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

[Sebastian Moeller]

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