From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 566AC3CB3E for ; Sat, 20 Jan 2018 06:55:25 -0500 (EST) Received: by mail-yw0-x232.google.com with SMTP id m84so1628480ywd.5 for ; Sat, 20 Jan 2018 03:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aenertia.net; s=dkimaenertianet; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rUORyBztV1DzK53Nci9IB4rjSiLozcRHAg81EgcMHFo=; b=fJzUJKwnW8WN+jukE7yPpFZdinN9v/arbsSo335s1/RR4LvlaQOPJS9WwBkM6FioLe SBm1SpvRQ05l8HYcKR5ldgN1RVbgWbMONpfpe4wLqCb/UYnhaXoz5WBuE20UJhbGztls oQDjZxiIQeICG/LQouC1R/nfQvRMUjCcBYDHs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rUORyBztV1DzK53Nci9IB4rjSiLozcRHAg81EgcMHFo=; b=OqiHJruEzxKcN+eILvn0gHxSbMZNB4zPDqCpncSh9Njd919J8cvedrhqvbBu5Il9Wv nyxMZOhjZfYRrKdkmedGFvn++aK6Upv5aOV/1YVd+qZoIo7fQYNSo3Jc+ce2Wq/dhSbe RfbiLmeZRKUmnbx1Uh7ybfV4u5FnZJbUK0llaUrqx/8l9MsE39zYdpuspqD+W9fyakLS FyfjnuAec7HcASDUEEWgMFvR/pjyvxvGlBwBarq4KdKLkutPLTcxAdTFPQrWYcA/s80N Bys2helMdo27t9P5Z9yTeBgfOkaU2eegFMUE+SiOs+fM5QMIFTx4FOReiD8EnWG91nBg wTig== X-Gm-Message-State: AKwxytfJYCfEYlKe2huGkgnZDY38YF3coeKSpQXGgZMsQvnGiuXdbxBl bbjmWzlpwKZfLw6ny7OeTlxqMHddeRw65cib78a7Bw== X-Google-Smtp-Source: AH8x224e9PSW/NKznAOqD/Urx0Y7tx0Sm9KsfRKNkk3j46o8dNtMYXpn+lgJp/bggw3rq9mAEE+tfIGBrxtCTU2bbiA= X-Received: by 10.129.141.7 with SMTP id d7mr1338322ywg.284.1516449324617; Sat, 20 Jan 2018 03:55:24 -0800 (PST) MIME-Version: 1.0 Sender: aenertia@aenertia.net Received: by 10.37.77.5 with HTTP; Sat, 20 Jan 2018 03:55:04 -0800 (PST) In-Reply-To: <87wp1rbxo8.fsf@nemesis.taht.net> References: <92906bd8-7bad-945d-83c8-a2f9598aac2c@lackof.org> <87bmjff7l6.fsf_-_@nemesis.taht.net> <1512417597.091724124@apps.rackspace.com> <87wp1rbxo8.fsf@nemesis.taht.net> From: =?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?= Date: Sun, 21 Jan 2018 00:55:04 +1300 X-Google-Sender-Auth: Nvc9kIojq6FLbz07f5B1sD4oFuY Message-ID: To: Dave Taht Cc: Luca Muscariello , bloat , "cerowrt-devel@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary="f403045e5fe6506898056333df2d" Subject: Re: [Bloat] [Cerowrt-devel] DC behaviors today X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2018 11:55:25 -0000 --f403045e5fe6506898056333df2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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@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@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@kiorewha:~/go/bin$ irtt sleep Testing sleep accuracy... Sleep Duration Mean Error % Error 1ns 245ns 24586.2 10ns 234ns 2345.1 100ns 10.272=C2=B5s 10272.9 1=C2=B5s 52.995=C2=B5s 5299.6 10=C2=B5s 53.189=C2=B5s 531.9 100=C2=B5s 53.926=C2=B5s 53.9 1ms 80.973=C2=B5s 8.1 10ms 86.933=C2=B5s 0.9 100ms 86.563=C2=B5s 0.1 200ms 66.967=C2=B5s 0.0 500ms 64.883=C2=B5s 0.0 On 13 December 2017 at 07:36, Dave Taht wrote: > > Luca Muscariello writes: > > > I think everything is about response time, even throughput. > > > > If we compare the time to transmit a single packet from A to B, includi= ng > > 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 bette= r > > quantities than throughput. At least more accurate. > > > > On Fri, Dec 8, 2017 at 8:05 AM, Mikael Abrahamsson > 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 abo= ut > > 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=C2=B5s 1335336.9 > > 10ns 14.34=C2=B5s 143409.5 > > 100ns 13.343=C2=B5s 13343.9 > > 1=C2=B5s 12.791=C2=B5s 1279.2 > > 10=C2=B5s 148.661=C2=B5s 1486.6 > > 100=C2=B5s 150.907=C2=B5s 150.9 > > 1ms 168.001=C2=B5s 16.8 > > 10ms 131.235=C2=B5s 1.3 > > 100ms 145.611=C2=B5s 0.1 > > 200ms 162.917=C2=B5s 0.1 > > 500ms 169.885=C2=B5s 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=C2=B5s 57.749=C2=B5s 5774.9 > > 10=C2=B5s 63.063=C2=B5s 630.6 > > 100=C2=B5s 67.737=C2=B5s 67.7 > > 1ms 153.978=C2=B5s 15.4 > > 10ms 169.709=C2=B5s 1.7 > > 100ms 186.685=C2=B5s 0.2 > > 200ms 176.859=C2=B5s 0.1 > > 500ms 177.271=C2=B5s 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 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --f403045e5fe6506898056333df2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I am writing up my slide-pack for LCA2018 this reminded me t= o test out irtt sleep bench against my running system.

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

Sleep Duration=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Me= an Error=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 % Error
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1ns=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 245ns=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 24586.2
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 10ns=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 234ns=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2345.1
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 100ns=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 10.272=C2=B5s=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = 10272.9
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1= =C2=B5s=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 52.995=C2=B5s= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 5299.6
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 10=C2=B5s=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 53.189=C2=B5s=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 531.9
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 100= =C2=B5s=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 53.926=C2=B5s= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 53.9
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1ms=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 80.973=C2=B5s=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 8.1
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 10ms=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 86.933=C2=B5s=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 0.9
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 100ms=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 86.563=C2=B5s=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0.1
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 200ms=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 66.967=C2=B5s=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 0.0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 500= ms=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 64.883=C2=B5s=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0.0

=

On 13 Decem= ber 2017 at 07:36, Dave Taht <dave@taht.net> wrote:

Luca Muscariello <luca.mus= cariello@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, includ= ing
> propagation delay, transmission delay and queuing delay,
> to the time to move a much larger amount of data from A to B we use th= roughput
> 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 sc= ale which
> has to be much larger than the min RTT (propagation + transmission del= ays)
> Agree also that looking at video, latency and latency budgets are bett= er
> quantities than throughput. At least more accurate.
>
> On Fri, Dec 8, 2017 at 8:05 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On Mon, 4 Dec 2017, dpreed@reed.com wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I suggest we stop talking about throu= ghput, which has been the mistaken
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0idea about networking for 30-40 years= .
>
>
>=C2=A0 =C2=A0 =C2=A0We need to talk both about latency and speed. Yes, = speed is talked about too
>=C2=A0 =C2=A0 =C2=A0much (relative to RTT), but it's not irrelevant= .
>
>=C2=A0 =C2=A0 =C2=A0Speed of light in fiber means RTT is approx 1ms per= 100km, so from Stockholm
>=C2=A0 =C2=A0 =C2=A0to SFO my RTT is never going to be significantly be= low 85ms (8625km great
>=C2=A0 =C2=A0 =C2=A0circle). It's current twice that.
>
>=C2=A0 =C2=A0 =C2=A0So we just have to accept that some services will n= ever be deliverable
>=C2=A0 =C2=A0 =C2=A0across the wider Internet, but have to be deployed = closer to the customer
>=C2=A0 =C2=A0 =C2=A0(as per your examples, some need 1ms RTT to work we= ll), and we need lower
>=C2=A0 =C2=A0 =C2=A0access latency and lower queuing delay. So yes, agr= eed.
>
>=C2=A0 =C2=A0 =C2=A0However, I am not going to concede that speed is &q= uot;mistaken idea about
>=C2=A0 =C2=A0 =C2=A0networking". No amount of smarter queuing is g= oing to fix the problem if I
>=C2=A0 =C2=A0 =C2=A0don't have enough throughput available to me th= at 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&quo= t;
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<= br> 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=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mean Error=C2=A0 =C2=A0 =C2=A0 = =C2=A0% Error

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01ns=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 13.353=C2=B5s=C2=A0 =C2=A0 =C2=A01335336.9

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10ns=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A014.34=C2=B5s=C2=A0 =C2=A0 =C2=A0 143409.5

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0100ns=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1= 3.343=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A013343.9

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 12.791=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 1279.2

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0148.661=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 1486.6

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0100=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0150.907=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0150.9

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01ms=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0168.001=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16.8

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10ms=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A013= 1.235=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.3

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0100ms=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A014= 5.611=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.1

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0200ms=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A016= 2.917=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.1

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0500ms=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A016= 9.885=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.0


d@nemesis:~$ irtt sleep

Testing sleep accuracy...


Sleep Duration=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mean Error=C2=A0 =C2=A0 =C2=A0 = =C2=A0% Error

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01ns=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0668ns=C2=A0 =C2=A0 =C2=A0 =C2=A066831.9

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10ns=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0672ns=C2=A0 =C2=A0 =C2=A0 =C2=A0 6723.7

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0100ns=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0557ns=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0557.6

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 57.749=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 5774.9

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 63.063=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0630.6

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0100=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 67.737=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 67.7

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01ms=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0153.978=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15.4

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10ms=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A016= 9.709=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.7

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0100ms=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A018= 6.685=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.2

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0200ms=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A017= 6.859=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.1

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0500ms=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A017= 7.271=C2=B5s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00.0

>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Mikael Abrahamsson email: swmike@swm.pp.se
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>
>
>=C2=A0 =C2=A0 =C2=A0Bloat mailing list=
>=C2=A0 =C2=A0 =C2=A0Bloa= t@lists.bufferbloat.net
>=C2=A0 =C2=A0 =C2=A0https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat= .net
> https://lists.bufferbloat.net/listinfo/bloat
____________________________= ___________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cero= wrt-devel

--f403045e5fe6506898056333df2d--