On Sat, 2006-18-03 at 15:10 +1000, Russell Stuart wrote:
[..]
> I guess there are a couple of points here I don't understand:
>
> - I don't see how 2.4 was "buggy", but perhaps we have different
> definitions of buggy. I regard giving the wrong result as
> buggy. Neither algorithm does that.
>
The 2.4.x was incapable of using the buckets provided to it if you
gave it anything other than the 0xff mask. In previous email i mentioned
anywhere from 25%-75% of the buckets that are created
were unusable. Reducing the number of hash buckets _did not_ help - that
is the buggy part i.e it was just incapable of using all the buckets
regardless of the number of buckets available, period. Note even the
2.6.x one behaves that way, but if i picked the right number of buckets
it worked (something i cant do with 2.4) - and i can very easily tell
what the number of buckets needed is.
And as i mentioned before my setup had a lot of hash tables - and this
would have amounted to about 60M of wasted memory. That is substantial.
> - I don't understand your point about "there are only 16
> possible masks for 16 bits". What do you want me to show?
>
** if i had a mask-bit of 0xff, then i can only have masks with length
1-8. To enumerate: 0xff, 0xfe, 0xfc, 0xf8, 0xf0, 0xe0,0xc0,0x80
** if i had a mask of 16 bits then likewise i would have 16 possible
values of length 1-16.
What i have been suggesting is you to do is take all possible masks and
run them on all possible values and plot or use your formula etc.
Then you dont need to worry about compensating for randomness at all
because you will be looking at _every possible value_.
If you are looking at 8 bits dont bother exceeding values 0-0xff; and
for 16 bits not to go over the range of 0-0xffff because any values
above that are not adding anything new to the equation.
I also asked you vary the # of buckets to see things.
A range of {8,16,32,64,128,256} will do.
> > I will not respond to any further emails which do not contain
> > data - instead I am going to produce mine.
>
> Put the 2.4 vs 2.6 argument aside. The best solution as is
> to adopt the "new" algorithm I proposed. Here is why:
>
Removed the rest of your text - it is something i promised not to
respond to. And now since i have time ... you will hear from me in the
next 1-2 hours.
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
