VNC is a bit of a tricky beast in terms of performance. Because the flow is client-controlled (that is, updates are sent only when the viewer requests them, which it does only when it's free to receive them), you encounter situations in which the VNC server effectively spoils frames sometimes and doesn't spoil them other times. Thus, you can't really rely upon the throughput reported by GLXspheres in this case. You have to measure the throughput from the client end using TCBench. That is also tricky, because whenever the VNC server is cycling like this, its CPU usage will fluctuate wildly, which can affect its ability to deliver frames to the client. If you're just concerned with frame rate, then I would suggest just using TCBench-- it should be accurate enough. If you're interested in measuring things like per-frame encoding time and the other metrics I typically use when benchmarking TurboVNC, then the procedure for that is not very pretty and generally requires an expert's touch.
What I'm working on right now is porting over the TigerVNC flow-control extensions. These allow updates to be sent continuously from the server, but they also introduce a mechanism to prevent those updates from being sent any faster than the client is able to process them. Thus, it should be possible to introduce a sort of equivalent to 'vglrun -sp' in TurboVNC, making it much easier to benchmark. Even though you're running without frame spoiling in VirtualGL, when TurboVNC enters a phase in which it starts spoiling frames, the GLXspheres frame rate will cease being coupled to the rate of frame delivery to the client, and thus it will run basically as fast as your graphics card is able to render and VirtualGL is able to read back and blit the frames into the VNC server. The reason why glXSwapBuffers() shows such a high CPU usage is that, when frame spoiling is disabled in VGL, the 3D rendering thread (that is, the application's main thread in the case of GLXspheres) is coupled to the blitter thread, so the XPutImage() call will basically occur before glXSwapBuffers() returns. I should also note that, rather than decreasing the window size, you can also simply decrease the image quality to improve your throughput. GLXspheres will typically generate ~2 bits/pixel of compressed image data when using Perceptually Lossless JPEG, ~1 bit/pixel with Medium-Quality JPEG, and ~0.5 bits/pixel with Low-Quality JPEG, so 15 Mpixels/sec is about the max you'll see on a 30 Mbps network unless you decrease the image quality. On 8/13/12 8:34 AM, Leander Koornneef wrote: > On 13 August 2012 13:55, Leander Koornneef > <leander.koornn...@clustervision.com> wrote: >> >> Hi list! >> >> I'm setting up a graphics/visualization server with VirtualGL and am >> currently testing the setup using the glxspheres(64) application. The server >> is a Dell Precision R5500 Rack Workstation with two Nvidia Quadro 6000 >> GPU's, running Scientific Linux 5.8 (x86_64). The VirtualGL/TurboVNC >> installation seems to be working, but the performance I get with the >> glxspheres application is rather inconsistent and I don't really have an >> idea why. When I run 'vglrun -d :0.0 +v -sp +pr +tr >> /opt/VirtualGL/bin/glxspheres64' it typically starts out rendering around >> 500fps. Then, after a while, the fps will drop dramatically to only a few >> per second, like so: >> >> 487.153071 frames/sec - 495.941312 Mpixels/sec >> 383.257436 frames/sec - 390.171400 Mpixels/sec >> 200.162382 frames/sec - 203.773311 Mpixels/sec >> 138.313337 frames/sec - 140.808510 Mpixels/sec >> 1.102129 frames/sec - 1.122012 Mpixels/sec >> 25.927141 frames/sec - 26.394867 Mpixels/sec >> 7.162349 frames/sec - 7.291557 Mpixels/sec >> 18.690150 frames/sec - 19.027321 Mpixels/sec >> 1.763289 frames/sec - 1.795099 Mpixels/sec >> 2.448173 frames/sec - 2.492338 Mpixels/sec >> 1.189486 frames/sec - 1.210945 Mpixels/sec >> 10.394469 frames/sec - 10.581986 Mpixels/sec >> 21.496225 frames/sec - 21.884017 Mpixels/sec >> 11.616107 frames/sec - 11.825661 Mpixels/sec >> 1.926034 frames/sec - 1.960780 Mpixels/sec >> 1.843533 frames/sec - 1.876790 Mpixels/sec >> 1.929879 frames/sec - 1.964694 Mpixels/sec >> 1.881723 frames/sec - 1.915670 Mpixels/sec >> 1.944252 frames/sec - 1.979326 Mpixels/sec >> >> Sometimes it will go back to >100fps, only to drop back again to single >> digits soon after. I've looked at the trace output and it seems that an >> inordinate amount of time (hundreds of milliseconds) is spent in >> glXSwapBuffers(). I'll attach the trace output to this message. >> This happens on both Quadro cards and with both the 32-bit and 64-bit >> glxspheres. I've tried different versions of the nvidia kernel module, but >> that does not seem make much of a difference, altough the older versions >> (275.xx) seem to have a much faster startup time. With the 295.xx version >> module, I typically have to wait around 30 seconds before I get any output >> at all, whereas with older versions of the module I'll get output after only >> a few seconds. >> >> Now I'm not sure what to do next, so I've come here hoping for some help. >> I will gladly provide more information if needed. > > Replying to my own post here, with apologies for the html in the > original message. > > It seems I may have underestimated the importance of having enough > bandwidth between the VNC client and server. With the default window > size of glxspheres (in my case about 1200x900 pixels), the link > between me and the server (30mbit/s, 30ms roundtrip over 1500 > kilometers) was pretty much completely saturated straight away. When I > decrease the size of the window, it happily renders hundreds or even > thousands of frames per second, depending on the window size. > > However, the issue with the slow startup when using the newer nvidia > module still remains, but I'm not sure if that is even necessarily > related to VirtualGL? > > Best regards, > Leander > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > VirtualGL-Users mailing list > VirtualGL-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/virtualgl-users > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
