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. > > For this reason, you might have better luck with the next higher RTT > setting. > > Thanks…and using ‘metro’ (rtt 10ms) does improve things (two more tests at the > end): > > https://docs.google.com/spreadsheets/d/1SMXWw2fLfmBRU622urfdvA_Ujsuf_KQ4P3uyOH1skOM/edit#gid=2072687073 > > In both cases, soft rate limiting to 950mbit when using lower RTTs works > better > than relying on bql for the back-pressure (if I’m saying that right). > > So it just might be a thing (for the man page?) to avoid confusion. Or a > warning > emitted in some cases? Maybe there are other opinions on that... Yes, man page. > Pete > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
