linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Stephan Mueller <smueller@chronox.de>
Cc: "Theodore Ts'o" <tytso@mit.edu>, "David Jaša" <djasa@redhat.com>,
	"Andi Kleen" <andi@firstfloor.org>,
	sandyinchina@gmail.com,
	"Jason Cooper" <cryptography@lakedaemon.net>,
	"John Denker" <jsd@av8n.com>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	"Joe Perches" <joe@perches.com>, "Pavel Machek" <pavel@ucw.cz>,
	"George Spelvin" <linux@horizon.com>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 0/5] /dev/random - a new approach
Date: Tue, 21 Jun 2016 15:31:07 -0400	[thread overview]
Message-ID: <e7ab11a3-8bc5-ac3f-4034-87f5a8835b02@gmail.com> (raw)
In-Reply-To: <1900555.p3fYFz9p7D@positron.chronox.de>

On 2016-06-21 14:04, Stephan Mueller wrote:
> Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn:
>>>> 6. You have a significant lack of data regarding embedded systems, which
>>>> is one of the two biggest segments of Linux's market share.  You list no
>>>> results for any pre-ARMv6 systems (Linux still runs on and is regularly
>>>> used on ARMv4 CPU's, and it's worth also pointing out that the values on
>>>> the ARMv6 systems are themselves below average), any MIPS systems other
>>>> than 24k and 4k (which is not a good representation of modern embedded
>>>> usage), any SPARC CPU's other than UltraSPARC (ideally you should have
>>>> results on at least a couple of LEON systems as well), no tight-embedded
>>>> PPC chips (PPC 440 processors are very widely used, as are the 7xx and
>>>> 970 families, and Freescale's e series), and only one set of results for
>>>> a tight-embedded x86 CPU (the Via Nano, you should ideally also have
>>>> results on things like an Intel Quark).  Overall, your test system
>>>> selection is not entirely representative of actual Linux usage (yeah,
>>>> ther'es a lot of x86 servers out there running Linux, there's at least
>>>> as many embedded systems running it too though, even without including
>>>> Android).
>>>
>>> Perfectly valid argument. But I programmed that RNG as a hobby -- I do not
>>> have the funds to buy all devices there are.
>>
>> I'm not complaining as much about the lack of data for such devices as I
>> am about you stating that it will work fine for such devices when you
>> have so little data to support those claims.  Many of the devices you
>
> Little data, interesting statement for results on 200+ systems including all
> major CPU arches all showing information leading in the same directions.

Let me try rephrasing this to make it a bit clearer:
1. You have lots of data on server systems.
2. You have a significant amount of data on desktop/workstation type 
systems.
3. You have very little data on embedded systems.

and here are your arguments:
A. This works well on server systems.
B. This works well on desktop systems.
C. This works well on embedded systems.

Arguments A and B are substantiated directly by points 1 and 2. 
Argument C is not substantiated thoroughly because of point 3.
My complaint is about argument C given point 3.

I'm not saying you have insufficient data to support argument A or B, 
only that you have insufficient data to support argument C.

Android barely counts as an embedded system anymore, as many Android 
phones can outperform most inexpensive desktop and laptop systems, and 
even some rather expensive laptops.  This leaves the only systems that 
can be assumed without further information to be representative of 
embedded boards to be the ones running Genode, and possibly the MIPS 
systems, which is a total of about 10 results out of hundreds for 
servers and desktops/workstations.

  reply	other threads:[~2016-06-21 19:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31 18:37 [PATCH v4 0/5] /dev/random - a new approach Stephan Mueller
2016-05-31 18:37 ` [PATCH v4 1/5] crypto: DRBG - externalize DRBG functions for LRNG Stephan Mueller
2016-05-31 18:38 ` [PATCH v4 2/5] random: conditionally compile code depending on LRNG Stephan Mueller
2016-05-31 18:39 ` [PATCH v4 3/5] crypto: Linux Random Number Generator Stephan Mueller
2016-05-31 18:39 ` [PATCH v4 4/5] crypto: LRNG - enable compile Stephan Mueller
2016-05-31 18:39 ` [PATCH v4 5/5] random: add interrupt callback to VMBus IRQ handler Stephan Mueller
2016-05-31 22:34 ` [PATCH v4 0/5] /dev/random - a new approach George Spelvin
2016-06-15 16:17 ` David Jaša
2016-06-15 16:58   ` Stephan Mueller
2016-06-17 13:56     ` David Jaša
2016-06-17 15:26       ` Sandy Harris
2016-06-18  8:22         ` Stephan Mueller
2016-06-18  8:21       ` Stephan Mueller
2016-06-18 14:44       ` Theodore Ts'o
2016-06-18 16:31         ` Stephan Mueller
2016-06-20 17:07           ` Austin S. Hemmelgarn
2016-06-20 18:32             ` Stephan Mueller
2016-06-21 13:05               ` Austin S. Hemmelgarn
2016-06-21 13:19                 ` Tomas Mraz
2016-06-21 17:18                   ` Austin S. Hemmelgarn
2016-06-21 17:23                     ` Stephan Mueller
2016-06-21 17:54                       ` Austin S. Hemmelgarn
2016-06-21 18:05                         ` Stephan Mueller
2016-06-21 13:20                 ` Stephan Mueller
2016-06-21 17:51                   ` Austin S. Hemmelgarn
2016-06-21 18:04                     ` Stephan Mueller
2016-06-21 19:31                       ` Austin S. Hemmelgarn [this message]
2016-06-22  5:16                         ` Stephan Mueller
2016-06-22 12:54                           ` Austin S. Hemmelgarn
2016-06-22 13:25                             ` Stephan Mueller
2016-06-21 13:42                 ` Pavel Machek
2016-06-21 17:17                   ` Austin S. Hemmelgarn
2016-06-21 12:25         ` David Jaša

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=e7ab11a3-8bc5-ac3f-4034-87f5a8835b02@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=andi@firstfloor.org \
    --cc=cryptography@lakedaemon.net \
    --cc=djasa@redhat.com \
    --cc=hpa@linux.intel.com \
    --cc=joe@perches.com \
    --cc=jsd@av8n.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=pavel@ucw.cz \
    --cc=sandyinchina@gmail.com \
    --cc=smueller@chronox.de \
    --cc=tytso@mit.edu \
    /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;
as well as URLs for NNTP newsgroup(s).