On Wed, Apr 18, 2018 at 1:25 PM, 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. I'm confused. Isn't the sojourn time for a packet a result of the total number of queued packets from all flows? If each flow were allowed to queue 40 packets, the sojourn time would be mtu_time * bulk_flows * 40, no?