Re: [dhcwg] Load Balancing for DHCPv6

Donald Eastlake <> Thu, 20 September 2012 05:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F0C221F86B0 for <>; Wed, 19 Sep 2012 22:27:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kW0GxiMnhrg5 for <>; Wed, 19 Sep 2012 22:27:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B455221F8678 for <>; Wed, 19 Sep 2012 22:27:30 -0700 (PDT)
Received: by iabz21 with SMTP id z21so1554326iab.31 for <>; Wed, 19 Sep 2012 22:27:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=WapE9RsoGh0hmjz4agI/UZ9Vd2m+rQ9zipFmHPpRpso=; b=EB4vtnxMulTmNlSPebI6DPY/+Ih/t7gmC1TdOxCr12rvtMVp6n70kTN8UeIy0RT4rI 2r9Tb3/o3368Z+5I55BXxyKc3ewoeOViXmUmujr8Zo91znUoMQ+FAVs/aqimWdo5+SYH xnx0oBqmD/7UQL59nZCqIUIARUw9Azzg9OvI3QOibs7l+QbdlGnbZAUZDDh4+nd2Bypi CB1XaxCGAl5C3cmjp+oUx1hg8CVOrYF8hVnj+yaIOXuyJGeFKtvU5g2HB8Lpb/igOqB4 AlPJ0a9bc3Q+S2BnjV9zzSjksTQ+jnzY/kTk2jacW4R5ZC51TR287uTC23KlU6Xiny0o 5EQw==
Received: by with SMTP id eu1mr730690igc.0.1348118850097; Wed, 19 Sep 2012 22:27:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Sep 2012 22:27:09 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Donald Eastlake <>
Date: Thu, 20 Sep 2012 01:27:09 -0400
Message-ID: <>
To: Ted Lemon <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, "Bernie Volz (volz)" <>
Subject: Re: [dhcwg] Load Balancing for DHCPv6
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Sep 2012 05:27:31 -0000

Well, I have some more statistics. One my co-authors on the draft
whipped up some code that I then extended. The data hashed consisted
of 2,560,000 strings calculated as follows:
        #define RUN 10000
        for(i = 0; i < 256*RUN; ++i)
                sprintf(str, "%08d^^%08d", i, i);
                {do hashes, etc}

Each string was hashed with Pearson and with 32-bit FNV-1a. Three
arrays of 256 counters were incremented based on the Pearson hash,
based on the bottom byte of the 32-bit FNV after one 16-bit fold (
hash2 = (hash&0xffff) ^ (hash >> 16) ), and based on the bottom byte
of the 32-bit FNV after an additional 8-bit fold (hash3 = (hash2&0xff)
^ (hash2 >> 8); the equivalent of xor'ing all four bytes together).
The expected number of hits on each bucket with perfect hashing would
be 10,000. Here are the minimum and maximum number of hits and the
standard deviation:

Pearson: min=9678 max=19938 std-dev=630.72
FNV-32 1-fold: min=9699 max=10331 std-dev=103.06
FNV-32 2-folds: min=9662 max=10247 std-dev=90.78

So you now have Brian Carpenter's results, showing FNV to be much
better than a variety of other methods, but not Pearson, on fairly
realistic data. And you have these results showing FNV to be much
better than Pearson on somewhat unrealistic data. ...

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

On Fri, Sep 7, 2012 at 6:29 PM, Ted Lemon <> wrote:
> On Sep 7, 2012, at 5:37 PM, Donald Eastlake <> wrote:
>> FNV takes a little more effort than Pearson. It also has a smaller
>> footprint in memory. And I believe it will produce statistically
>> better results. What are the relative weights of these or other
>> factors in this case?
> Unfortunately, as far as I can tell neither of the studies you cite compares FNV to Pearson, although the results from Brian Carpenter's study are certainly pretty impressive.    I think more work is worse, smaller footprint probably doesn't matter (this algorithm is being run in DHCP servers, which typically aren't seriously memory-constrained), and statistically better results only matter if it's a pretty big difference, so it's frustrating that we don't have a comparison to the existing algorithm.
> To me, the biggest win of using FNV would be if there were an RFC to refer to, but it looks like this is not quite there yet.   So my conclusion is that I certainly don't oppose using FNV instead of Pearson, but I don't see a strong reason to support it either.