[Cerowrt-devel] [Bloat] 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/cerowrt-devel/attachments/20180121/ab79952a/attachment.html>
More information about the Cerowrt-devel
mailing list