Re: [Cake] Lockup at high speeds

[Dave Taht <dave.taht@gmail.com>]

How on earth are you getting these speeds? I'm stuck at a pathetic *4*
gbit here on the admittedly ancient 12 core boxes I'd got.
(I'll go rework my veth topology)

rcu stuff makes me nervous, what happens if that nat stuff is disabled entirely.

What if you made q.len and sparse/bullk flow counts atomic ops?

I tend to lean towards an overflow post 40gbit also.

On Fri, Jun 1, 2018 at 12:58 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Jonathan Morton <chromatix99@gmail.com> writes:
>
>>> On 1 Jun, 2018, at 10:23 pm, Toke Høiland-Jørgensen <toke@toke.dk> 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
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619