Re: [Cake] net-next is OPEN...

[Pete Heist <pete@eventide.io>]

> On Apr 18, 2018, at 7:43 AM, Pete Heist <pete@eventide.io> wrote:
> 
> I also think I saw this happen at lower bandwidths as well, when the CPU wasn’t loaded. What I’ll do is re-test on the current version I have at, say, 50Mbit (or to where load drops substantially), then update to the head and test again, and let you know...
> 
>> On Apr 17, 2018, at 3:52 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>> 
>>> On 16 Apr, 2018, at 11:55 pm, Pete Heist <pete@eventide.io> wrote:
>>> 
>>> I remember that fairness behavior at low RTTs (< 20ms) needed to be either improved or documented
>> 
>> The reason for the behaviour, IIRC, was that throughput dropped below 100% when the latency target was reduced too much.  Since then there has been a small change which might improve it a little, so a retest would be reasonable.

At 50mbit I don’t see nearly as much fairness degradation at low RTTs, although there’s some. Even at 100us, “fairness” is around 1.1 (1.0 being perfectly fair) instead of the 2.x I saw at 500mbit. I do not see much of a difference between the latest code (16d7fed, 2018-04-17) and the previous code I tested (7061401, 2017-12-01), if that info is of use.

RTT: tcp_1up upload Mbps / tcp_12up upload Mbps

7061401 (2017-12-01):

   100us: 23.80 / 25.85
   1ms: 23.89 / 29.46
   10ms: 23.93 / 24.66
   40ms: 23.96 / 24.10
   100ms: 23.97 / 24.12

16d7fed (2018-04-17):

   100us: 23.97 / 26.49
   1ms: 23.89 / 26.27
   10ms: 23.98 / 26.37
   40ms: 23.94 / 24.08
   100ms: 23.97 / 24.12

I can post reports / flent files on request.

So it appears this is CPU related, and not worth exploring further(?) and not worth documenting(?) other than that once things have stabilized, documenting how Cake degrades under various extreme conditions would be informative.

Well, here’s to science and a good walk in the weeds…