Two machines, A et B, on a wired LAN with X11 forward running fine. A is a fully configured Arch linux but has a bad screen. B has a much better screen even though an old netbook, so I work on it using a live Porteus (Slackware). All is working fine with respect to the limited horsepower B has. Until I want to watch a (streamed) video.

The issue

Heavy browsing with Firefox + multiple terminal + Libreoffice has both ssh on client and sshd on the server use < O.5% CPU.

But opening a low resolution video (on Dailymotion or Youtube) has ssh & sshd literally eat CPU @ 100% (with X @ 1%) and 60%, with A/V desync and the broswer lagging in accordance!

Ssh connection settings

I did played with ~/.ssh/config. Especially the Cipher in use as after some testing: arcfour128 proves to be three times faster than aes128-ctr (22 vs 6.2 MB/sec).

1) Default (Cipher, no ForwardX11Trusted or Control{Master,Path,Persist}: Crazy CPU usage and perceived display/result.

2) With ForwardX11Trusted or Control{Master,Path,Persist} ON: Same crazy CPU usage and perceived display/result.

3) Lan and old boxes optimized

Cipher      arcfour128
Compression     no
ForwardX11      yes
ForwardX11Trusted   yes
# Make all sessions to the same host use a single connection:
ControlMaster   auto
ControlPath     ~/.ssh/socket-%r@%h:%p
ControlPersist  3600
# Bypasses IPv6 lookup:
AddressFamily   inet

Same crazy CPU usage and perceived display/result.

4) I tried to launch the embedded video in an external player with GreaseMonkey's Linterna Magica, and the MediaPlayerConnectivity add-on without success. Even though machine A's mpv player cannot handle the no hardware rendering on machine B: caca video output only :}

Would appreciate it if someone can show me:

  • why a low resolution streamed video (html5 if that counts) makes ssh eat the whole CPU, when ssh can allow for a 22 MB/sec throughput on the same boxes?
  • why the cipher used makes no perceived difference?
  • try settings other than mine above that can help playing a video through Xforwarding.
  • 1
    Have you tried to run this without ssh, by directly spawning a window remotely? (X11 DISPLAY environment variable) I think that it's overkill for ssh to stream video, ssh will be bottleneck there. – user140866 Nov 10 '15 at 7:18
  • @siblynx I'll try that! He he simple X11 tunneling didn't even cross my mind. Not used to LAN operations I bet ":o} – tuk0z Nov 10 '15 at 12:02
  • If it will be still slow then either the X11 protocol was not designed for such fat applications or insufficient network throughput. Monitor network activity in parallel with testing. If it will be fast enough then ssh is bottleneck there. So probably there is no choice :-( (or you can accept watching videos insecurely of course :-) ) – user140866 Nov 10 '15 at 12:09
  • On pointing machine A $DISPLAY to the little bastard B's, html5 video streaming plays just fine, yeah without lagging or A/V desync :) CPU @ 50+% on A, 90% on B; network traffic @ 12 MB/sec i.e. eth0 down: 1.87Mb and up: 92.0Mb (will not try to understand that). The browser keeps being responsive. Now going to secure that via xauth Access Control. Next step, have the gma500 to support a bit of Xvideo hopefully. Kuddos to you @siblynx for pointing me right to the way to solve this issue. That poor man single Core Atom CPUs tandem now is exceeding my expectations. – tuk0z Nov 10 '15 at 21:04
  • Well done, so ssh is probably too weak for your two! If you want, I can post this as answer and you'll tick it solved. – user140866 Nov 11 '15 at 1:36

Perhaps for your setup sshd is too slow and becoming a bottleneck here. Using plain X11 forwarding may ease the pressure of realtime video playback over network, however a sufficient bandwidth (for example, ethernet) is probably required. sshd (no matter of implementation) can copy files well, although it's still heavyweight for little-CPU machines like embedded systems and netbooks, as from my own practice.

|improve this answer|||||
  • siblynx answer gladly accepted as it showed me the road. Its openness led me search and learn by trying. Still, two questions stay open: First is: 92 MiB bandwith to stream a SD video through ssh?? Second, if ssh's heavyweight for ARM or Atom @1.33 GHz, how did we do 15 years ago? My memory can be weak so I found this report from a guy called Van Emery who ssh'ed *a whole glossy GNOME (and KDE) to a Pentium II @ 350 MHz on an ADSL line, back in 2003: CPU usage @ 10%! Benchmark is included. – tuk0z Nov 15 '15 at 1:21
  • 1
    Congratulations! Enjoy the bless of self education and opening new things. I'm glad I helped you there. Now, you can think about it: comparing old GNOME/KDE in 2003 when things were not such complicated as now (install fvwm and try to run it like that today. The same and even less) and today, uncompressed video stream that flows raw through your wire. Please note that it's not only streaming, it's uncompressing and displaying directly to your screen, but from remote. Then I no wonder why 92MBits! – user140866 Nov 15 '15 at 1:26
  • Well, and whole stack of question now opens to you: uncompressing a video takes CPU, then ssh encryption (and maybe comprssion, again!) takes CPU again. On client: ssh decoding whole stream (uncipher and probably uncompress). Well, disgusting! :) – user140866 Nov 15 '15 at 1:35
  • Ah, true video stream is uncompressed and displayed directly to the client's screen from remote I missed that. ps no compression on LAN (activatiing it made no perceavable diff) – tuk0z Nov 15 '15 at 1:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.