From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 159D73B2A4 for ; Tue, 21 Nov 2017 14:03:40 -0500 (EST) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id C853021341; Tue, 21 Nov 2017 19:03:39 +0000 (UTC) From: Dave Taht To: Jonathan Morton Cc: cake@lists.bufferbloat.net References: <1510945885-9986-1-git-send-email-dave.taht@gmail.com> <1510945885-9986-3-git-send-email-dave.taht@gmail.com> <8760a81y3s.fsf@nemesis.taht.net> Date: Tue, 21 Nov 2017 11:03:38 -0800 In-Reply-To: (Jonathan Morton's message of "Tue, 21 Nov 2017 00:08:18 +0200") Message-ID: <87tvxntpx1.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Cake] [RFC PATCH 2/3] Add cake related includes and source files 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: Tue, 21 Nov 2017 19:03:41 -0000 Jonathan Morton writes: > On 17/11/17 21:52, Dave Taht wrote: >>> +#define REC_INV_SQRT_CACHE (16) > >> Never been proven that this cache either improves cpu utiliziation, nor >> that the added accuracy has any effect. I'd like to be able to >> completely compile out the cache. > > CPU utilisation is debatable. It could go either way, actually, compared to a > *single* unconditional Newton step. The cache is probably faster than > *multiple* Newton steps which would be required to guarantee the same accuracy. > > However, a few minutes' work with a spreadsheet is sufficient to show a *big* > difference in timing between the accurate values placed in the cache and the > approximations given by a single Newton step for small count values, > particularly when stepping from count 1 to 2 or vice versa. Above 16, a single > Newton step gives sufficient accuracy in either direction, given the precision > stored. > The magnitude of the error when stepping up to count 2 is such as to give the > value that *should* have been produced at count 4. I am going to add this as a comment. > Since you are presently > concerned elsewhere with Cobalt's supposedly "aggressive" behaviour, removing > the cache would definitely make that worse. I would like to work towards a stable version that can be benchmarked at long rtts. The network namespace stuff is helping here to simulate that.