<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 18, 2018 at 1:25 PM, Toke Høiland-Jørgensen <span dir="ltr"><<a href="mailto:toke@toke.dk" target="_blank">toke@toke.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk">toke@toke.dk</a>> writes:<br>
<br>
> Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> writes:<br>
><br>
>>> On 17 Apr, 2018, at 12:42 pm, Toke Høiland-Jørgensen <<a href="mailto:toke@toke.dk">toke@toke.dk</a>> wrote:<br>
>>> <br>
>>> - The TCP RTT of the 32 flows is *way* higher for Cake. FQ-CoDel<br>
>>>  controls TCP flow latency to around 65 ms, while for Cake it is all<br>
>>>  the way up around the 180ms mark. Is the Codel version in Cake too<br>
>>>  lenient, or what is going on here?<br>
>><br>
>> A recent change was to increase the target dynamically so that at<br>
>> least 4 MTUs per flow could fit in each queue without AQM activity.<br>
>> That should improve throughput in high-contention scenarios, but it<br>
>> does come at the expense of intra-flow latency when it's relevant.<br>
><br>
> Ah, right, that might explain it. In the 128 flow case each flow has<br>
> less than 100 Kbps available to it, so four MTUs are going to take a<br>
> while to dequeue...<br>
<br>
</span>OK, so I went and looked at the code and found this:<br>
<br>
        bool over_target = sojourn > p->target &&<br>
                           sojourn > p->mtu_time * bulk_flows * 4;<br>
<br>
<br>
Which means that we scale the allowed sojourn time for each flow by the<br>
time of four packets *times the number of bulk flows*.<br>
<br>
So if there is one active bulk flow, we allow each flow to queue four<br>
packets. But if there are ten active bulk flows, we allow *each* flow to<br>
queue *40* packets.</blockquote><div><br></div><div>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?</div></div><br></div></div>