Hi Darrell, Thanks - the client we just tried was a Windows one but we'll be trying a few. I'll give the multi-threading a go.
For testing purposes, how out is setting a standard resolution screen to something ridiculous? Is it smart enough to down sample on the server side if the client is viewing in scaled mode? Or if the client is viewing in full res, but only a portion, is the out of view portion not sent? The point James just made is also something I need to try, I forgot to look if the ssh daemon was maxing out! And I should test with it without any tunnel at all. Cheers, Paul ----- Original Message ----- > From: "DRC" <dcomman...@users.sourceforge.net> > To: virtualgl-users@lists.sourceforge.net > Sent: Saturday, 15 June, 2013 9:43:08 AM > Subject: Re: [VirtualGL-Users] Improving performance on very large displays > > Bigger pipes will definitely help, up to a point. The compression > ratio > you can get will vary a lot depending on the types of images that the > app is generating. I use GLXspheres as a sort of > "middle-of-the-road" > approximation, since it has a realistic proportion of solid color and > smooth gradient, one that you might see in a CAD or viz app when the > model is zoomed out to fit in the window. However, as they say here > in > the States, your mileage may vary. > > GLXspheres compresses to about 1.8 bits/pixel when using perceptually > lossless JPEG, about 0.75 bits/pixel when using medium-quality JPEG, > and > about 0.4 bits/pixel when using low-quality JPEG. Thus, for that > particular image workload to maintain 15 fps at low quality on a > 24-36 > Mpixel display would require 10-15 Megabits/sec of bandwidth. Double > that for medium quality. > > It is also more than likely that you will run into a CPU bottleneck > once > you eliminate the network bottleneck. libjpeg-turbo is typically > going > to be capable of compressing perceptually lossless JPEG at about > 60-100 > Mpixels/sec on a reasonably modern CPU core (maybe a bit more than > that > now-- my machine is 2 years old.) Add 30% to that for medium-quality > JPEG, and add 50% for low-quality JPEG (both are faster, simply > because > they generate less data for the Huffman codec.) So applying that to > the > GLXspheres example above, my particular machine might be capable of > compressing ~2-4 fps with a 24-36 Mpixel display, or perhaps ~3-6 fps > if > using low-quality JPEG. > > If the client and server are reasonably similar in terms of CPU > performance, then you can probably improve the situation by enabling > server-side multithreading (export TVNC_MT=1 prior to launching > vncserver.) This divides the VNC desktop into equal-sized tiles and > uses a separate compression thread for each. Even though the client > is > not multithreaded yet, typically libjpeg-turbo can decompress a lot > faster than it compresses, so enabling server-side multithreading > will > likely shift the CPU bottleneck to the client. Be sure to read the > section on multithreading in the TurboVNC User's Guide. > > I have funding to work on multithreading the client as well and will > be > looking into that later this summer. Can you clarify which viewer > you're using? > > > On 6/14/13 6:12 PM, Paul McIntosh wrote: > > Hi, > > > > I have done a couple of experiments with very large displays (e.g. > > 7680x4800, 7680x3200) and the performance has (understandably) > > dropped significantly. > > > > Are there any tricks to improving the performance or is it not > > worth trying? I recall multi-threaded builds but have not had a > > chance to try them out. > > > > The tests so far have been on less than optimal links - we will be > > trying a long hall 1G network soon (across Australia) and possibly > > a shorter 10G link (from one facility on campus to another). Would > > bigger pipes solve the issue or is the bottle neck be elsewhere? > > > > Cheers, > > > > Paul > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > -- Dr Paul McIntosh Senior HPC Consultant, Technical Lead, Multi-modal Australian ScienceS Imaging and Visualisation Environment (www.massive.org.au) Monash University, Ph: 9902 0439 Mob: 0434 524935 ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
