[FreeNX-kNX] Extremely poor performance with Youtube/flash

[Mario Becroft]

I have found some conditions where the performance of nx is extremely
bad. The most common seems to be running Adobe flash, especially when
watching youtube videos.

What happens is that the frame rate is quite low. This might be
acceptable, except that other clints not playing the flash video become
unresponsive delayed (for instance it can take more than 1 second to
respond to a mouse click), making it impossible to do anything while the
flash video is playing. This happens even when running over fast
ethernet.

I notice that adjusting the nx client bandwidth setting down to ISDN or
lower fixes the unresponsiveness. However this makes the video play even
slower, presumably because nx is limiting the bandwidth. I don't know
whether the unresponsiveness is fixed only because the video is going
slower, or because something is qualititatively different in the ISDN
mode.

Looking at netstat output on the nx client host, it is clear that there
is no congestion on the nx protocol link to the remote nxagent since the
rx queue length is nearly 0. This suggests that the nx protocol itself
is doing a decent job of congestion control. However, if the nxssh is
made to connect via tcp to the local X server, then you can see that
there is massive congestion on the X protocol connection from nxssh to
the X server. See the following netstat output:

--8<---------------cut here---------------start------------->8---
$ netstat -n
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 10.10.12.88:6000            10.10.10.10:38944           ESTABLISHED
tcp   880920      0 10.10.12.88:6000            10.10.12.88:33382           ESTABLISHED
tcp        0      0 10.10.12.88:51509           10.10.10.31:5056            ESTABLISHED
tcp        0      0 10.10.12.88:6000            10.10.10.31:55809           ESTABLISHED
tcp        0      0 10.10.12.88:6000            10.10.10.31:55830           ESTABLISHED
tcp      256      0 10.10.12.88:37832           10.10.10.31:22              ESTABLISHED
tcp        0 917504 10.10.12.88:33382           10.10.12.88:6000            ESTABLISHED
--8<---------------cut here---------------end--------------->8---

10.10.12.88 is the nx client host running nxssh and an X
server. 10.10.10.31 is the nx server host running the nxagent. As you
can see, there is nearly a megabyte of traffic queued at any moment on
the local connection from port 33382 (nxssh) to port 6000 (X).

The reason for this is obvious from client host top output:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3320 root      20   0  198m  59m 4828 R 65.6 24.7 135:09.36 X
 4195 qclient   20   0  9784 6676 2920 S 37.8  2.7   0:12.16 nxssh

Between them, nxssh and X are CPU bound. (this is a single processor
machine.)

Even on machines with fast CPU and high-performance nvidia or ATI
graphics, it is the same. The X server is CPU bound just trying to draw
about 5 fps of Flash video at about 400x300 pixels coming from nx. It is
quite noticable that each frame can be seen to draw from the top to the
bottom of the video screen area, and during this time, no other drawing
operations take place on the X server (even ones from local clients not
running over nx). The X server I am using on the nx client host is Xorg
(various different versions up to 1.3).

On the other hand, when running flash video from the same host via X
protocol (without using nx), the frame rate can be slower (depending on
the link speed) because there is no compression, but there is about 0%
CPU usage form the X server, and all other X clients remain responsive.

I don't know enough to understand this problem much, but it seems to me
it must be one of the following:

1. Nx uses some pixmap format that is very inefficient for the X server
to process, and thus requires such a large amount of CPU time. It seems
most unlikely, however, that this could result in the observed degree of
slowness.

2. I don't know enough about the X server architecture to have a clue
about this, but here is a hypothesis: when nxssh makes a PutImage (or
whatever) call, it transmits the begining of the call, then gradually
transmits the image data as it is received and decompressed. The X
server begins the drawing operation as soon as the request header is
received, but before there is any image data. Due to its design, the X
server does not handle any requests from other clients while it is in
the process of doing this drawing operation, and it busy waits while
receiving and drawing the image data. This would explain the
unresponsiveness of other clients, and the high CPU usage, because X's
busy waiting would slow down the decompression of the image data by
nxssh.

These are the only two explanations I can think of. I guess the next
step in diagnosing this might be to use oprofile to find out what the X
server is spending all that time on.

It is worth noting that the system as a whole is capable of playing
flash video with no trouble, since if, for example, Xvnc is used, which
is exercising all the same hosts and network paths, the performance is
excellent.

Has anyone else noticed this problem, and does anyone have any ideas
about what might cause it or how to fix it?

-- 
Mario Becroft <mb at gem.win.co.nz>