[Bloat] [Cerowrt-devel] DC behaviors today

Joel Wirāmu Pauling joel at aenertia.net
Sat Jan 20 06:55:04 EST 2018


As I am writing up my slide-pack for LCA2018 this reminded me to test out
irtt sleep bench against my running system.

Seems either the Skylake Parts are much better in Combination with current
kernels at this than what you were running on - what is the kernel of the
x86 result?
---
aenertia at kiorewha:~/go/bin$ inxi -C
CPU:       Quad core Intel Core i7-7700K (-HT-MCP-) cache: 8192 KB
           clock speeds: max: 4700 MHz 1: 4603 MHz 2: 4616 MHz 3: 4600 MHz
4: 4602 MHz 5: 4601 MHz 6: 4612 MHz
           7: 4601 MHz 8: 4600 MHz
aenertia at kiorewha:~/go/bin$ uname -a
Linux kiorewha 4.15.0-rc7+ #12 SMP Tue Jan 16 20:16:35 NZDT 2018 x86_64
x86_64 x86_64 GNU/Linux
aenertia at kiorewha:~/go/bin$ irtt sleep
Testing sleep accuracy...

Sleep Duration        Mean Error       % Error
           1ns             245ns       24586.2
          10ns             234ns        2345.1
         100ns          10.272µs       10272.9
           1µs          52.995µs        5299.6
          10µs          53.189µs         531.9
         100µs          53.926µs          53.9
           1ms          80.973µs           8.1
          10ms          86.933µs           0.9
         100ms          86.563µs           0.1
         200ms          66.967µs           0.0
         500ms          64.883µs           0.0


On 13 December 2017 at 07:36, Dave Taht <dave at taht.net> wrote:

>
> 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
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20180121/ab79952a/attachment.html>


More information about the Bloat mailing list