<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">As I am writing up my slide-pack for LCA2018 this reminded me to test out irtt sleep bench against my running system.<br><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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?<br>---<br>aenertia@kiorewha:~/go/bin$ inxi -C<br>CPU: Quad core Intel Core i7-7700K (-HT-MCP-) cache: 8192 KB<br> clock speeds: max: 4700 MHz 1: 4603 MHz 2: 4616 MHz 3: 4600 MHz 4: 4602 MHz 5: 4601 MHz 6: 4612 MHz<br> 7: 4601 MHz 8: 4600 MHz<br>aenertia@kiorewha:~/go/bin$ uname -a<br>Linux kiorewha 4.15.0-rc7+ #12 SMP Tue Jan 16 20:16:35 NZDT 2018 x86_64 x86_64 x86_64 GNU/Linux<br>aenertia@kiorewha:~/go/bin$ irtt sleep<br>Testing sleep accuracy...<br><br>Sleep Duration Mean Error % Error<br> 1ns 245ns 24586.2<br> 10ns 234ns 2345.1<br> 100ns 10.272µs 10272.9<br> 1µs 52.995µs 5299.6<br> 10µs 53.189µs 531.9<br> 100µs 53.926µs 53.9<br> 1ms 80.973µs 8.1<br> 10ms 86.933µs 0.9<br> 100ms 86.563µs 0.1<br> 200ms 66.967µs 0.0<br> 500ms 64.883µs 0.0<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 December 2017 at 07:36, Dave Taht <span dir="ltr"><<a href="mailto:dave@taht.net" target="_blank">dave@taht.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Luca Muscariello <<a href="mailto:luca.muscariello@gmail.com">luca.muscariello@gmail.com</a>> writes:<br>
<br>
> I think everything is about response time, even throughput.<br>
><br>
> If we compare the time to transmit a single packet from A to B, including<br>
> propagation delay, transmission delay and queuing delay,<br>
> to the time to move a much larger amount of data from A to B we use throughput<br>
> in this second case because it is a normalized<br>
> quantity w.r.t. response time (bytes over delivery time). For a single<br>
> transmission we tend to use latency.<br>
> But in the end response time is what matters.<br>
><br>
> Also, even instantaneous throughput is well defined only for a time scale which<br>
> has to be much larger than the min RTT (propagation + transmission delays)<br>
> Agree also that looking at video, latency and latency budgets are better<br>
> quantities than throughput. At least more accurate.<br>
<span class="">><br>
> On Fri, Dec 8, 2017 at 8:05 AM, Mikael Abrahamsson <<a href="mailto:swmike@swm.pp.se">swmike@swm.pp.se</a>> wrote:<br>
><br>
> On Mon, 4 Dec 2017, <a href="mailto:dpreed@reed.com">dpreed@reed.com</a> wrote:<br>
><br>
> I suggest we stop talking about throughput, which has been the mistaken<br>
> idea about networking for 30-40 years.<br>
><br>
><br>
> We need to talk both about latency and speed. Yes, speed is talked about too<br>
> much (relative to RTT), but it's not irrelevant.<br>
><br>
> Speed of light in fiber means RTT is approx 1ms per 100km, so from Stockholm<br>
> to SFO my RTT is never going to be significantly below 85ms (8625km great<br>
> circle). It's current twice that.<br>
><br>
> So we just have to accept that some services will never be deliverable<br>
> across the wider Internet, but have to be deployed closer to the customer<br>
> (as per your examples, some need 1ms RTT to work well), and we need lower<br>
> access latency and lower queuing delay. So yes, agreed.<br>
><br>
> However, I am not going to concede that speed is "mistaken idea about<br>
> networking". No amount of smarter queuing is going to fix the problem if I<br>
> don't have enough throughput available to me that I need for my application.<br>
<br>
</span>In terms of the bellcurve here, throughput has increased much more<br>
rapidly than than latency has decreased, for most, and in an increasing<br>
majority of human-interactive cases (like video streaming), we often<br>
have enough throughput.<br>
<br>
And the age old argument regarding "just have overcapacity, always"<br>
tends to work in these cases.<br>
<br>
I tend not to care as much about how long it takes for things that do<br>
not need R/T deadlines as humans and as steering wheels do.<br>
<br>
Propigation delay, while ultimately bound by the speed of light, is also<br>
affected by the wires wrapping indirectly around the earth - much slower<br>
than would be possible if we worked at it:<br>
<br>
<a href="https://arxiv.org/pdf/1505.03449.pdf" rel="noreferrer" target="_blank">https://arxiv.org/pdf/1505.<wbr>03449.pdf</a><br>
<br>
Then there's inside the boxes themselves:<br>
<br>
A lot of my struggles of late has been to get latencies and adaquate<br>
sampling techniques down below 3ms (my previous value for starting to<br>
reject things due to having too much noise) - and despite trying fairly<br>
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,<br>
with a video delay of not much more than 2.7ms for AR applications.<br>
<br>
For comparison, an idle quad core aarch64 and dual core x86_64:<br>
<br>
root@nanopineo2:~# irtt sleep<br>
<br>
Testing sleep accuracy...<br>
<br>
Sleep Duration Mean Error % Error<br>
<br>
1ns 13.353µs 1335336.9<br>
<br>
10ns 14.34µs 143409.5<br>
<br>
100ns 13.343µs 13343.9<br>
<br>
1µs 12.791µs 1279.2<br>
<br>
10µs 148.661µs 1486.6<br>
<br>
100µs 150.907µs 150.9<br>
<br>
1ms 168.001µs 16.8<br>
<br>
10ms 131.235µs 1.3<br>
<br>
100ms 145.611µs 0.1<br>
<br>
200ms 162.917µs 0.1<br>
<br>
500ms 169.885µs 0.0<br>
<br>
<br>
d@nemesis:~$ irtt sleep<br>
<br>
Testing sleep accuracy...<br>
<br>
<br>
Sleep Duration Mean Error % Error<br>
<br>
1ns 668ns 66831.9<br>
<br>
10ns 672ns 6723.7<br>
<br>
100ns 557ns 557.6<br>
<br>
1µs 57.749µs 5774.9<br>
<br>
10µs 63.063µs 630.6<br>
<br>
100µs 67.737µs 67.7<br>
<br>
1ms 153.978µs 15.4<br>
<br>
10ms 169.709µs 1.7<br>
<br>
100ms 186.685µs 0.2<br>
<br>
200ms 176.859µs 0.1<br>
<br>
500ms 177.271µs 0.0<br>
<span class="im HOEnZb"><br>
><br>
> --<br>
> Mikael Abrahamsson email: <a href="mailto:swmike@swm.pp.se">swmike@swm.pp.se</a><br>
> ______________________________<wbr>_________________<br>
><br>
><br>
</span><span class="im HOEnZb">> Bloat mailing list<br>
> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Bloat mailing list<br>
> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Cerowrt-devel mailing list<br>
<a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.<wbr>bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/cerowrt-devel</a><br>
</div></div></blockquote></div><br></div>