[Cerowrt-devel] [Cake] openwrt build available with latest cake and fq_pie
dave.taht at gmail.com
Sun Jun 14 14:24:52 EDT 2015
On Sun, Jun 14, 2015 at 11:07 AM, Jonathan Morton <chromatix99 at gmail.com> wrote:
>> On 14 Jun, 2015, at 20:38, Dave Taht <dave.taht at gmail.com> wrote:
>>> Every time Codel triggers the dropping state, it will mark or drop at least one packet, and increment count by that number. With count decremented only by 1 on recovery, it will effectively remain constant *if*, by some miracle, the queue empties before the second signal was sent; it cannot decrease between episodes unless it resets or wraps.
>> It aint a miracle, it is hopefully within an rtt.
> No, it is *at minimum* one RTT. It takes that long for the congestion signal to reach the receiver, be reflected back to the sender, the sender’s reaction to *begin to* appear at the queue. Then the queue *starts* to empty, if the signal is what’s required to make it do so.
Flows, btw, do end quite rapidly in the real world. What was it, 95%
of all web flows ended inside of IW10? Dropping a packet at the tail
end of an ending flow forces a retransmit. Far too much of our testing
and thinking is oriented to full rate flows.
That is what I meant by "hopefully". I would like to build a test that
consisted primarily of short flows, one that hopefully looked more
like normal traffic.
>> When resuming the drop phase of codel, it is almost *already* too late
>> to catch that burst incurring the latency.
> Yes, but that’s what FQ is for. And ELR, if we ever get that properly started.
>> Sometimes I think we need to do away with the count idea and measure
>> slopes of curves instead, and "harmonics”.
>> Is there any reason why the decrease couldn't be some sort of decay?
>> I.e. a function of how long ago the drop state was exited?
> Such things are theoretically possible, but require further thought to determine how best to do them.
> - Jonathan Morton
What will it take to vastly improve wifi for everyone?
More information about the Cerowrt-devel