After a while testing (high and low latency and high and low bandwith
networks) you were right. The problem was mainly the X11 protocol, I didn't
test it before because I didn't think the protocol would be so "chatty". I
tested my app with differents transport modes and with VNC and my problem
appears when I work with an uncompressed X11 transmission. With TurboVNC my
app works very smooth even with a 1mpbs ADSL.
Reading about transport modes I found that I can implement my own :D So, I
am going to try it.
Thank you very much, again!
2011/2/9 DRC <dcomman...@users.sourceforge.net>
> 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
>
------------------------------------------------------------------------------
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
