Hello,
Apologies for the delay in replying. I just got back to this today and
will spend time during this week. I need a couple of clarifications to make
sure I understood what you say before I go about making the change.
> Note that we could also consider not doubling the keywords and proceeding
> like this instead since "avalanche" is always optional with any hash :
My reading of the code in backend.c and definitions in backend.h, and I
think you mentioned it previously, avalanche/full_hash was always applied
prior to consistent. What does "always optional" mean in this context?
> hash-type {map-based|consistent} [[<algo>] avalanche]
> <algo> would be "sdbm", "djb2", "wt6", "sdbm+avalanche",
"djb2+avalanche",
> "wt6+avalanche".
Are you now saying, that we do not apply avalanche with consistent unless
specified?
I did not test this well enough, but did do a quick test, when I do not
apply avalanche/full_hash for consistent in backend.c, I get wildly
different results. I looked at the code in lb_chash.c between 1.4 and 1.5
and did not find anything difference. Am I missing something?
Please clarify at the earliest and I will work on it immediate. Once again,
thanks for your patience.
-Bhaskar
On Wed, Oct 30, 2013 at 2:44 AM, Willy Tarreau <[email protected]> wrote:
> Hello Bhaskar,
>
> On Tue, Oct 29, 2013 at 11:56:50PM -0400, Bhaskar Maddala wrote:
> > Hello Willy,
> >
> > In continuation of the thread on alternatives to consistent hashing, I
> > am starting a new thread to track the patch that has been implemented.
> >
> > The results of testing can be viewed at [1]. The result match my
> > expectations from earlier, i.e. when using consistent hashing DJB2 is
> > better than the alternatives.
>
> OK then probably we don't need wt6 if it does not bring anything here.
> We don't need to add features that provide no value and that people
> will want to use because they decide so!
>
> I just noticed that Bob Jenkins has run a comparison of multiple hashes
> including DJB2 which in his opinion is good for english text :
>
> http://www.burtleburtle.net/bob/hash/doobs.html
>
> Never tried Spookyhash though, Murmur3 nor siphash though.
>
> > I will run the additional test for 1MM
> > requests and fill in the results shortly, however I was satisfied to send
> > this patch along. Please lmk in case of any questions.
>
> OK. I'm thinking about something we discussed about earlier in this
> thread, to have the ability to disable avalanche. I think we could
> do this *and* keep the compatibility with existing configs with what
> you've done :
>
> hash-type {map-based|consistent} [<algo>]
>
> <algo> would be "sdbm", "djb2", "wt6", "sdbm+avalanche",
> "djb2+avalanche",
> "wt6+avalanche".
>
> "consistent" would default to "sdbm+avalanche".
> The keyword "avalanche" alone would still be accepted for the first
> keyword as an alias for "map-based sdbm+avalanche" but be deprecated
> (and probably removed in the 1.5 release).
>
> Note that we could also consider not doubling the keywords and proceeding
> like this instead since "avalanche" is always optional with any hash :
>
> hash-type {map-based|consistent} [[<algo>] avalanche]
>
> > The attached patch was generated with "git format-patch master
> > --stdout", here are some stats
>
> Don't worry about the stats, you can simply post the output of
> git format-patch, it's easily understandable.
>
> I quickly glanced over the patch because I must leave in a few minutes
> and my general feeling is that it's OK.
>
> Please consider the options above concerning the split of "avalanche"
> and about still allowing as a separate keyword but deprecated. I think
> this will open the way to add more hash functions in the future,
> especially if we want to add some mixing functions (like avalanche)
> which re-hash 32-bit into 32-bit.
>
> Thanks for the great work and all the testing, I know what it means
> to produce that many values!
>
> Willy
>
>