[Bloat] [Cerowrt-devel] DC behaviors today

[Dave Taht]

Luca Muscariello <luca.muscariello at 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 at swm.pp.se> wrote:
>
>     On Mon, 4 Dec 2017, dpreed at 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 at 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 at 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 at swm.pp.se
>     _______________________________________________
>     
>     
>     Bloat mailing list
>     Bloat at lists.bufferbloat.net
>     https://lists.bufferbloat.net/listinfo/bloat
>     
>
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat