+1 on all. Except that Little's Law is very general as it applies to any ergodic process. It just derives from the law of large numbers. And BTW, Little's law is a very powerful law. We use it unconsciously all the time.
On Tue, Dec 12, 2017 at 11:53 PM, <dpr...@reed.com> wrote: > 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. > > > > 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). > > > > However, the other reason I say what I say so strongly is this: > > > > Rant on. > > > > 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. > > > > 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. > > > > SLA's are specified in "uptime" not "bits transported", and a clogged pipe > is defined as down when latency exceeds a small number. > > > > Typical operating points of corporate networks where the users are happy > are single-digit percentage of max load. > > > > 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. > > > > Rant off. > > > On Tuesday, December 12, 2017 1:36pm, "Dave Taht" <d...@taht.net> said: > > > > > Luca Muscariello <luca.muscarie...@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 <swm...@swm.pp.se> > > wrote: > > > > > > On Mon, 4 Dec 2017, dpr...@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@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@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: swm...@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 > > >
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat