Re: [Cake] Cake upstream Planning

[Pete Heist <peteheist@gmail.com>]

> From: Dave Taht <dave@taht.net>
> To: Pete Heist <peteheist@gmail.com>
> Cc: cake@lists.bufferbloat.net
> Subject: Re: [Cake] Cake upstream Planning
> Message-ID: <87375f71h3.fsf@nemesis.taht.net>
> Content-Type: text/plain; charset=utf-8
> 
> Dave Taht <dave@taht.net> 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.