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

[David Lang]

On Tue, 28 Apr 2015, Sebastian Moeller wrote:

> 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?


lots of this sort of work was done back in the late '80s when ATM was being 
developed and long-distance digital networks were first being deployed.

>
>>
>> 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 ;) )….

I agree we should be aiming for the lowest latency we can reasonably maintain, 
but this topic started with the question of where to put the 'green' band on a 
latency test, and labeling a point as 'VoIP stops working'

base latency + 30-60 ms of buffer induced latency is a reasonble limit, with a 
cap somewhere in the 300-500 ms range (and it can be survived with a cap close 
to 1 sec, as long as the buffer induced latency that causes jitter remains 
small)

As we are looking at what labels to put on the graphs, we need to decide if we 
want to pick examples based on jitter (i.e. relative to base latency) or 
absolutes (total latency)

given the wide variation in base latency due to different technologies, I think 
it would be best to try and use relative latency examples if we can.


Changing topic slightly, I wonder if it would make sense to have an optional 
second column to the results page, that shows a 'known good' or 'best known' 
report to show the user what they could be getting from their connection if they 
were using the right equipment?

David Lang

>>
>> 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.
>>
>
>