I have hundreds of users using TurboVNC (which doesn't have a CUT) with dual
1920x1200 displays, and CPU is definitely the primary limitation. They are not
having issues with bandwidth.
What I'm saying is that we should not have a knee-jerk reaction to this or to
decide based on only one or two apps. This needs to be studied at the low
level. I know for a fact that the CUT kills performance for 3D and video apps.
Pierre, more specifically, Cendio hired me to improve the performance of
TigerVNC, and it doesn't make sense to then reverse some of that hard-fought
gain.
Will discuss further when I'm back in the office.
On Nov 11, 2011, at 8:54 AM, Brian Hinz <bph...@users.sourceforge.net> wrote:
> Initially I would have agreed completely with DRC since 95% of my users are
> on GbE fiber, but if those numbers accurately reflect typical usage (and it
> would seem they do) then I have to wonder how this might affect throughput.
> It's been a while since the last time I tried to quantify this (>6 months),
> but I know that when I did I was surprised at how low the overall bandwidth
> usage was for 50+ users (all with large displays, >=1920x1200). If nothing
> else, can this be made to be a runtime option?
>
> -brian
>
> On Fri, Nov 11, 2011 at 5:48 AM, Pierre Ossman <oss...@cendio.se> wrote:
> On Thu, 10 Nov 2011 13:40:38 -0600
> DRC <dcomman...@users.sourceforge.net> wrote:
>
> > Sorry, but I've quantified the reasons why it should be disabled on a
> > LAN. If you see some benefit in performance on a WAN, then you need to
> > quantify that as well. I will not endorse TigerVNC unless it is
> > "performant by default."
>
> I'm sorry you feel that way 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 LAN use.
>
> I'd also like to hear what other people think. Adam? Brian? Anyone else
> following this list? What use cases are your priority?
>
> > The CUT uses a significant amount of server CPU time, so if it benefits
> > WAN-based scenarios, it needs to be quantified how much and how much of
> > a CPU time hit is incurred from the LAN-based scenarios. If it
> > benefits only one and not the other, then the default behavior needs
> > to be enabling it only when it shows a clear benefit without
> > compromising overall frame rate.
>
> 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" framerate, namely when it is no longer
> possible for the user to tell the difference. Bandwidth is generally
> always worth reducing.
>
> But you want some numbers, so I did some quick measurements:
>
> Firefox, msn.com, 10 seconds with a blinking cursor and animated
> preview:
>
> With comparing:
>
> 1.3 MiB to 2.4 MiB
>
> Without comparing:
>
> 3.8 MiB to 7.5 MiB
>
> Bandwidth savings:
>
> 66-68%
>
> Firefox, idg.se, 10 seconds with an animated GIF banner ad:
>
>
> With comparing:
>
> 420 KiB to 450 KiB
>
> Without comparing:
>
> 12 MiB to 16 MiB
>
> Bandwidth savings:
>
> 96-97%
>
> Compositing, gnome-terminal, 10 seconds with mostly just empty space
> and blinking cursor:
>
> With comparing:
>
> 30 KiB
>
> Without comparing:
>
> 501 KiB
>
> Bandwidth savings:
>
> 94%
>
> Compositing, gnome-terminal, 10 seconds with a fair amount of text
> present and blinking cursor:
>
> With comparing:
>
> 100 KiB
>
> Without comparing:
>
> 1.7 MiB
>
> Bandwidth savings:
>
> 96%
>
>
> 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.
>
> More work on the CUT is of course worthwhile. Perhaps it should have
> some heuristic on automatically turning it on and off based on the
> availability of CPU? But where we stand right now, having it off is a
> worse trade-off than having it on. IMO.
>
> Rgds
> --
> Pierre Ossman OpenSource-based Thin Client Technology
> System Developer Telephone: +46-13-21 46 00
> Cendio AB Web: http://www.cendio.com
>
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>
> ------------------------------------------------------------------------------
> 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
>
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
