From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 27C343B29E for ; Fri, 1 Jun 2018 15:58:00 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1527883076; bh=a+pON8t+FmQ9Fh4q+D5xFWpvUNKUr50J+O4KoYi3RbM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hvxQPQcJ9TN3OshnSzczA5zV7GFhcr9w/nvlBLtGaMDY7NjaGZveNdjWvlp3m3dQB wWgc47weHfv2UtF3UBoVcBXh64BBef+SxQdwHDfaLDyeHbXMDrnVXdbwmDfCCybAz0 d5KgeUoJKPIjoGOfSYdFn0FeMWd4uhuW2hKO76UygE3zOfvfV14hB0Ino2ZHZ+jH5u 6QN13NcA8BiojZVDvWL3NGFbYopdOzlsqxAEjXwcfXnV87JXsbmM+KBJeonFOh+53c jfHIOVV/Sq4MpbCApJK//f5YkXGwl0FHoPM/IxTvItjguz/0lfBSSA03lMHTY/cgjA Jk5jFPn44OLtg== To: Jonathan Morton Cc: cake@lists.bufferbloat.net In-Reply-To: <9A273CA6-FDF6-485D-B466-8B01D4573BD9@gmail.com> References: <87muwe9z7j.fsf@toke.dk> <87k1ri9yve.fsf@toke.dk> <877enimhuh.fsf@toke.dk> <9A273CA6-FDF6-485D-B466-8B01D4573BD9@gmail.com> Date: Fri, 01 Jun 2018 21:58:02 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <871sdqmg8l.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Lockup at high speeds X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 19:58:00 -0000 Jonathan Morton writes: >> On 1 Jun, 2018, at 10:23 pm, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> 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