[Cerowrt-devel] uplink_buffer_adjustment

[dpreed at reed.com]

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
>>
>>
>