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

[Prakash Velayutham]

Hi Mario,

My question is mainly, on the outset, would using the server-side  
graphics card for rendering (as VirtualGL does) and pushing the  
framebuffer through NX (and its compression and round-trip  
optimization features) be better than using OpenGL remote rendering  
(which basically disables hardware acceleration) on the NX client side?

These are my experimental numbers.

Client X (using NoMachine client)
FreeNX server Y
Graphics node Z

I connect via the NX client from X to Y (using SSH tunneling and X  
proxy)
I then SSH -X to the graphics node (this is needed in my setting as  
the graphics node Z is in a private network reachable only from Y)
Then I startup Matlab on the node. This, if I am correct, streams all  
the OpenGL rendering commands through the tunnel back to my client and  
uses the client-side X (which is the X server here) to render it. And,  
by the very definition, this cannot use hardware acceleration as it  
can only do indirect rendering. My Matlab startup time, as I see it,  
is about 27 seconds in this case.

What I have read thus far says that a VNC connection renders the  
graphics on the application side, instead of the interaction side. So,  
if, after connecting to node Z, I start up a VNC server on, say  
display 1, and then connect to Z from Y using a VNC viewer, and start  
up Matlab, the startup time, is about 10 seconds.

I am trying to understand which is the best way to extract the  
rendering power of the graphics node and still get the best  
interactive experience using NX.

I hope that is clear.

Prakash

On Mar 19, 2009, at 11:30 PM, Mario Becroft wrote:

> 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>
> ________________________________________________________________
>     Were you helped on this list with your FreeNX problem?
>    Then please write up the solution in the FreeNX Wiki/FAQ:
>
> http://openfacts2.berlios.de/wikien/index.php/BerliosProject:FreeNX_-_FAQ
>
>         Don't forget to check the NX Knowledge Base:
>                 http://www.nomachine.com/kb/
>
> ________________________________________________________________
>       FreeNX-kNX mailing list --- FreeNX-kNX at kde.org
>      https://mail.kde.org/mailman/listinfo/freenx-knx
> ________________________________________________________________