[FreeNX-kNX] Forcing the graphical applications to use the server-side graphics abilities

[Mario Becroft]

Murray Trainer <mtrainer at central-data.net> writes:

> Hi Prakash,
>
> There was a thread on this list titled "[FreeNX-kNX] NX performance issue" starting 3/10/07.  I am not sure if there were any results?  Perhaps a developer can update us all on the status of this.
>
> Thanks
>
> Murray
>
>
>>Hi there.  I develop an open source application (http://www.virtualgl.org)
>>which adds hardware-accelerated 3D capabilities to X proxies such as NX,
>>VNC, etc.  It works by rerouting the 3D rendering into a Pbuffer on the
>>server's graphics card, reading it back, and drawing it into the X proxy
>>using XShmPutImage() or using X pixmap drawing (if XShm isn't available.)
>
>>The essential workload that VirtualGL produces is a stream of full-screen
>>(usually 1280x1024), back-to-back calls to XShmPutImage() or XCopyArea(),
>>depending on whether the MIT-SHM extension is available.
>
>>And now, the issue -- in either case, what I observe with NX is that this
>>workload will perform great for about 3-5 seconds, then it will slow to a
>>crawl and remain slow.  I've tried various quality settings,
>>enabling/disabling the bitmap caches, etc., and nothing seems to improve the
>>situation.  Is there something else I could try?  Or is there perhaps a way
>>to profile that system and determine what's causing it to slow down?  I
>>don't observe this slow-down with other X servers (TurboVNC, specifically,
>>or even just sending the pixels via. remote X on a gigabit connection.)

I have not used VirtualGL, but I have done some performance diagnostics
in nx.

It is important to find out whether the bottleneck is in nx (nxagent or
nxssh) or in the X server that nxagent is displaying onto. This is easy
to check by using a TCP connection to the X server and running netstat
on the X server host (the one running nxclient). If there is a large
queue size on nxssh's connection to the X server, this indicates that
the X server is falling behind because it cannot complete the drawing
operations as fast as nx is sending them on the wire.

I would then use oprofile on the host running nxagent and/or the host
running nxssh and the X server to find out where it is spending time.

I can't think off-hand what would cause the behaviour you describe, but
I have seen some very weird behaviour that I can't explain where the X
server, which normally can easily cope with the graphics workload,
suddenly become very slow and falls way behind. In my case, though, it
is triggered by resizing the nxagent root window, not the same as in
your case.

Another thing that is not directly relevant here but still interesting
is that because nxagent is a single client of the X server, if the X
server gets bogged down and the socket buffer starts to fill up, instead
of only one client becoming unresponsive, all clients running through
nxagent (in our case, everything) become unresponsive. To fix this, some
serious work is needed to control congestion on the connection between
nxssh and the X server--or at least, the socket buffer size needs to be
restricted.

It would also be interesting to try modifying the image compression and
streaming parameters in nxclient and see whether this affects the
problem. The way nx streams images is very different depending on the
link speed setting, which will have a large impact on the
performance. Still, regardless of the parameters, we should not be
seeing the behaviour described.

This sounds like an interesting problem.

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