On 10/4/11 7:11 AM, Pierre Ossman wrote: > (Cross-posting to both tigervnc-devel and rfbproto as this is a general > protocol issue, but tigervnc will be the playground for testing it) > > Hi, > > I'm looking at making VNC/RFB work better over high latency network. > Right now we're limited to one update per RTT, which makes things > rather unpleasant over many links. Things are still very much up in the > air, but I've written down my thoughts so far and I'd appreciate any > input you could give on it. You can find my notes here: > > https://sourceforge.net/apps/mediawiki/tigervnc/index.php?title=VNC_Latency_Considerations
I've been dealing with these sorts of problems for years with VirtualGL, and what we've found is that it's not so much the latency that's the problem-- it's the user's perception of the latency. At the end of the day, there are two things the user will notice more than anything else: (1) how long it takes the application to respond whenever they start or stop dragging the mouse, and (2) the apparent frame rate when they are dragging. Generally, there is little that can be done to improve the performance of isolated input events, such as single keystrokes or mouse clicks. If you press "A", you will always have a round trip before you see the A in your VNC Viewer window, and users can typically deal with that by "typing ahead" of the latency. That doesn't work with mouse dragging, however, because you need constant visual feedback to determine when to start/stop and how fast to drag. If there is a noticeable lag between the time that the user starts or stops dragging and the time that the application starts or stops animating, or if the frame rate while dragging is too low, interactivity is effectively lost. The frame rate issue is easily addressed by using a continuous (unsolicited) updates mechanism. That essentially gives you a protocol akin to VirtualGL's VGL Transport with frame spoiling turned off. However, the problem there is that, since every mouse event results in a frame being sent through the pipeline, there is always a perceptible delay. The easiest way around that is to spoil frames. The way VGL does this is to compress and send the frames in a second thread. The second thread is gated by send blocking, as you mention in your article, but not all frames make it into the second thread. Basically, when the second thread comes back around for a new frame, only the latest one gets in. Thus, the application "feels" as if it is responding instantly to the mouse, because the actual frame rendering is keeping pace with the mouse movements, even though only a fraction of those frames may end up being sent to the client. Personally, I'm in favor of simplifying VNC's mechanism for sending updates as much as possible. I'd love to somehow get rid of the deferred update timer, for instance. IMHO, the easiest way to do that is to implement a spoiling queue and a compress/send thread for each connected client. That way, you can truly control the flow of updates on a client-by-client basis. There would still be only one X11 server thread, but whenever it dispatched an update to a client that had frame spoiling enabled (which all would by default), that update would either be immediately copied into a send queue or it would be discarded. In either case, the X11 thread would immediately return control to the application. The way things currently work with the deferred update timer is somewhat complicated, and it can produce situations in which one slow client can cause the server to lock into its frame rate, slowing down all other clients. The other advantage of having a separate thread for each client is simply that multiple client streams can be processed in parallel on multi-core machines. As part of these enhancements, the other thing I think we need to do is implement a back buffer on the client. The idea would be to have a viewer that never has to ask for updates from the server. If its window becomes obscured, it continues to receive updates and draw them into its back buffer, and when the window becomes visible again, it simply swaps from back to front rather than requiring the server to re-send those regions of the window. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
