From: Rick Jones <[EMAIL PROTECTED]>
Date: Tue, 08 Nov 2005 12:12:19 -0800

> Still seems to be doing as well - I'm assuming that when the
> "random" IPs are generated that they do not have to be put into
> network byte order, since they are randomly generated bits.  When
> the IPs aren't random, the inet_addr() call is putting things in
> network byte order.

The thing to observe, in real life, is that the lower bytes
(in network byte order, ie. big endian) of the IP addresses
change more often than the upper bytes (usually the network
part).

Since the IP addresses come off the wire in big-endian, and
we are hashing their values up in little-endian, the upper
bytes are what are more likely to change.  This is why it's
desirable to shift them down into the hash mask range.

Running test programs using random IP addresses and ports are a big
waste of time, since the likelyhood of change in various areas of IP
addresses is not at all random.  It is much better to get TCP socket
list snapshots from heavily loaded servers and use that as your hash
analysis test data, which is what we did when writing this code.

That being said, nobody has looked into this hash function in a long
time, so a new analysis wouldn't be such a bad idea.  We could even
just use the Jenkins for this.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to