On 11-02-08 07:02 AM, dani rivas wrote:
> I am experiencing some delay issues using VirtualGL due to the bandwith
> on my network. For example, when I press a button to start rotating a
> model as fast as the graphic can go, if the network is working at
> maximum (there is a bottleneck on it), when I press the stop button
> there is a delay that can be from ms to seconds.

1. By delay, you mean the image keeps rotating for a little bit before 
it stops?

2. What transport are you using? That is, which argument to 'vglrun -c'?
If using "proxy" mode, where is the X server in relation to your app 
(local/remote)?

> I tried the frame
> spoiling option ("+sp") but what I feel is that it just drops frames
> when the client can't process them but if the problem is on the bandwith
> virtualGL just works as usual.

(Off the top of my head) There is the application's GL thread that reads 
back frames, and these frames are passed to a separate thread that has a 
queue of frames to be sent.  If you use +sp (default) then what happens 
is when a frame is read back from your graphics card VirtualGL checks if 
the queue still has any frames in it, and discards them if any.  So old 
unsent frames are always replaced by the latest.  The reason the queue 
will still have frames in it is because it couldn't send them to the 
remote side fast enough.

Therefore, spoiling takes into account all aspects of sending the 
frames: bandwidth, remote processing speed, etc.

If the size of your GLX window is not very large I could see a slight 
delay coming from having to drain VGL's queue, full TCP buffers, plus 
any remote side buffers. Without a network trace it's hard to guess what 
the issue is though.

-Nathan

-- 
Nathan Kidd
OpenText, Connectivity Solutions Group

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
VirtualGL-Users mailing list
VirtualGL-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtualgl-users

Reply via email to