On 11/9/11 3:41 AM, Pierre Ossman wrote: > Here is the promised patch to "fix" the latency issue in VNC. The basic > idea is to let the server start sending updates without requests, but > doing so in a way that doesn't overload the client or the network. > > WARNING! This patch uses protocol numbers that aren't properly > registered and should therefore not be deployed anywhere!
How are you testing/verifying performance of this solution? I'm using qdisc to add varying amounts of latency on both ends of a Linux->Linux connection that has been stepped down to 10 Mbps on both ends. In the next-gen version of TurboVNC, manually enabling the Continuous Updates extension (which causes the TurboVNC server to send updates immediately to the client) produces significantly better throughput on this type of connection, but none of the TigerVNC enhancements seem to have improved its throughput. ------------------------------------------------------------------------------ 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. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
