|
Hello,
On Thu, 19 Jun 2003, Roberto Nibali wrote:
> You're right, but getting it from /proc/net/ip_vs_conn is only giving us
> a snapshot situation. We would need continouus snapshots to see hash
> collisions and distribution in relation to time and template entries.
Agreed, but I'm not sure what we can do. May be stats?
> > mix was designed for 2-way but there are so many shifts.
> > The modern CPUs multiply faster.
>
> Yes. BTW, have you noticed that inlining only improves runtime for the
> lvs hash method when using gcc 3.x?
Yes, I didn't tried to optimize them
> > BTW, I suspect our implementation in DH and the old tests with
> > 2654435761. May be it is more correct to get the highest bits (as
> > in hashlvs-0.2)?
>
> I think only if the hash size is small but for 18 bits it should not
> matter too much. What I was a bit surprised about is why we use the
> proto in the current LVS hash, because it can only be 0x0001 or 0x0011.
> This doesn't add anything to the distribution per se if you do
Yes, I removed it from use in my tests, no need to waste
cycles with proto.
> proto^addrh^(addrh>>bits)^ntohs(port) & mask
>
> and might explain the high bits approach, as the lowest bits are most of
> the time populated.
:) ok, I'll try now to optimize these tools ...
> Best regards,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
