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 <[email protected]>
wrote:
Sebastian Moeller <[email protected]> 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
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
