Jonathan Morton <[email protected]> writes: >> On 1 Jun, 2018, at 10:23 pm, Toke Høiland-Jørgensen <[email protected]> wrote: >> >> Happens in unlimited mode and when the shaper is set to 60gbps, but not when >> it is set to 40gbps. > > Observations: > > - The shaper converts a rate in B/s into a time-per-byte value stored > in floating-point - cake_set_rate(). It is plausible that such a > conversion becomes faulty when exposed to especially large values.
Yeah. When changing the rate to a 64-bit value I changed the shifts in cake_set_rate() to the maximum possible to try to mitigate this... > - 40Gbps is 5.0 GB/s, 0.2000 ns/B. 60Gbps is 7.5 GB/s, 0.1333 ns/B. > No obvious power-of-two threshold is crossed; both are between 0.25 > and 0.125 ns/B, require 40 bits to store as bps and 33 as B/s. > > - In unlimited mode, the time-per-byte should be zero and the shaper > should therefore always pass traffic without advancing, but > time_next_packet will be continually reset to the latest delivery > time. Right. I was wondering if there was some way we could end up looping through cake_dequeue() forever if the shaper is not limiting things; there is both a while(1) and a couple of 'goto begin's in there. I guess if the sparse/bulk flow counts or sch->q.len accounting got messed up we might? But that shouldn't happen, should it? > What happens if a watchdog timer is set for a time that has already > elapsed? As far as I can tell from tracing through those functions, that just ends up inserting a timer value into an rbtree. So I don't think that in itself can cause bad things to happen... -Toke _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
