I analyzed the part res ^= (res >> 24); res ^= (res >> 8); a little more in the rt_hash. What it really does is that it applies the hi bits in the 32bit integer on the low ones. This means that we wont just throw them away when we apply the %-operation on it. This is what keeps the good distribution. So i just added those two line to abcd (and got abcd_rt). Showed up to be very good:
http://aaricia.hemmet.chalmers.se/~gozem/cttest/0.4/ And specially: http://aaricia.hemmet.chalmers.se/~gozem/cttest/0.4/1abcd/sizes.262143.html The hashfunction: static u32 hash_abcd_rt(struct ct_key *key) { u32 res; PER_HASH_TIMER_1( res = 0x47441DFB * key->sip + 0x57655A7D * key->dip + 0x1C7F1D2D * key->sport + 0xDF91D738 * key->dport + key->proto; res ^= (res >> 24); res ^= (res >> 8); ); return res; } Since we wanted to try other architectures than x86 i tried to run the calculations on my school that has SUN and solaris. After much trixing with the cttest-0.4 scripts and program (since they were clearly not Solaris compatible) i managed to get some results. Without the timing of the function since that part was Linux specific. Atleast this is a test on a big-endian machine: #uname -a SunOS licia.dtek.chalmers.se 5.8 Generic_108528-14 sun4u sparc SUNW,Sun-Fire-280 http://www.dtek.chalmers.se/~d97gozem/cttest/0.4/ All graphs here look about equally good. I dont know if there is a bug somewhere in cttest that might do this. -- /Joakim Axelsson A.K.A Gozem@EFnet & OPN
