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

[Toke Høiland-Jørgensen]

Sebastian Moeller <moeller0 at gmx.de> writes:

> 	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 ;).

Well I agree that this is relevant information in relation to the total
link latency. But keeping the issues separate has value, I think,
because you can potentially fix your bufferbloat, but increasing the
speed of light to get better base latency on your satellite link is
probably out of scope for now (or at least for a couple of hundred more
years: http://theinfosphere.org/Speed_of_light).

> 	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 ;) )

Oh, I'm all for fixed thresholds! As I said, the goal should be (close
to) zero added latency...

> 	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?

Yup, something like that :)

-Toke