public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oliver Xymoron <oxymoron@waste.org>
To: Tommi Kyntola <kynde@ts.ray.fi>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] (0/4) Entropy accounting fixes
Date: Tue, 20 Aug 2002 12:22:16 -0500	[thread overview]
Message-ID: <20020820172215.GE19225@waste.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0208201740480.3601-100000@behemoth.ts.ray.fi>

On Tue, Aug 20, 2002 at 07:19:26PM +0300, Tommi Kyntola wrote:
> On Tue, 20 Aug 2002, Oliver Xymoron wrote:
> > On Tue, Aug 20, 2002 at 11:59:49AM +0300, Tommi Kyntola wrote:
> > > On Mon, 19 Aug 2002, Oliver Xymoron wrote:
> > > > On Mon, Aug 19, 2002 at 01:43:59AM -0400, Theodore Ts'o wrote:
> > > > > On Sat, Aug 17, 2002 at 09:15:22PM -0500, Oliver Xymoron wrote:
> > > > >
> > > > > >  Assuming the interrupt actually has a nice gamma-like distribution
> > > > > >  (which is unlikely in practice), then this is indeed true. The
> > > > > >  trouble is that Linux assumes that if a delta is 13 bits, it contains
> > > > > >  12 bits of actual entropy. A moment of thought will reveal that
> > > > > >  binary numbers of the form 1xxxx can contain at most 4 bits of
> > > > > >  entropy - it's a tautology that all binary numbers start with 1 when
> > > > > >  you take off the leading zeros. This is actually a degenerate case of
> > > > > >  Benford's Law (http://mathworld.wolfram.com/BenfordsLaw.html), which
> > > > > >  governs the distribution of leading digits in scale invariant
> > > > > >  distributions.
> > > > > > 
> > > > > >  What we're concerned with is the entropy contained in digits
> > > > > >  following the leading 1, which we can derive with a simple extension
> > > > > >  of Benford's Law (and some Python):
> > 
> > > I think you have it slightly wrong there. By snipping away the first digit 
> > > from a number leaves you with, not Benford's distribution, but 
> > > uniform distribution, for which the Shannon entropy is naturally roughly
> > > the bitcount.
> > 
> > No, it's much more complicated than that - that doesn't give us scale
> > invariance. Observe that the distribution of the first and second
> > digits in base n is the same as the distribution of the first digit in
> > base n*2. The probability of finding a 0 as the second digit
> > base 10 is simply the sum of the probabilities of finding 10, 20,
> > 30,..90 as the first digit, base 100, see? It's .1197, rather than the
> > expected .1. In base 2, the odds of the second digit being 0 is .58.
> 
> Oh now I see, you're relying on the given times to be gamma distributed 
> (1/x, and thus naturally scale invariant). I was constantly thinking about 
> the jiffie count that got masked that I took as uniform, but naturally 
> within the delta context it's not uniform, since the first order delta 
> naturally defines the timestamp when the previous timestamp is known.
> And thus yes, you are indeed right. Furthermore it wouldn't even have to 
> be gamma and as such scale invariant. Even mere nonuniformness (which I'm 
> sure the timings are) guarantees that mere first bit snipping is not 
> enough to ensure entropy inside that full range.
> 
> The current the delta bitcount - 1 is not the correct entropy amount in 
> any said gamma (or likes) distributed number. Does strict gamma assumption 
> really lead to so strict figures as you showed in your patch :
> static int benford[16]={0,0,0,1,2,3,4,5,5,6,7,7,8,9,9,10};
> 
> Numbers below 0..7, don't have a single bit of entropy?

They have fractional bits of entropy.
 
> I'm more inclined to think that where as this may be sound for the larger 
> delta bit counts, I don't think it applies that well for the smaller 
> deltas. It's unlikely that the timing distributions stay scale invariant
> for the lower end bits.

Possibly. If anything, I'd expect them to get worse, not better, more
strongly displaying quantization due to cache flushes or the like.
 
> Not mention that if the actual time separation is something like 12 bits,
> but the second order delta drops the entropy bit count down to 4, 
> couldn't those four be considered uniformly distributed, atleast roughly 
> enough, so that the benford array reduction could be skipped.

Actually, no. Scale invariant means we expect to see the same sorts of
numbers regardless of the units we use. Differences of such numbers
won't magically become associated with a particular unit and should
still match up with the so-called 'distribution of distributions'.

> Although Linus was not so hot about your "draconian measures" patch set
> this part of it would atleast seem worth the while. Atleast when the 
> limiting delta is the first order, it is indeed unreasonable to think 
> that it's bit count - 1 would show the entropy that's present.

I've got another spin that I'll send him after he's kicked out .32
that he'll probably find acceptable. Gives headless folks the rope to
hang themselves with.

Ooh, that's clever. I'll have to stick that in the comments somewhere.

-- 
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

  reply	other threads:[~2002-08-20 17:18 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-18  2:15 [PATCH] (0/4) Entropy accounting fixes Oliver Xymoron
2002-08-18  2:23 ` [PATCH] (1/4) " Oliver Xymoron
2002-08-18  2:26   ` [PATCH] (2/4) Update input drivers Oliver Xymoron
2002-08-18  2:29     ` [PATCH] (3/4) SA_RANDOM user fixup Oliver Xymoron
2002-08-18  2:32       ` [PATCH] (4/4) entropy batching update Oliver Xymoron
2002-08-18  2:30 ` [PATCH] (0/4) Entropy accounting fixes Linus Torvalds
2002-08-18  2:59   ` Oliver Xymoron
2002-08-18  3:08     ` Linus Torvalds
2002-08-18  3:25       ` Linus Torvalds
2002-08-18  4:42         ` Oliver Xymoron
2002-08-18  4:53           ` Linus Torvalds
2002-08-18  5:05             ` Dmitri
2002-08-18  6:18               ` Oliver Xymoron
2002-08-22  3:33             ` David Wagner
2002-08-18 10:30         ` Alan Cox
2002-08-18 15:08           ` Oliver Xymoron
2002-08-18 17:31           ` Jonathan Lundell
2002-08-22  3:27         ` David Wagner
2002-08-18  4:30       ` Oliver Xymoron
2002-08-21  8:44       ` Rogier Wolff
2002-08-21 12:47         ` Oliver Xymoron
2002-08-18  5:28     ` Andreas Dilger
2002-08-18  5:53       ` Oliver Xymoron
2002-08-22  3:25   ` David Wagner
2002-08-18  3:05 ` Linus Torvalds
2002-08-18  3:51   ` Robert Love
2002-08-18  4:01     ` Linus Torvalds
2002-08-18  5:38       ` Oliver Xymoron
2002-08-19  4:21         ` Theodore Ts'o
2002-08-19 10:15           ` Marco Colombo
2002-08-19 10:25             ` Oliver Neukum
2002-08-19 11:03               ` Marco Colombo
2002-08-19 14:22                 ` Oliver Neukum
2002-08-19 15:21                   ` Marco Colombo
2002-08-19 16:29                     ` Oliver Neukum
2002-08-19 12:39           ` Oliver Xymoron
2002-08-18  6:31       ` Robert Love
2002-08-18  6:48         ` Oliver Xymoron
2002-08-18  4:06     ` dean gaudet
2002-08-18  4:44       ` Oliver Xymoron
2002-08-18  7:31       ` Bernd Eckenfels
2002-08-18  9:48         ` Ralf Baechle
2002-08-20 12:51           ` Bernd Eckenfels
2002-08-18 16:58         ` Robert Love
2002-08-18 10:25       ` Alan Cox
2002-08-19 10:47         ` Marco Colombo
2002-08-19 12:29           ` Alan Cox
2002-08-19 12:56             ` Marco Colombo
2002-09-08  3:43             ` D. Hugh Redelmeier
2002-09-08 18:03               ` David Wagner
2002-09-09 16:53                 ` Oliver Xymoron
2002-09-09 16:58                   ` David Wagner
2002-09-09 19:47                     ` Oliver Xymoron
2002-09-09 23:22                       ` David Wagner
2002-09-16 22:51                       ` dean gaudet
2002-09-17  1:18                         ` Oliver Xymoron
2002-09-09 18:54                   ` Kent Borg
2002-09-09 19:57                     ` Oliver Xymoron
2002-09-09 20:11                       ` Kent Borg
2002-08-18  4:57     ` Oliver Xymoron
2002-08-18  4:28   ` Oliver Xymoron
2002-08-18  4:51     ` Linus Torvalds
2002-08-18  5:24       ` Oliver Xymoron
2002-08-18 16:59         ` Linus Torvalds
2001-11-02 10:34           ` Pavel Machek
2002-08-23 20:16             ` Linus Torvalds
2002-08-18 17:03           ` Robert Love
2002-08-18 17:31           ` Oliver Xymoron
2002-08-18 16:54     ` Robert Love
2002-08-18 17:18       ` Oliver Xymoron
2002-08-18 17:20         ` Robert Love
2002-08-19  5:43 ` Theodore Ts'o
2001-11-02 10:05   ` Pavel Machek
2002-08-19  6:06   ` *Challenge* Finding a solution (When kernel boots it does not display any system info) louie miranda
2002-08-19  7:30     ` Gilad Ben-Yossef
2002-08-19  7:30     ` Ryan Cumming
2002-08-20  0:55       ` louie miranda
2002-08-19 13:52   ` [PATCH] (0/4) Entropy accounting fixes Oliver Xymoron
2002-08-20  8:59     ` Tommi Kyntola
2002-08-20 13:21       ` Oliver Xymoron
2002-08-20 16:19         ` Tommi Kyntola
2002-08-20 17:22           ` Oliver Xymoron [this message]
2002-09-08  3:51             ` D. Hugh Redelmeier
2002-09-08  4:31               ` Oliver Xymoron
  -- strict thread matches above, loose matches on Subject: below --
2002-08-18  4:57 David Brownell
2002-08-18  6:02 ` Oliver Xymoron

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=20020820172215.GE19225@waste.org \
    --to=oxymoron@waste.org \
    --cc=kynde@ts.ray.fi \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox