All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Andi Kleen <andi@firstfloor.org>
Cc: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>,
	netdev@vger.kernel.org
Subject: Re: [PATCH] Stochastic Fair Blue queue discipline
Date: Thu, 10 Apr 2008 03:38:13 +0200	[thread overview]
Message-ID: <47FD6F85.5080003@trash.net> (raw)
In-Reply-To: <47FD6C0E.7040808@trash.net>

Patrick McHardy wrote:
> Andi Kleen wrote:
>>> Random32 is initialised from get_random_bytes; so the per-cpu
>>> pseudo-random sequences should be uncorrelated.  I fail to see how an
>>> arbitrary interleaving of uncorrelated good pseudo-random sequences
>>> can fail to be good.
>>
>> They are not necessarily uncorreleated, especially on platforms
>> which do have poor entropy support and when your initialization happens
>> at boot time. Take a look at how the random pool starts in random.c.
>>
>>> Looking at line 448 of sch_sfq.c in Linus' current HEAD, I see that
>>> somebody else thinks the same as I do.  So please let me know if sfq
>>> needs fixed, or whether I can use net_random in sfb.
>>
>> A lot of people get this wrong, but this doesn't mean that the
>> problem should be readded in new code again.
> 
> 
> Well, if I'm not mistaken net_random() used to be a function
> (in net/core/utils.c) that didn't have this problem. So these
> problems seem to have been introduced by the conversion to
> srandom().

Two more noteworthy things:

- net_random() was intended to provide *mediocre* random,
cheap to compute, not perfect. Good enough for many networking
related things.

- traffic schedulers shouldn't depend on perfect random,
its more about statistical multiplexing.




  reply	other threads:[~2008-04-10  1:38 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-07 22:37 [PATCH] Stochastic Fair Blue queue discipline Juliusz Chroboczek
2008-04-08  0:04 ` Patrick McHardy
2008-04-08  0:56   ` Patrick McHardy
2008-04-08 15:28   ` Juliusz Chroboczek
2008-04-08  8:20 ` Andi Kleen
2008-04-08 12:11   ` Patrick McHardy
2008-04-08 15:39     ` Juliusz Chroboczek
2008-04-08 15:45       ` Patrick McHardy
2008-04-09 15:48         ` Juliusz Chroboczek
2008-04-09 16:00           ` Patrick McHardy
2008-04-08 15:38   ` Juliusz Chroboczek
2008-04-08 16:32     ` Andi Kleen
2008-04-08 17:35       ` Juliusz Chroboczek
2008-04-08 17:53         ` Andi Kleen
2008-04-09 15:45           ` Juliusz Chroboczek
2008-04-09 17:49             ` Andi Kleen
2008-04-10  1:23               ` Patrick McHardy
2008-04-10  1:38                 ` Patrick McHardy [this message]
2008-04-10 11:17                   ` Juliusz Chroboczek
2008-04-11 13:07                     ` Patrick McHardy
2008-04-10 14:04                   ` Stephen Hemminger
2008-04-10  7:36                 ` Andi Kleen
2008-04-08 16:44 ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47FD6F85.5080003@trash.net \
    --to=kaber@trash.net \
    --cc=Juliusz.Chroboczek@pps.jussieu.fr \
    --cc=andi@firstfloor.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.