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
