On Tue, 28 Apr 2015, Sebastian Moeller wrote:
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?
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.
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
