[Cerowrt-devel] uplink_buffer_adjustment

dpreed at reed.com dpreed at reed.com
Tue Feb 25 16:27:25 EST 2014

I've measured buffer size with TCP, when there is no fq_codel or whatever doing drops.  After all, this is what caused me to get concerned.

And actually, since UDP packets are dropped by fq_codel the same as TCP packets, it's easy to see how big fq_codel lets the buffers get.

If the buffer gets to be 1200 msec. long with UDP, that's a problem with fq_codel - just think about it.  Someone's tuning fq_codel to allow excess buildup of queueing, if that's observed.

So I doubt this is a netalyzr bug at all.  Operator error more likely, in tuning fq_codel.

On Tuesday, February 25, 2014 11:46am, "Jim Gettys" <jg at freedesktop.org> said:

> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> On Tue, Feb 25, 2014 at 11:02 AM, Nicholas Weaver <nweaver at icsi.berkeley.edu
>> wrote:
>> On Feb 25, 2014, at 7:59 AM, Jim Gettys <jg at freedesktop.org> wrote:
>> > So it is arguably a "bug" in netalyzr.  It is certainly extremely
>> misleading.
>> >
>> > Nick?
>> Rewriting it as a TCP-based stresser is definatly on our to-do list.
> Good; though I'm not sure you'll be able to build a TCP one that fills the
> buffers fast enough to determine some of the buffering out there (at least
> without hacking the TCP implementation, anyway).
> The other piece of this is detecting flow queuing being active; this makes
> a bigger difference to actual latency than mark/drop algorithms do by
> themselves.
>                                   - Jim
>> --
>> Nicholas Weaver                  it is a tale, told by an idiot,
>> nweaver at icsi.berkeley.edu                full of sound and fury,
>> 510-666-2903                                 .signifying nothing
>> PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

More information about the Cerowrt-devel mailing list