<div dir="ltr">+1 on all.<div>Except that Little's Law is very general as it applies to any ergodic process.</div><div>It just derives from the law of large numbers. And BTW, Little's law is a very powerful law.</div><div>We use it unconsciously all the time.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 12, 2017 at 11:53 PM,  <span dir="ltr"><<a href="mailto:dpreed@reed.com" target="_blank">dpreed@reed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="verdana" size="2"><p style="margin:0;padding:0;font-family:verdana;font-size:10pt">Luca's point tends to be correct - variable latency destroys the stability of flow control loops, which destroys throughput, even when there is sufficient capacity to handle the load.</p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt"> </p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt">This is an indirect result of Little's Lemma (which is strictly true only for Poisson arrival, but almost any arrival process will have a similar interaction between latency and throughput).</p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt"> </p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt">However, the other reason I say what I say so strongly is this:</p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt"> </p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt">Rant on.</p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt"> </p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt">Peak/avg. load ratio always exceeds a factor of 10 or more, IRL. Only "benchmark setups" (or hot-rod races done for academic reasons or marketing reasons to claim some sort of "title") operate at peak supportable load any significant part of the time.</p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt"> </p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt">The reason for this is not just "fat pipes are better", but because bitrate of the underlying medium is an insignificant fraction of systems operational and capital expense.</p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt"> </p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt">SLA's are specified in "uptime" not "bits transported", and a clogged pipe is defined as down when latency exceeds a small number.</p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt"> </p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt">Typical operating points of corporate networks where the users are happy are single-digit percentage of max load.</p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt"> </p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt">This is also true of computer buses and memory controllers and storage interfaces IRL. Again, latency is the primary measure, and the system never focuses on operating points anywhere near max throughput.</p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt"> </p>
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt">Rant off.</p><div><div class="h5"><br><br>On Tuesday, December 12, 2017 1:36pm, "Dave Taht" <<a href="mailto:dave@taht.net" target="_blank">dave@taht.net</a>> said:<br><br></div></div><p></p><div><div class="h5">
<div id="m_-635720945056357378SafeStyles1513118484">
<p style="margin:0;padding:0;font-family:verdana;font-size:10pt">> <br>> Luca Muscariello <<a href="mailto:luca.muscariello@gmail.com" target="_blank">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<br>> 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<br>> 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>> ><br>> > On Fri, Dec 8, 2017 at 8:05 AM, Mikael Abrahamsson <<a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a>><br>> wrote:<br>> ><br>> > On Mon, 4 Dec 2017, <a href="mailto:dpreed@reed.com" target="_blank">dpreed@reed.com</a> wrote:<br>> ><br>> > I suggest we stop talking about throughput, which has been the<br>> 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<br>> 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<br>> Stockholm<br>> > to SFO my RTT is never going to be significantly below 85ms (8625km<br>> 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<br>> customer<br>> > (as per your examples, some need 1ms RTT to work well), and we need<br>> 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<br>> I<br>> > don't have enough throughput available to me that I need for my<br>> application.<br>> <br>> 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" 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>> <br>> ><br>> > --<br>> > Mikael Abrahamsson email: <a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a><br>> > ______________________________<wbr>_________________<br>> ><br>> ><br>> > Bloat mailing list<br>> > <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>> > <a href="https://lists.bufferbloat.net/listinfo/bloat" 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" target="_blank">Bloat@lists.bufferbloat.net</a><br>> > <a href="https://lists.bufferbloat.net/listinfo/bloat" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>> </p>
</div></div></div></font></blockquote></div><br></div>