> From: Dave Taht <[email protected]> > To: Pete Heist <[email protected]> > Cc: [email protected] > Subject: Re: [Cake] Cake upstream Planning > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > Dave Taht <[email protected]> writes: > >>> So yes, we can lower TCP RTT with these more aggressive settings. But just >>> to >>> make sure, we’re confident that there are no other side effects from these >>> lower >>> targets and intervals? Is there anything else I should test for to be sure? >>> For >>> example, when I rate limit to 950 Mbit and try the same test above, ‘lan’ >>> causes >>> a 20% drop in throughput vs the defaults. That may be from an overtaxed >>> CPU, but >>> I don’t know. I also wonder how this affects routed vs local traffic. I’ll >>> try >>> to test this at some point, as I want to understand it better anyway to >>> know how >>> backhaul links should be configured... > > One interesting thing that might make tcp behave better is the new > pacing code which lets us set pacing to a different log value. Presently > - at 10 - the TSQ algorithm recalculates things at 1ms. The pacing value > is intended to be changed to, say, 6 or 7 to make wifi work > better... and I suspect, that if it were upped to, say 12 (250us), on > ethernet, > that might make pacing more effective there. > > Just like breaking the sound barrier, breaking the 1ms barrier looks to > be hard within conventional kernel thread scheduling.
To make sure I understand, setting pacing means setting a socket option at the sender, right? A TCP RTT of ~= 1ms with the ‘lan’ keyword is already quite good, and not something likely worth trying to optimize right away anyway. _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
