On Wed, 07 Dec 2011 04:39:40 -0600 DRC <dcomman...@users.sourceforge.net> wrote:
>
> This is an Amdahl's Law thing. The frame rate is capped to 1 /
> ({deferred update time} + {FBU processing time}). Whether or not the
> FBU processing time is all CPU or some CPU and some I/O is irrelevant.
> As long as the server can't receive new X updates during that time, then
> the effect is the same.
>
That's my point. It is very relevant if it is CPU or I/O as we can deal
with those in very different ways. If I/O is the problem, then
increasing the buffer size should make the issue go away.
> > As to a solution, the only "proper" one is to reduce the time spent
> > encoding stuff. We can't really do it in the background as we can't
>
> No, because, per above, if we speed up processing, then the DUT delay
> will have more of a relative effect, not less. If it takes 10 ms on
> average to process every update, then the difference between a 1 ms and
> a 10 ms DUT is a 45% throughput loss. If it takes 100 ms on average to
> process every update, then the difference between a 1 ms and a 10 ms DUT
> is only an 8% throughput loss.
So? We don't want throughput for throughput's sake. Want we want is
sufficient throughput. Anything above that is wasting resources. As to
what is "sufficent", that's certainly up for discussion.
> > That said, perhaps we can consider treating this as a corner case and
> > dial back the aggregation when we are hitting the CPU wall.
>
> Well, ultimately the purpose of
> aggregation/coalescence/whatever-you-want-to-call-it is increased
> performance, so I'm assuming there is data to show that 10 ms performs
> better than 1 ms under certain conditions? I have never seen it to have
> any effect other than a negative one, either on a WAN or a LAN. We
> really need to figure out a way to address these issues quantitatively,
> because I feel like I have a lot of data to show what does and doesn't
> work for 3D and video apps, but there is not the same data to show what
> does and doesn't work for Firefox or OpenOffice or whatever, nor a
> reproducible way to measure the effect of certain design decisions on
> such apps.
It's not just performance. The deferred updates have three purposes:
- Aggregate updates in the hope that we'll get a more efficient
transfer when overlapping or adjacent areas get modified.
- Rate limit the updates to avoid spending CPU and bandwidth on
something that will have little to no perceived effect.
- Avoid partially updated applications by trying to get through the
applications entire update routine before sending anything.
There has not been any thorough investigation in how well it achieves
these goals, no. I messed around with it because it was getting in the
way of my other work. I had two options at that point, remove it or fix
it according to what it was supposed to do. I did not reevaluate its
basic premise.
As for the default setting, it's mostly pulled out of my ass. The old
default of 40 ms seemed like an excessive frame rate limit. And the new
default of 1 ms (which was more of a workaround than an actual setting
given how flaky the old code was) seemed insufficient for applications
that rendered something complex.
> I will also say that LAN usage is not a corner case, and if we treat it
> as such, it will become a self-fulfilling prophesy, because no one will
> want to use TigerVNC on a LAN if it's slow.
It's not a corner case. But it is also not the most important use case.
And LAN doesn't automatically mean infinite bandwidth. In many cases it
just means low latency.
We should balance the needs, make it easier to switch settings
depending on the use case and preferably work towards a system that can
automatically reconfigure itself.
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?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
