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