I think it might be useful to have a 'latency guide' for users. It would
say things like
100ms - VoIP applications work well
250ms - VoIP applications - conversation is not as natural as it could
be, although users may not notice this.
500ms - VoIP applications begin to have awkward pauses in conversation.
1000ms - VoIP applications have significant annoying pauses in conversation.
2000ms - VoIP unusable for most interactive conversations.
0-50ms - web pages load snappily
250ms - web pages can often take an extra second to appear, even on the
highest bandwidth links
1000ms - web pages load significantly slower than they should, taking
several extra seconds to appear, even on the highest bandwidth links
2000ms+ - web browsing is heavily slowed, with many seconds or even 10s
of seconds of delays for pages to load, even on the highest bandwidth links.
Gaming.... some kind of guide here....
Simon
On 4/24/2015 1:55 AM, Sebastian Moeller wrote:
Hi Toke,
On Apr 24, 2015, at 10:29 , Toke Høiland-Jørgensen <[email protected]> wrote:
Sebastian Moeller <[email protected]> writes:
I know this is not perfect and the numbers will probably require
severe "bike-shedding”
Since you're literally asking for it... ;)
In this case we're talking about *added* latency. So the ambition should
be zero, or so close to it as to be indiscernible. Furthermore, we know
that proper application of a good queue management algorithm can keep it
pretty close to this. Certainly under 20-30 ms of added latency. So from
this, IMO the 'green' or 'excellent' score should be from zero to 30 ms.
Oh, I can get behind that easily, I just thought basing the limits on
externally relevant total latency thresholds would directly tell the user which
applications might run well on his link. Sure this means that people on a
satellite link most likely will miss out the acceptable voip threshold by their
base-latency alone, but guess what telephony via satellite leaves something to
be desired. That said if the alternative is no telephony I would take 1 second
one-way delay any day ;).
What I liked about fixed thresholds is that the test would give a good
indication what kind of uses are going to work well on the link under load,
given that during load both base and induced latency come into play. I agree
that 300ms as first threshold is rather unambiguous though (and I am certain
that remote X11 will require a massively lower RTT unless one likes to think of
remote desktop as an oil tanker simulator ;) )
The other increments I have less opinions about, but 100 ms does seem to
be a nice round number, so do yellow from 30-100 ms, then start with the
reds somewhere above that, and range up into the deep red / purple /
black with skulls and fiery death as we go nearer and above one second?
I very much think that raising peoples expectations and being quite
ambitious about what to expect is an important part of this. Of course
the base latency is going to vary, but the added latency shouldn't. And
sine we have the technology to make sure it doesn't, calling out bad
results when we see them is reasonable!
Okay so this would turn into:
base latency to base latency + 30 ms: green
base latency + 31 ms to base latency + 100 ms: yellow
base latency + 101 ms to base latency + 200 ms: orange?
base latency + 201 ms to base latency + 500 ms: red
base latency + 501 ms to base latency + 1000 ms: fire
base latency + 1001 ms to infinity: fire &
brimstone
correct?
-Toke
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
