Re: [aqm] avoiding the sqrt

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 10 August 2015 17:17 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1E11B3A69 for <aqm@ietfa.amsl.com>; Mon, 10 Aug 2015 10:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.961
X-Spam-Level:
X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOgUcgd-9V4H for <aqm@ietfa.amsl.com>; Mon, 10 Aug 2015 10:17:48 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4475F1B3A5D for <aqm@ietf.org>; Mon, 10 Aug 2015 10:17:08 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7C6BFA1; Mon, 10 Aug 2015 19:17:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1439227026; bh=8HVjvqXyxtrMegVSeFexXzmxC97B1KILotQjYhUpnS4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=e/2AqPI1Upbq5QEkBQ9V9hthoi/pJDRRRK//24wHgQRAduLd/Emis2BmabFPUhdwf dDggaLOoyNMkaY1TobBwYOooxBdM81TyVvxDpzbElG8KLeQJYC+BaUfwxKbF4x6+eK WfDcKSvGix8luwr5osEYEVQWHbrSvAxwNF5EEx8s=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 74B639F; Mon, 10 Aug 2015 19:17:06 +0200 (CEST)
Date: Mon, 10 Aug 2015 19:17:06 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Jeff Weeks <jweeks@sandvine.com>
In-Reply-To: <274D3A0FA900FD47AA6B56991AAA32FDC53BAA3F@wtl-exchp-1.sandvine.com>
Message-ID: <alpine.DEB.2.02.1508101913460.11810@uplift.swm.pp.se>
References: <274D3A0FA900FD47AA6B56991AAA32FDC53BAA3F@wtl-exchp-1.sandvine.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/L5gorqQv3i8vfbF8PV1bgRlEiUg>
Cc: "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] avoiding the sqrt
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2015 17:17:50 -0000

On Mon, 10 Aug 2015, Jeff Weeks wrote:

> The CoDel control_law is defined as 't + interval/sqrt(count)'
>
> The sample implementation (http://queue.acm.org/appendices/codel.html) suggests that sqrt(count) can be calculated using only integer multiplication, but I'm wondering if it even needs to be calculated.
>
> Would it not be more efficient to pre-calculate a set of 1/sqrt(count) for some range --  probably (1..interval), and for any count > interval, the next interval can just be set to t+1.
>
> Is there any reason to not use this approach (assuming sufficient memory exists, of course)?

I think this should be left up to individual implementation. I have some 
experience from assembler programming on the C64 and Amiga in the 80ties, 
and back then it was common to have these kinds of lookup tables because 
memory accesses were "cheap" and calculations were "expensive". I don't 
know if this is still the case in modern hardware, it might even be that 
it's cheaper to do sqrt on an internal register compared to doing memory 
access to relatively slow DRAM (if the lookup table isn't kept in cache) 
to fetch some data from a precalculated lookup table.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se