Re: [Bloat] [Cerowrt-devel] DC behaviors today

[Luca Muscariello <luca.muscariello@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6798 bytes --]

+1 on all.
Except that Little's Law is very general as it applies to any ergodic
process.
It just derives from the law of large numbers. And BTW, Little's law is a
very powerful law.
We use it unconsciously all the time.



On Tue, Dec 12, 2017 at 11:53 PM, <dpreed@reed.com> wrote:

> Luca's point tends to be correct - variable latency destroys the stability
> of flow control loops, which destroys throughput, even when there is
> sufficient capacity to handle the load.
>
>
>
> This is an indirect result of Little's Lemma (which is strictly true only
> for Poisson arrival, but almost any arrival process will have a similar
> interaction between latency and throughput).
>
>
>
> However, the other reason I say what I say so strongly is this:
>
>
>
> Rant on.
>
>
>
> Peak/avg. load ratio always exceeds a factor of 10 or more, IRL. Only
> "benchmark setups" (or hot-rod races done for academic reasons or marketing
> reasons to claim some sort of "title") operate at peak supportable load any
> significant part of the time.
>
>
>
> The reason for this is not just "fat pipes are better", but because
> bitrate of the underlying medium is an insignificant fraction of systems
> operational and capital expense.
>
>
>
> SLA's are specified in "uptime" not "bits transported", and a clogged pipe
> is defined as down when latency exceeds a small number.
>
>
>
> Typical operating points of corporate networks where the users are happy
> are single-digit percentage of max load.
>
>
>
> This is also true of computer buses and memory controllers and storage
> interfaces IRL. Again, latency is the primary measure, and the system never
> focuses on operating points anywhere near max throughput.
>
>
>
> Rant off.
>
>
> On Tuesday, December 12, 2017 1:36pm, "Dave Taht" <dave@taht.net> said:
>
> >
> > Luca Muscariello <luca.muscariello@gmail.com> writes:
> >
> > > I think everything is about response time, even throughput.
> > >
> > > If we compare the time to transmit a single packet from A to B,
> including
> > > propagation delay, transmission delay and queuing delay,
> > > to the time to move a much larger amount of data from A to B we use
> > throughput
> > > in this second case because it is a normalized
> > > quantity w.r.t. response time (bytes over delivery time). For a single
> > > transmission we tend to use latency.
> > > But in the end response time is what matters.
> > >
> > > Also, even instantaneous throughput is well defined only for a time
> scale
> > which
> > > has to be much larger than the min RTT (propagation + transmission
> delays)
> > > Agree also that looking at video, latency and latency budgets are
> better
> > > quantities than throughput. At least more accurate.
> > >
> > > On Fri, Dec 8, 2017 at 8:05 AM, Mikael Abrahamsson <swmike@swm.pp.se>
> > wrote:
> > >
> > > On Mon, 4 Dec 2017, dpreed@reed.com wrote:
> > >
> > > I suggest we stop talking about throughput, which has been the
> > mistaken
> > > idea about networking for 30-40 years.
> > >
> > >
> > > We need to talk both about latency and speed. Yes, speed is talked
> about
> > too
> > > much (relative to RTT), but it's not irrelevant.
> > >
> > > Speed of light in fiber means RTT is approx 1ms per 100km, so from
> > Stockholm
> > > to SFO my RTT is never going to be significantly below 85ms (8625km
> > great
> > > circle). It's current twice that.
> > >
> > > So we just have to accept that some services will never be deliverable
> > > across the wider Internet, but have to be deployed closer to the
> > customer
> > > (as per your examples, some need 1ms RTT to work well), and we need
> > lower
> > > access latency and lower queuing delay. So yes, agreed.
> > >
> > > However, I am not going to concede that speed is "mistaken idea about
> > > networking". No amount of smarter queuing is going to fix the problem
> if
> > I
> > > don't have enough throughput available to me that I need for my
> > application.
> >
> > In terms of the bellcurve here, throughput has increased much more
> > rapidly than than latency has decreased, for most, and in an increasing
> > majority of human-interactive cases (like video streaming), we often
> > have enough throughput.
> >
> > And the age old argument regarding "just have overcapacity, always"
> > tends to work in these cases.
> >
> > I tend not to care as much about how long it takes for things that do
> > not need R/T deadlines as humans and as steering wheels do.
> >
> > Propigation delay, while ultimately bound by the speed of light, is also
> > affected by the wires wrapping indirectly around the earth - much slower
> > than would be possible if we worked at it:
> >
> > https://arxiv.org/pdf/1505.03449.pdf
> >
> > Then there's inside the boxes themselves:
> >
> > A lot of my struggles of late has been to get latencies and adaquate
> > sampling techniques down below 3ms (my previous value for starting to
> > reject things due to having too much noise) - and despite trying fairly
> > hard, well... a process can't even sleep accurately much below 1ms, on
> > bare metal linux. A dream of mine has been 8 channel high quality audio,
> > with a video delay of not much more than 2.7ms for AR applications.
> >
> > For comparison, an idle quad core aarch64 and dual core x86_64:
> >
> > root@nanopineo2:~# irtt sleep
> >
> > Testing sleep accuracy...
> >
> > Sleep Duration Mean Error % Error
> >
> > 1ns 13.353µs 1335336.9
> >
> > 10ns 14.34µs 143409.5
> >
> > 100ns 13.343µs 13343.9
> >
> > 1µs 12.791µs 1279.2
> >
> > 10µs 148.661µs 1486.6
> >
> > 100µs 150.907µs 150.9
> >
> > 1ms 168.001µs 16.8
> >
> > 10ms 131.235µs 1.3
> >
> > 100ms 145.611µs 0.1
> >
> > 200ms 162.917µs 0.1
> >
> > 500ms 169.885µs 0.0
> >
> >
> > d@nemesis:~$ irtt sleep
> >
> > Testing sleep accuracy...
> >
> >
> > Sleep Duration Mean Error % Error
> >
> > 1ns 668ns 66831.9
> >
> > 10ns 672ns 6723.7
> >
> > 100ns 557ns 557.6
> >
> > 1µs 57.749µs 5774.9
> >
> > 10µs 63.063µs 630.6
> >
> > 100µs 67.737µs 67.7
> >
> > 1ms 153.978µs 15.4
> >
> > 10ms 169.709µs 1.7
> >
> > 100ms 186.685µs 0.2
> >
> > 200ms 176.859µs 0.1
> >
> > 500ms 177.271µs 0.0
> >
> > >
> > > --
> > > Mikael Abrahamsson email: swmike@swm.pp.se
> > > _______________________________________________
> > >
> > >
> > > Bloat mailing list
> > > Bloat@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/bloat
> > >
> > >
> > >
> > > _______________________________________________
> > > Bloat mailing list
> > > Bloat@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/bloat
> >
>

[-- Attachment #2: Type: text/html, Size: 10020 bytes --]