> as tuned for LANs at the expense of > everything else is not our goal. The defaults should reflect the needs > of the majority of users. We're trying to create a well-rounded VNC > implementation that can be used for a broad range of applications, not > just
Understood, which is why I proposed to enable the CUT by default in situations where it can be proven more beneficial than not (maybe in situations where the server detects that link usage is maxed out?) More study is warranted. I know that enabling it by default will hurt performance for the apps and deployment scenarios that are most important to VirtualGL. Thus, it would be nice if we could come up with an automatic mode that makes us both happy. > Why? I'd argue the opposite. It's should only be disabled when it is > clear that it is the limiting factor. For many (most?) users, that > limiting factor will be bandwidth, not CPU. And there is also the fact > that there is a "good enough" I, namely when it is no longer > possible for the user to tell the difference. Bandwidth is generally > always worth reducing. Sorry, but you're wrong. In most VirtualGL deployment scenarios, CPU usage is the primary constraint to performance. On a 1920x1200 desktop, you can really only get 15 fps on modern hardware, and even a few fps drop is noticeable at that level. My customers are, with great success (evidenced by our Red Hat Innovator of the Year Award) using TurboVNC as a replacement for local workstations. WAN performance is less important to them than absolute peak LAN performance, but again, I argue that there's probably a way to automatically detect when it would likely be beneficial. > These numbers are way too big to ignore. And given that the CUT used to > be enabled (i.e. this is a regression), and that I have yet to see an > installation where server side CPU was such a major issue that > bandwidth can be ignored, I say we should revert to the 1.1.0 behaviour. >From the point of view of TurboVNC customers, who Cendio is hypothetically >trying to attract by hiring me to enhance TigerVNC's performance, decreased >frame rate and increased server CPU usage would be viewed as a regression >relative to TurboVNC and would hinder adoption of TigerVNC in that market. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
