[Bloat] Re: calculating baseline latency properly?

[Bloat] Re: calculating baseline latency properly?

[David Collier-Brown]

Dave Taht wrote:
> In measuring ping RTT rather than arrival time elsewhere (which I plan
> to do with RTP at some point), there's actually two variables in play
> send and return time...
>
> So should a RTT latency under load calculation remove the baseline latency
> thusly:
>
> latency_improvement =
>   (ping_RTT - baseline_ping_rtt) / (new_ping_RTT - baseline_ping_rtt)
>
> factor 344 improvement
>
> OR keep it:
>
> latency_improvement =
>   (ping_RTT) / (new_ping_RTT)
>
> factor 180 improvement...
>
> or would there be another way to compensate for it that made sense?
>   
If the improvement in the *baseline* ping times is part of the
improvement you're seeing, it's
fair to include it in the calculation.  In other words, if it's causal,
it's golden.  If you're unsure, leave it out.

--dave (random capacity-planning guy) c-b

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain
(416) 223-8968

[Bloat] Re: What is fairness, anyway?

[David Collier-Brown]

Bob Briscoe <bob.briscoe@bt.com> wrote: | All I would add is that in the
family scenario, all the users have control over the hosts which are
already able to control transfer rates. So no-one needs or wants to
twiddle knobs on home gateways to improve family harmony. In the first
instance, app developers have the interests of family harmony at heart.
They don't want to write apps that pee off their users. And if there's a
chance they will be peeved, the app developer can add a knob in the app.

I think separation of concerns is appropriate here: if I want to manage some particular flows in the context of a home network, I'll bring up trickle.  The daemon, not the protocol!  See http://monkey.org/~marius/pages/?page=trickle

Then I get an explicit, user-visible knob to manage any special cases, such as a over-long transfer eating my wife's more important transfer!

--dave c-b

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain
(416) 223-8968