On Fri, Nov 24, 2017 at 01:06:12PM +0100, Sebastian Moeller wrote: > > > On Nov 24, 2017, at 12:21, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > > > Dave Taht <d...@taht.net> writes: > > > >> Pete Heist <petehe...@gmail.com> writes: > >> > >>> On Nov 23, 2017, at 10:44 AM, Jonathan Morton <chromati...@gmail.com> > >>> wrote: > >>> > >>> This is most likely an interaction of the AQM with Linux' scheduling > >>> latency. > >>> > >>> At the 'lan' setting, the time comstants are similar in magnitude to > >>> the > >>> delays induced by Linux itself, so congestion might be signalled > >>> prematurely. The flows will then become sparse and total throughput > >>> reduced, > >>> leaving little or no back-pressure for the fairness logic to work > >>> against. > >> > >> Agreed. > >> > >> man page add: > >> > >> At the 'lan' setting(1ms), the time constants are similar in magnitude > >> to the jitter in the Linux kernel itself, so congestion might be > >> signalled prematurely. The flows will then become sparse and total > >> throughput reduced, leaving little or no back-pressure for the fairness > >> logic to work against. Use the "metro" setting for local lans unless you > >> have a custom kernel. > > > > Erm, doesn't this make the 'lan' keyword pretty much useless? So why not > > just remove it? Or redefine it to something that actually works? 3ms? > > The same applies for datacentre (0.1 ms), no? But I agree, let's not expose > these as explicit keywords, one can always use "rtt [100us|1ms]" I assume...
Which should also contain such disclaimer with it. "Values smaller than 10ms requires special handling.", for example. Marcelo _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
