Never mind. I just updated my client-side VGL to 2.2alpha1 (which the server was already using) and now everything works fine, no lag anymore. B.t.w, great work integrating libjpeg/SIMD!
Best regards, Paul Paul Melis wrote: > Unfortunately, I can't check without tunneling, due to network and > firewall limitations. I've experimented a bit further with disabling ssh > compression (which would take extra time) and forcing the use of > blowfish-cbc. None of these make any difference. > > However, I did now notice that the amount of lag depends on the image > content, so it seems to be an image compression problem, even though the > profile data seems to suggest there is enough speed there. Is there a > way to get more detailed profiling data, like reporting the numbers more > often than currently is done? > > Paul > > DRC wrote: > >> There shouldn't be any lag unless frame spoiling was disabled (it is >> enabled by default.) Maybe the SSh tunnel is causing problems, >> however. Do you get the same lag with vglconnect without the -s option? >> >> On Feb 11, 2010, at 6:09 AM, Paul Melis <[email protected]> wrote: >> >> >> >>> Hmm, I must have been checking the wrong log file then (probably on >>> the >>> server instead of the client), because now I indeed see the numbers, >>> thanks! >>> >>> Would you have some performance insight into the following? I'm >>> running >>> a VGL Image Transport session over ssh (vglconnect -s), the numbers >>> below being an excerpt from such a session. These look fine to me, the >>> network speed should not be a problem, the resolution of the >>> application >>> is fairly low (640x480), but I'm experiencing a lag in the >>> interaction. >>> I.e. when rotating a 3D model in the application with the mouse the >>> image is updated noticeably (and annoyingly) later. When running the >>> same application with VirtualGL+TurboVNC (0.6) over an ssh-tunneled >>> VNC >>> session the lag is almost non-existent. >>> >>> One thing that is slightly weird in my setup is that the server runs >>> 64-bit VGL 2.2alpha1, while the client is using 32-bit VGL 2.1.3. >>> Could >>> that cause issues like the above? Are client/server combinations like >>> this supported at all? >>> >>> Thanks, >>> Paul >>> >>> >>> >>> [Server] >>> Readback - 230.83 Mpixels/sec- 751.39 fps >>> Compress 0 - 47.48 Mpixels/sec- 154.56 fps >>> Total - 26.79 Mpixels/sec- 87.21 fps- 0.54 Mbits/sec >>> (1184.6:1) >>> Readback - 231.51 Mpixels/sec- 753.60 fps >>> Compress 0 - 46.00 Mpixels/sec- 149.73 fps >>> Total - 26.45 Mpixels/sec- 86.09 fps- 42.02 Mbits/sec >>> (15.1:1) >>> Readback - 226.35 Mpixels/sec- 736.82 fps >>> Compress 0 - 46.62 Mpixels/sec- 151.75 fps >>> Total - 26.15 Mpixels/sec- 85.12 fps- 80.71 Mbits/sec >>> (7.8:1) >>> Readback - 215.57 Mpixels/sec- 701.72 fps >>> Compress 0 - 47.46 Mpixels/sec- 154.50 fps >>> Total - 24.22 Mpixels/sec- 78.85 fps- 28.79 Mbits/sec >>> (20.2:1) >>> Readback - 257.80 Mpixels/sec- 839.18 fps >>> Total - 26.86 Mpixels/sec- 87.43 fps- 4.79 Mbits/sec >>> (134.7:1) >>> >>> [Client] >>> Decompress - 14.35 Mpixels/sec- 46.73 fps >>> Blit - 292.95 Mpixels/sec- 953.63 fps >>> Total - 25.75 Mpixels/sec- 83.82 fps- 40.78 Mbits/sec >>> (15.2:1) >>> Decompress - 15.17 Mpixels/sec- 49.39 fps >>> Blit - 256.11 Mpixels/sec- 833.68 fps >>> Total - 19.18 Mpixels/sec- 62.42 fps- 56.85 Mbits/sec >>> (8.1:1) >>> Decompress - 14.83 Mpixels/sec- 48.26 fps >>> Blit - 332.58 Mpixels/sec- 1082.60 fps >>> Total - 29.54 Mpixels/sec- 96.17 fps- 47.41 Mbits/sec >>> (15.0:1) >>> Blit - 320.82 Mpixels/sec- 1044.33 fps >>> Total - 31.15 Mpixels/sec- 101.40 fps- 4.79 Mbits/sec >>> (156.2:1) >>> Blit - 294.86 Mpixels/sec- 959.84 fps >>> Total - 26.86 Mpixels/sec- 87.43 fps >>> >>> >>> DRC wrote: >>> >>> >>>> If you use vglconnect, then it automatically starts vglclient and >>>> redirects the output to a log file in ~/.vgl, which is where the >>>> profiling output will be. You can do tail -f <logfile> to see this in >>>> real time. >>>> >>>> On Feb 10, 2010, at 4:01 AM, Paul Melis <[email protected]> wrote: >>>> >>>> >>>> >>>> >>>>> Hello, >>>>> >>>>> When doing VGL Image Transport it's easy to get profiling data on >>>>> the >>>>> server side (vglrun +pr), and the docs mention the env.var. >>>>> VGL_PROFILE >>>>> to enable it on the client side as well. But how is that supposed to >>>>> work? Should I do this? >>>>> >>>>> [client] export VGL_PROFILE=1 >>>>> [client] vglconnect -s <host> >>>>> [server] vglrun ... >>>>> >>>>> If so, where does the client-side profiling data go? If this isn't >>>>> the >>>>> way to do it, how should one use the VGL_PROFILE setting? >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> --- >>>>> --- >>>>> --- >>>>> --- >>>>> ------------------------------------------------------------------ >>>>> SOLARIS 10 is the OS for Data Centers - provides features such as >>>>> DTrace, >>>>> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW >>>>> http://p.sf.net/sfu/solaris-dev2dev >>>>> _______________________________________________ >>>>> VirtualGL-Users mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/virtualgl-users >>>>> >>>>> >>>>> > > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > VirtualGL-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
