Graphite

Why does ConsistentHashRing cut hashes down to 16 bits?

Asked by Wade Rossmann

I'm looking to port the ConsistentHashRing implementation to a different language and I'm trying to get my head around various implementation details, but this one has eluded me so far. I was tinkering with the code as-is when I noticed all the ring positions were <= 65535 even though fnv1a should be returning 32bit hashes.

The code in question: https://github.com/graphite-project/carbon/blob/master/lib/carbon/hashing.py#L42-L53

I know from the current rev it _looks_ like it's to accomodate 16bit algos, but after looking back through the blame history the original implementation didn't look like it was accomodating those, but still cut the hashes in half. I can't really think of a good reason for this since the hash positions are going to be stored as full size integers anyway. I was hoping to glean some reasoning from the commit/PR messages but there's not much to be found, even all the way back to the initial commit 8+ years ago.

Can anyone clarify this for me?

Question information

Language:
English Edit question
Status:
Expired
For:
Graphite Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Denis Zhdanov (deniszhdanov) said : 		#1

If you talking about initial implementation, i.e. carbon_ch then probably only initial contributor knows, from Orbitz time, probably only Chris Davis himself, and I think it's better to ask him directly - <email address hidden>
If you talking fnv1a_ch - I only mimic initial implementation from carbon-c-relay - https://github.com/grobian/carbon-c-relay/blob/1f83a273e88a594b068b39eb082ec4af7b8a8c95/consistent-hash.c#L67-L80 - so it's better again to ask its author directly - probably through Github, I do not know his email.

Revision history for this message
Launchpad Janitor (janitor) said : 		#2

This question was expired because it remained in the 'Open' state without activity for the last 15 days.