On Thu, 2006-16-03 at 10:52 +1000, Russell Stuart wrote: > On Wed, 2006-03-15 at 10:21 -0500, jamal wrote:
> > > I dont agree with reverting the 2.6.x change. In the future if you do prove > > that the old one is better or a newer one is better then we will revisit > > given the definition we have of backwards compatibility above. > > Note, you need a lot more data than the simple example you showed. > > We can discuss this later etc. I am interested. > > Yes - later. I have posted data where the 2.4 algorithm > fares better. To proceed with the discussion we need > your data that shows it is worse. Then we can haggle > about which is more likely in real life. > Sounds good. I am assuming you are on your way to sending the patch, so let me note again the variables i mentioned when you do run those comparison. Your test was too simplistic to merit a fair comparison. The variables again are: a) the mask/mask size b) the size of the buckets available example if you are masking on 2 bits, then it doesnt matter if you have 256 buckets - only 4 get used. So creating more than 4 is a waste of memory. c) The offset within the 32 bit. I dont think this is a big factor if you keep shifting by increments of a byte. The last one is the range of values in your test data. Example if you have only 8 bits that you are masking on, then you dont need an input dataset of more than 256 - it adds no value. IIRC, the old 2.4.x hash is not only inefficient over a wide set of values it will be considered plain _buggy_ for lower values. I think over the weekend i will try to write a little program myself to simulate the different cases myself. cheers, jamal - 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
