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

[jb]

Don't you want to accuse the size of the buffer, rather than the latency?

For example, say someone has some hardware and their line is fairly slow.
it might be RED on the graph because the buffer is quite big relative to the
bandwidth delay product of the line. A test is telling them they have
bloated buffers.

Then they upgrade their product speed to a much faster product, and suddenly
that buffer is fairly small, the incremental latency is low, and no longer
shows
RED on a test.

What changed? the hardware didn't change. Just the speed changed. So the
test is saying that for your particular speed, the buffers are too big. But
for a
higher speed, they may be quite ok.

If you add 100ms to a 1gigabit product the buffer has to be what, ~10mb?
but adding 100ms to my feeble line is quite easy, the billion router can
have
a buffer of just 100kb and it is too high. But that same billion in front
of a
gigabit modem is only going to add at most 1ms to latency and nobody
would complain.

Ok I think I talked myself around in a complete circle: a buffer is only
bad IF
it increases latency under load. Not because of its size. It might explain
why
these fiber connection tests don't show much latency change, because
their buffers are really inconsequential at those higher speeds?


On Fri, Apr 24, 2015 at 7:02 PM, Toke Høiland-Jørgensen <toke at toke.dk>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20150424/430a51e4/attachment-0002.html>