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
