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

[David Lang <david@lang.hm>]

[-- Attachment #1: Type: TEXT/Plain, Size: 3936 bytes --]

On Fri, 24 Apr 2015, jb wrote:

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

The size of the buffer really doesn't matter. The latency is what hurts.

in theory, you could have a massive buffer for some low-priority non-TCP bulk 
protocol (non-TCP so that it can do it's own retries of lost blocks rather then 
the TCP method) with no problem and no impact on the user experience.

the problem is how the buffer is managed, not that it exists.

David Lang

> 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@toke.dk>
> wrote:
>
>> Sebastian Moeller <moeller0@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
>>
>

[-- Attachment #2: Type: TEXT/PLAIN, Size: 140 bytes --]

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat