On 28/07/15 15:49, Eric Dumazet wrote:
On Tue, 2015-07-28 at 07:31 -0700, Simon Barber wrote:
The issue is that Codel tries to keep the delay low, and will start
dropping when sojourn time grows above 5ms for 100ms. For longer RTT links
more delay is necessary to avoid underutilizing the link. This is due to
the multiplicative decrease - it's worst with Reno, where the halving of
cWind means that you need to have a full BDP of data in the buffer to avoid
the link going idle when cWind is halved. With longer RTTs this means more
delay than Codel allows is required to avoid a throughput hit. The worst
case happens when a single flow is controlled, but that can be a common
situation. My proposal is to sense and have the target value in Codel
automatically adjust when this worst case scenario happens - which would
mitigate most of the downside.
As I said, I've never seen what you describe.
100ms value is not a go/nogo threshold. It is a hint, based on real
world values. We are speaking of 100 ms sojourn time in the CoDel queue,
not sojourn time in the Internet !
You can still have flows with 500 ms or even 10 sec rtt and codel just
works fine.
Are you sure you understood how this was working ?
The codel paper indicates utilization dropoff as RTT increases above the
'interval' (and that interval is set based on expected rtt). They
presented an average of several loads, so this wasn't even the
single-stream worst case.
200ms rtt was fine, 500ms was a slightly worse & varied a lot more.
If you wanted something that was "fine" at 10s (ow), you wouldn't want
codel's defaults. Tuning higher values in fq_codel would probably be
enough though.
http://queue.acm.org/detail.cfm?id=2209336
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
