Re: Question about tcp hash function tcp_hashfn()

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/