Hi David,
On Apr 28, 2015, at 10:01 , David Lang <[email protected]> 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.
>
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
