Dave,
your presentation was awesome, I fully agree with you ;). I very much liked
your practical funnel demonstration which was boiled down to the bare minimum
(I only partly asked myself, will the liquid spill in in your laptops keyboard,
and if so is it water-proof, but you clearly had rehearsed/tried that before).
BTW, I always have to think of this h++ps://www.youtube.com/watch?v=R7yfISlGLNU
somehow when you present live from the marina ;)
I am still not through watching all of the presentations and panels, but can
already say, team L4S continues to over-promise and under-deliver, but Koen's
presentation itself was done well and might (sadly) convince people to buy-in
into L4(S) = 2L2L = too little, too late.
Stuart's RPM presentation was great, making a convincing point. (Except for
pitching L4S and LLD as "solutions", I will accept them as a step in the right
direction, but why not go in all the way and embrace proper scheduling?)
In detail though, I am not fully convinced about the decision of taking the
inverse of delay increase as singular measure here as I consider that as a bit
of a squandered opportunity at public outreach/education and as comparing idle
and working RPM is non-intuitive, while idle and working RTT can immediately
subtracted to see the extent of the queueing damage in actionable terms.
Try the same with RPM values:
123-1234567:~ user$ networkQuality -v
==== SUMMARY ====
Upload capacity: 22.208 Mbps
Download capacity: 88.054 Mbps
Upload flows: 12
Download flows: 12
Responsiveness: High (2622 RPM)
Base RTT: 18
Start: 3/12/23, 21:00:58
End: 3/12/23, 21:01:08
OS Version: Version 12.6.3 (Build 21G419)
here we can divide 60 [sec/minute] * 1000 [ms/sec] by the RPM [1/min] to get:
60000/2622 = 22.88 ms loaded delay and subtract the base RTT of 18 for
60000/2622 - 18 = 4.88 ~5ms of loaded delay which is a useful quantity when
managing a delay budget (this test was performed over wired ethernet with
competent AQM and traffic shaping on the link, so no surprise about the outcome
there). Let's look at the reverse and convert the base RTT into a base RPM
score instead: 6000/18 = 333 rpm, what exactly does the delta RPM of 2622-333 =
2289rpm now tell us about the difference between idle and working conditions?
[Well, since conversion is not witchcraft, I will be fine as will other
interested in actual evoked delay, but we could have gotten a better measure*]
And all for the somewhat unhelpful car analogy... (it is not that for internal
combustion engines bigger is necessarily better for RPM, either for torque or
fuel efficiency).
I guess that ship has sailed though and RPM it is
*) Stuart notes that milliseconds and Hertz sound to sciency, but they could
simply have given the delay increase in milliseconds a fancier name to solve
that specific problem...
> On Mar 12, 2023, at 20:31, Dave Taht via Rpm <r...@lists.bufferbloat.net>
> wrote:
>
> https://www.reddit.com/r/HomeNetworking/comments/11pmc9a/comment/jbypj0z/?context=3
>
> --
> Come Heckle Mar 6-9 at: https://www.understandinglatency.com/
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Rpm mailing list
> r...@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
