> On 18 Apr 2018, at 12:25, Toke Høiland-Jørgensen wrote: > > Toke Høiland-Jørgensen writes: > >> Jonathan Morton writes: >> >>>> On 17 Apr, 2018, at 12:42 pm, Toke Høiland-Jørgensen wrote: >>>> >>>> - The TCP RTT of the 32 flows is *way* higher for Cake. FQ-CoDel >>>> controls TCP flow latency to around 65 ms, while for Cake it is all >>>> the way up around the 180ms mark. Is the Codel version in Cake too >>>> lenient, or what is going on here? >>> >>> A recent change was to increase the target dynamically so that at >>> least 4 MTUs per flow could fit in each queue without AQM activity. >>> That should improve throughput in high-contention scenarios, but it >>> does come at the expense of intra-flow latency when it's relevant. >> >> Ah, right, that might explain it. In the 128 flow case each flow has >> less than 100 Kbps available to it, so four MTUs are going to take a >> while to dequeue... > > OK, so I went and looked at the code and found this: > > bool over_target = sojourn > p->target && > sojourn > p->mtu_time * bulk_flows * 4; > > > Which means that we scale the allowed sojourn time for each flow by the > time of four packets *times the number of bulk flows*. > > So if there is one active bulk flow, we allow each flow to queue four > packets. But if there are ten active bulk flows, we allow *each* flow to > queue *40* packets. > > This completely breaks the isolation of different flows, and makes the > scaling of Cake *worse* than plain CoDel. > > So why on earth would we do that? The thread that lead to that change: https://lists.bufferbloat.net/pipermail/cake/2017-December/003159.html Commits: 0d8f30faa3d4bb2bc87a382f18d8e0f3e4e56eac & the change to 4*bulk flows 49776da5b93f03c8548e26f2d7982d553d1d226c Cheers, Kevin D-B 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A