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" <[email protected]> said: > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel > On Tue, Feb 25, 2014 at 11:02 AM, Nicholas Weaver <[email protected] >> wrote: > >> >> On Feb 25, 2014, at 7:59 AM, Jim Gettys <[email protected]> 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, >> [email protected] full of sound and fury, >> 510-666-2903 .signifying nothing >> PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc >> >> > _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
