Re: Question about tcp hash function tcp_hashfn()

["Brian F. G. Bidulock" <bidulock@openss7.org>]

Evgeniy,

On Thu, 01 Jun 2006, Evgeniy Polyakov wrote:

For purely random numbers you could amplify thermal noise off an
open transitor junction (the audiofile's white noise generator)
and feed it into an analog to digital converter.

> 
> I've run it with following source ip/port selection algo:
> 	if (++sport == 0) {
> 		saddr++;
> 		sport++;
> 	}
> 
> Starting IP was 1.1.1.1 and sport was 1.
> Destination IP and port are the same 192.168.0.1:80
> 
> Jenkins hash started to show different behaviour:
> it does not have previous artefacts, but instead it's dispersion is
> _much_ wider than in XOR case.

Aha!  But perhaps this is too easy a data set.  HTTP clients typically
dynamically allocate port numbers within a range and source address
are typically not less than a certain value.  That is why I suggested
something like:

       sport = 10000;
       saddr = 0x0a000000;  /* 10.0.0.0 */

       ...

       if (++sport == 16000) {
	       sport = 10000;
	       saddr++;
       }

If this shows artifacts worse than XOR then more realistic gaps in the
input values will cause artifacts.

> 
> With following ip/port selection algo:
> 	if (++sport == 0) {
> 		//saddr++;
> 		sport += 123;
> 	}
> 
> I see yet another jenkins artefacts, but again different from previous
> two.

Adding primes.  Again, the arithmetic series of primes might auto-correlate
with the Jenkins function.  Or it plain might not like gaps.

> 
> But each time both folded and not folded hashes behave exactly the same.
> 
> > Can you show the same artifacts for jenkins_3word?
> 
> What should be used as starting point there?
> If I use 0 it is the same as jhash_2words().
> If I use 123123 - artefacts are the same, just slighly shifted (I tested
> only the latest test above though).
> 
> Looking into the code we can see that jhash_2words() is jhash_3words()
> with zero "C" value, so it will show the same nature.

Skip that then.