From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id AB9D33B2A4 for ; Fri, 6 Jul 2018 06:46:36 -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=1530873994; bh=wNUGDND6oioS6dt/ke/yT/kevSUTZF3KgU8rUgGmQG8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jOCTa6uaYgkUzJUxY4jVFqWRyIjeKfguZeT/AgCeVZpdHkgIIHUexqDbBKZaX9L9P k4HIXLajVho/xtmD8NHHyYpdHgSEOZ2gm87/9V/WMtmYJEj9zBli0A+k8RWlJbUJI3 vQn0q7cS9rdTB03LKgZtwFtk+mfrT0pB5lUs72UFCvYOTKnfUv5NtJ7prUYzgenIbQ JAkOlqa3cf0EA7Yy27EI8eCsdpJmY1FpT4E7CWamFIb4Bkyjqx3BxOlvfwj/3nml3H J9eG5A/o4bfLXjNKmfpkZrcYFMhDehyy8fBSX4iwLiJNLo/WOq1nV5I0x6tYDy9yca xDXRjJMQJ0rDQ== To: Pete Heist Cc: Jonathan Morton , Cake List In-Reply-To: References: <87lgatj13k.fsf@toke.dk> <87fu11ipir.fsf@toke.dk> <871scligay.fsf@toke.dk> <2AE036E5-BD3D-4176-9476-9EC824EC1D18@darbyshire-bryant.me.uk> <87r2klh1fz.fsf@toke.dk> <87lgath01v.fsf@toke.dk> <52B2B44D-4382-404C-8F6D-03F12A72B11F@heistp.net> <31667353-48F2-4FAB-AC05-163680451719@toke.dk> <48ECB6C8-5D22-4785-A6CE-696D87EC5496@toke.dk> <73DD74AD-C2E7-4A12-AE49-C06D4486660E@gmail.com> <87fu10haw7.fsf@toke.dk> <8736wxco28.fsf@toke.dk> <87o9fkbtky.fsf@toke.dk> Date: Fri, 06 Jul 2018 12:46:33 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87lgaobq0m.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] cake at 60gbit 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, 06 Jul 2018 10:46:36 -0000 Pete Heist writes: >> On Jul 6, 2018, at 11:29 AM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>=20 >> Pete Heist > writes: >>=20 >>> - is tin_deficit overflowing at these rates? at 50gbit, 2^31-1 bytes >>> happen in 344 ms (involuntary chuckle) >>> - what=E2=80=99s the value of tin_quantum_band here? but I suspect it= =E2=80=99s ok. >>=20 >> I thought about overflows, but I don't get any "weird" values, and >> everything ends up back at zero when the flows stop. And it's not >> actually tin_backlog that's causing the looping=E2=80=A6 > > Ok, I think tin_deficit is meant here, esp. in light of what follows rega= rding *_flow_count. > > Once we do get past this infinite loop, which it sounds like is not > caused by overflow here, I guess it=E2=80=99s still worth reviewing wheth= er > tin_backlog or other values _could_ overflow in certain conditions. There's a global memory limit which limits the backlog. So no overflows as long as the accounting is working correctly :) >> Yeah, they are; that's why it keeps looping. I've been looking at both >> tin_backlog and the *_flow_count vars as different ways of checking >> whether the tins are actually empty... they are all 0 when this happens. > > Aha, ok. It does look physically possible for these to both be 0 since > there appear to be cases where one is decremented without the other > being incremented. That _all_ *_flow_count vars are 0 seems strange > logically. I=E2=80=99ll leave this alone now though as don=E2=80=99t yet = understand > what the values represent well enough=E2=80=A6 :) Yeah, that state machine is a bit too complicated for my taste as well; not sure it's actually incorrect, though... -Toke