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

[Simon Barber]

Certainly the VoIP numbers are for peak total latency, and while Justin is 
measuring total latency because he is only taking a few samples the peak 
values will be a little higher.

Simon

Sent with AquaMail for Android
http://www.aqua-mail.com


On April 24, 2015 9:04:45 PM Dave Taht <dave.taht at gmail.com> wrote:

> simon all your numbers are too large by at least a factor of 2. I
> think also you are thinking about total latency, rather than induced
> latency and jitter.
>
> Please see my earlier email laying out the bands. And gettys' manifesto.
>
> If you are thinking in terms of voip, less than 30ms *jitter* is what
> you want, and a latency increase of 30ms is a proxy for also holding
> jitter that low.
>
>
> On Fri, Apr 24, 2015 at 8:15 PM, Simon Barber <simon at superduper.net> wrote:
> > 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 <toke at toke.dk> wrote:
> >>
> >>> Sebastian Moeller <moeller0 at gmx.de> 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
> >> Bloat at lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/bloat
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
> Dave Täht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67