vglclient and VirtualGL's built-in image transport work fine on local-area networks, but they are not recommended on any network that has a latency greater than about 20 ms. The reason is that this transport relies on X11 to send the 2D elements of the application display. It is an improvement over using X11 to send both 2D and 3D, but it still has some latency sensitivity. Running VirtualGL in a TurboVNC session is the recommended solution for high-latency networks.
The behavior you describe is consistent with running the VirtualGL Transport over a slow or high-latency network. Again, always disable frame spoiling when benchmarking, because that's the only way you'll get an accurate frame rate from the benchmark, but always re-enable it after benchmarking, so you won't see the delay when you stop rotating. On 2/9/11 12:37 PM, dani rivas wrote: > Sorry for the delay (answering), I had some problems at work with OpenGL > and I have not been able to test my app again until now. > I tried to rotate my volume model as fast as possible for benchmark > purposes and what I noticed is that when pressing the stop button it > remained rotating like may be for the order of seconds. I have been > trying to reproduce the problem but now I just have one PC available to > do the benchmark (when I was experiencing these issues I comment I was > working with 10-15 PC at full) and with a 100mb/s lan I am not able to > reproduce the effect. I will do it again and I will let you notice the > new results as soon as I test it again. > As configuration I am just using the default options. I am not using the > option -c because as far as I know it is using jpeg as default. May be I > am wrong. > > Sorry for my "ignorance" on my own test but I have taken for granted > somethings that may be I haven't to (like default transport mode or the > frame spoiling working like I said). As I said, I will let you know as > soon as I can (I hope it will be tomorrow). > > And thank you very much for your help. > > 2011/2/8 DRC <dcomman...@users.sourceforge.net > <mailto:dcomman...@users.sourceforge.net>> > > On 2/8/11 6: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. 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. > > Frame spoiling does precisely that, and it does so to avoid precisely > the delay problem you describe. Spoiling is meant to be used with > interactive applications. It is designed such that, when you move your > mouse (or control the application using the keyboard, in your case), the > remote 3D pipeline will discard any frames necessary to keep pace with > your mouse movements. Otherwise, without spoiling, the 3D rendering > will become locked to the rate at which frames can be sent to the > client, and if this is significantly less than the 40-60 Hz rate at > which the mouse is sampled, it will feel like the scene lags behind your > mouse movements. Also, if frame spoiling is disabled, there will be a > 1-2 frame delay whenever you stop moving the object, because VirtualGL > has to flush out the pipeline. That 1-2 frame delay can be noticeable > if the network is low-bandwidth. If running on a low-bandwidth network, > however, you should really be using TurboVNC along with VirtualGL rather > than trying to use VirtualGL's built-in image transport (which is > designed only for fast networks), and you should probably be reducing > the image quality to a lower level than the default. > > > > I would like to know if I am doing something wrong or it is just the > > option is not implemented yet. In that case I would like to implemented > > it by myself but I need some help with the code. I have been following > > inside the code the option -fps and +sp trying to see where is done the > > frame spoiling but until now I have not been very lucky with it. So, if > > anyone knows the code better than I do (I am sure everyone will do :) ) > > I would be very thankful if can tell me where to look at. > > I'm not totally understanding what the problem is. It sounds like > you're trying to rotate the model as fast as it will go-- is this for > benchmarking purposes? If so, then disable spoiling while benchmarking > and then re-enable it when you are ready to interact with the > application again. Spoiling can be enabled/disabled on the fly using > VirtualGL's pop-up menu (see User's Guide.) > > > ------------------------------------------------------------------------------ > 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 > <mailto:VirtualGL-Users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > > > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
