Re: [Codel] [aqm] Codel's count variable and re-entering dropping state at small time intervals

[Jonathan Morton <chromatix99@gmail.com>]

> 1. in Cake, count saturates at 2^32-1, am I right (https://github.com/dtaht/sch_cake/blob/master/codel5.h#L352).
> 
> could it make sense to saturate count when interval/sqrt(count) and interval/sqrt(count+1) are indistinguishable in timer resolution?

Actually it saturates at 2^16-1, since count is declared as u16 (though it could reasonably be a wider type, too).

At that point, there are about 2560 drops (or marks) per second; if it did go up to 2^32-1, that would be 655360 drops/marks per second.  Linux timers on modern hardware generally have microsecond resolution or better, so there is no reason to saturate early even in the latter case.

> 2. I found three more changes from the original Codel:
> 
> 2.1 Line292:  if (sojourn_time < target || queue is empty) instead of (sojourn_time < target || there is less than MTU bytes in the queue).
> 
> was it changed because queue_length_in_bytes < MTU causes sojourn_time < target ?

We found no reason to special-case the last packet in the queue, so we simplified the code by removing it.  Detecting MTU (via the “maxpacket” statistic) was rather fragile in the face of GRO and GSO, with some common hardware regularly producing 64K aggregates.

Instead of special-casing the last packet, Cake constrains the target to 1.5 hardware MTUs (detected via the interface API, not via maxpacket) at the shaped rate.  This has more nearly the desired effect.

> 2.2. Line 304:
> 
> else if (vars->count > 1 && now - vars->drop_next < 8 * interval) {
>  /* we were recently dropping; be more aggressive */
>  return now - vars->first_above_time >
>     codel_control_law(now, interval, vars->rec_inv_sqrt);
> }
> 
> 2.3. Line 308:
> 
> else if (((now - vars->first_above_time) >> 15) * ((now - codel_get_enqueue_time(skb)) >> 15) > threshold) { return true; }.
> This line is explained in this email from Cake mailing list: https://lists.bufferbloat.net/pipermail/cake/2015-May/000227.html
> 
> 
> My question is - are these changes valid for a standalone Codel or are they specifically made to optimize Cake's scheduler?

I believe they could be.  The intent is to bias interval according to how quickly the queue is growing, so as to react more aggressively to slow-start’s rapid growth than to congestion-avoidance slow growth.  It might be worth testing in a standalone context.

 - Jonathan Morton