lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 11 Apr 2008 15:07:19 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Juliusz Chroboczek <Juliusz.Chroboczek@....jussieu.fr>
CC:	Andi Kleen <andi@...stfloor.org>, netdev@...r.kernel.org
Subject: Re: [PATCH] Stochastic Fair Blue queue discipline

Juliusz Chroboczek wrote:
>> - traffic schedulers shouldn't depend on perfect random,
>> its more about statistical multiplexing.
> 
> Okay, I've been thinking about this, and I'm not quite sure that what
> sfq and sfb want is a pseudo-random sequence in the first place.
> 
> Sfq and sfb only draw random numbers in order to change hashing
> functions periodically, so as not to have an innocent flow stuck
> within a hash bucket with a non-reactive flow.  For sfb it doesn't
> matter much (collisions in a Bloom filter are so rare as to be almost
> nonexistent), but for sfq, it is fairly important.
> 
> Now assuming jhash is any good, i.e. that a single bit change in the
> input changes all output bits with roughly similar probability (and
> I don't know whether it is), it shouldn't matter much what sequence of
> u32 we use for the perturbation as long as it doesn't repeat values
> too often.  Something as simple as a static counter might actually be
> good enough.
> 
> So I'd argue that the wise thing is to make sure of is that jhash is
> good (in the sense above), and not bother too much with the PRNG.


Agreed. jhash gives pretty good distribution, so we should be fine.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ