On 08.05.17 23:51, Richard Outerbridge wrote:
> On 2017-05-08 12:08:58 +0000, Karl.Frank said:
>
>> On 07.05.17 08:25, Richard Outerbridge wrote:
>>> On 2017-05-01 18:46:34 +0000, Karl.Frank said:
>>>
>>>> I have uploaded a short ANSI-C source code that can test the output of
>>>> any PRNG using the TESTU01 test battery by reading in 32bit values from
>>>> STDIN.
>>>
>>> This is pretty handy, especially if one already has TestU01 installed.
>
> [....]
>
>> The problem you mentioned on how many samples to pipe in is not an easy
>> to estimate parameter.
>
> [....]
>
> Yes, you're right, the input requirements of the TestU01 Crush tests seem
> to vary according to the actual contents of the stream under test. So the
> limit would seem to be how many samples (4,294,967,295 single bytes or even
> better 17,179,869,180 bytes as 4,294,967,295 32Bit chunks) you can instruct
> the generator to produce.
>
I figured out that passing 0xfffffffe as 32bit samples for a SmallCrush
and 0xfffffffffffffe for Crush should suffice to run both tests with a
piped input. TestU01_stdin simply stops when all needed samples are
processed and analysed. Yet I suppose 0xfffffffffffffffe samples might
be needed for the BigCrush.

The recently mentioned error origin to the fact that the machine running
the Crush test does not has sufficient RAM.

snpair_ClosePairs test:
-----------------------------------------------
N = 10, n = 2000000, r = 0, t = 2, p = 0, m = 30, Torus = TRUE

********* WARNING in file snpair.c on line 294
********* res->NumClose > 50000

On a quick check it becomes evident that the Crush test consumes up to
800MB of RAM and round about 750MB virtual Memory. Not yet tested the
RAM needed for BigCrush.

>> By the way, on which PRNG did you perform the test runs?
>> Did it survive SmallCrush, Crush and BigCrush?
>
> On my own, of course :) And yes, after 18 hours, it eventually did. This
> was using a bespoke interface (the generator was integrated with the
> tests).
> __outer
>
Well, essentially one could easily replace the function stdin32bit() on
top of the source code with his own PRNG algorithm. That's what I did in
the first place when publishing my PRNG algorithms alongside the
TestU01 results. But piping the keystream is more flexible, for example
if you like to check the randomness quality of a stream cipher or even a
hash function ;-)

Did you already publish your PRNG algorithm?

--
cHNiMUBACG0HAAAAAAAAAAAAAABIZVbDdKVM0w1kM9vxQHw+bkLxsY/Z0czY0uv8/Ks6WULxJVua
zjvpoYvtEwDVhP7RGTCBVlzZ+VBWPHg5rqmKWvtzsuVmMSDxAIS6Db6YhtzT+RStzoG9ForBcG8k
G97Q3Jml/aBun8Kyf+XOBHpl5gNW4YqhiM0=

On 2017-05-09 20:39:00 +0000, Karl.Frank said:

> On 08.05.17 23:51, Richard Outerbridge wrote:
>> On 2017-05-08 12:08:58 +0000, Karl.Frank said:
>>
>>> On 07.05.17 08:25, Richard Outerbridge wrote:
>>>> On 2017-05-01 18:46:34 +0000, Karl.Frank said:

[....]

>>> By the way, on which PRNG did you perform the test runs?
>>> Did it survive SmallCrush, Crush and BigCrush?
>>
>> On my own, of course :) And yes, after 18 hours, it eventually did. This
>> was using a bespoke interface (the generator was integrated with the
>> tests).
>> __outer
>>
> Well, essentially one could easily replace the function stdin32bit() on
> top of the source code with his own PRNG algorithm. That's what I did in
> the first place when publishing my PRNG algorithms alongside the
> TestU01 results. But piping the keystream is more flexible, for example
> if you like to check the randomness quality of a stream cipher or even a
> hash function ;-)
>
> Did you already publish your PRNG algorithm?

It's been exposed for public ridicule, yes. Send me an email, why not?
__outer