[Bloat] DSLReports Speed Test has latency measurement built-in

[Sebastian Moeller]

Hi David,

On Apr 28, 2015, at 10:01 , David Lang <david at lang.hm> wrote:

> On Tue, 28 Apr 2015, Sebastian Moeller wrote:
> 
>>> 
>>> I consider induced latencies of 30ms as a "green" band because that is
>>> the outer limit of the range modern aqm technologies can achieve (fq
>>> can get closer to 0). There was a lot of debate about 20ms being the
>>> right figure for induced latency and/or jitter, a year or two back,
>>> and we settled on 30ms for both, so that number is already a
>>> compromise figure.
>> 
>> 	Ah, I think someone brought this up already, do we need to make allowances for slow links? If a full packet traversal is already 16ms can we really expect 30ms? And should we even care, I mean, a slow link is a slow link and will have some drawbacks maybe we should just expose those instead of rationalizing them away? On the other hand I tend to think that in the end it is all about the cumulative performance of the link for most users, i.e. if the link allows glitch-free voip while heavy up- and downloads go on, normal users should not care one iota what the induced latency actually is (aqm or no aqm as long as the link behaves well nothing needs changing)
>> 
>>> 
>>> It is highly likely that folk here are not aware of the extra-ordinary
>>> amount of debate that went into deciding the ultimate ATM cell size
>>> back in the day. The eu wanted 32 bytes, the US 48, both because that
>>> was basically a good size for the local continental distance and echo
>>> cancellation stuff, at the time.
>>> 
>>> In the case of voip, jitter is actually more important than latency.
>>> Modern codecs and coding techniques can tolerate 30ms of jitter, just
>>> barely, without sound artifacts. >60ms, boom, crackle, hiss.
>> 
>> 	Ah, and here is were I understand why my simplistic model from above fails; induced latency will contribute significantly to jitter and hence is a good proxy for link-suitability for real-time applications. So I agree using the induced latency as measure to base the color bands from sounds like a good approach.
>> 
> 
> Voice is actually remarkably tolerant of pure latency. While 60ms of jitter makes a connection almost unusalbe, a few hundred ms of consistant latency isn't a problem. IIRC (from my college days when ATM was the new, hot technology) you have to get up to around a second of latency before pure-consistant latency starts to break things.

	Well, what I want to see is a study, preferably psychophysics not modeling ;), showing the different latency “tolerances” of humans. I am certain that humans can adjust to even dozens of seconds de;ays if need be, but the goal should be fluent and seamless conversation not interleaved monologues. Thanks for giving a bound for jitter, do you have any reference for perceptional jitter thresholds or some such?


> 
> Gaming and high frequency trading care about the minimum latency a LOT. but most other things are far more sentitive to jitter than pure latency. [1]

	Sure, but it is easy to “loose” latency but impossible to reclaim, so we should aim for lowest latency ;) . Now as long as jitter has a bound one can trade jitter for latency, by simply buffering more at the receiver thereby ironing out (a part of the) the jitter while introducing additional latency. One reason why I still thing that absolute latency thresholds have some value as they would allow to assess how much of a “budget” one has to flatten out jitter, but I digress. I also think now, that conflating absolute latency and buffer bloat will not really help (unless everybody understands induced latency by heart ;) )….

> 
> The trouble with bufferbloat induced latency is that it is highly variable based on exactly how much other data is in the queue, so under the wrong conditions, all latency caused by buffering shows up as jitter.

	That is how I understood Dave’s mail, thanks for confirming that.

Best Regards
	Sebastian

> 
> David Lang
> 
> [1] pure latency will degrade the experience for many things, but usually in a fairly graceful manner.
>