The reliable but not very sexy way to seed random

robtillaart: I have posted it as an issue

Thanks!

I'm not sure increasing to long will do any good - looking online, the prototype for srand always seems to be int:

void srand ( unsigned int seed );

Do we have source to look into?

And also, if the zero test is needed, something should happen - that randomSeed(0); does nothing at all is counterintuitive.

Instead of:

void randomSeed(unsigned long seed)
{
  if (seed != 0) 
  {
    srandom(seed);
  }
}

Even this would be more useful:

void randomSeed(unsigned long seed)
{
  if (seed == 0) 
    seed=1;
  srandom(seed);
}

or even

void randomSeed(unsigned long seed)
{
  srandom(seed|1);
}

[quote author=David Pankhurst link=topic=66206.msg505806#msg505806 date=1312567560]I'm not sure increasing to long will do any good[/quote]

It does.

  • looking online, the prototype for srand

You are searching for the wrong function. random / srandom is used not rand / srand.

Do we have source to look into?

Yes. The source code for random / srandom can be found searching for "avr libc".

An article I came across - http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0 -

Thanks. That was an interesting read.

Interesting technique, I wonder if they'll spin it off to a 3-pin chip anyone can use?


Rob

The big difference that Intel brings to the table is generation rate. In the article, the author claims a raw bit rate of 3 gigabits per second. That just cries out "simulation". I suspect that is the market they are targeting. Which means the generator, at least initially, will always be coupled with a processor capable of doing useful things with all that random data.

In other words, until they develop a 3-pin i7, I think we're out of luck.

robtillaart:

An article I came across - http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0 -

Well, that’s interesting. I hadn’t known that Intel was including a hardware RNG. In Linux, the kernel still gathers entropy:

The random number generator gathers environmental noise from device drivers and other sources into an entropy pool. The generator also keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created. (from man random)

Probably some reason for doing it. Maybe, for some purposes, only a few hundred kilobits of random numbers a second isn’t enough? I have no idea.

Looking at the simplified drawing (without knowing it was that) I thought, hey, I have inverter ICs, I could try that. But then comes the rub:

To keep the inverters in balance, we built a feedback loop into the new hardware. The circuitry in that loop performs some targeted fiddling until the two possible output values, 0 and 1, each occur roughly half the time.

And they’re using IGFETS – maybe I could subsitute MOSFETs, or something else, as long as I don’t care about how fast the switching is. I don’t have the knowledge to know whether there’s some reason an insulated gate FET is needed here. And, even without the feedback loop, there’s more to it than drawn – VCC and ground, e.g.

An article I came across - http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0 -

Very interesting article.

The big difference that Intel brings to the table is generation rate. In the article, the author claims a raw bit rate of 3 gigabits per second. That just cries out “simulation”. I suspect that is the market they are targeting. Which means the generator, at least initially, will always be coupled with a processor capable of doing useful things with all that random data.

In other words, until they develop a 3-pin i7, I think we’re out of luck.

I wonder if anyone has made a chip of their initial analogue approach http://www.cryptography.com/public/pdf/IntelRNG.pdf (Block diagram is on Page 3 of the link). This still has a digital corrector and I’m guessing they’re not interesting in making one themselves.

Iain

sixeyes: I wonder if anyone has made a chip of their initial analogue approach http://www.cryptography.com/public/pdf/IntelRNG.pdf (Block diagram is on Page 3 of the link). This still has a digital corrector and I'm guessing they're not interesting in making one themselves.

Well, my first question would be what the signal level is from an undriven resistor.

robtillaart: An article I came across - http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0 -

I happened across that the other day as well, the September issue of IEEE Spectrum just arrived, it's the cover story!

The latest version…

#include <avr/eeprom.h>

/*==============================================================================
  Call reseedRandom once in setup to start random on a new sequence.  Uses 
  four bytes of EEPROM.
==============================================================================*/

void reseedRandom( uint32_t* address )
{
  static const uint32_t HappyPrime = 127807 /*937*/;
  uint32_t raw;
  unsigned long seed;

  // Read the previous raw value from EEPROM
  raw = eeprom_read_dword( address );

  // Loop until a seed within the valid range is found
  do
  {
    // Incrementing by a prime (except 2) every possible raw value is visited
    raw += HappyPrime;

    // Park-Miller is only 31 bits so ignore the most significant bit
    seed = raw & 0x7FFFFFFF;
  }
  while ( (seed < 1) || (seed > 2147483646) );

  // Seed the random number generator with the next value in the sequence
  srandom( seed );  

  // Save the new raw value for next time
  eeprom_write_dword( address, raw );
}

inline void reseedRandom( unsigned short address )
{
  reseedRandom( (uint32_t*)(address) );
}


/*==============================================================================
  So the reseedRandom raw value can be initialized allowing different 
  applications or instances to have different random sequences.

  Generate initial raw values...

  https://www.random.org/cgi-bin/randbyte?nbytes=4&format=h
  https://www.fourmilab.ch/cgi-bin/Hotbits?nbytes=4&fmt=c&npass=1&lpass=8&pwtype=3

==============================================================================*/

void reseedRandomInit( uint32_t* address, uint32_t value )
{
  eeprom_write_dword( address, value );
}

inline void reseedRandomInit( unsigned short address, uint32_t value )
{
  reseedRandomInit( (uint32_t*)(address), value );
}


uint32_t reseedRandomSeed EEMEM = 0xFFFFFFFF;

void setup( void )
{
/*
  // Example that sets the seed to a specific value
  // Typically only done during debugging
  // Uses EEMEM to determine the EEPROM address
  reseedRandomInit( &reseedRandomSeed, 42 );
*/

  // Example that reseeds the random number generator each time the application starts
  // Uses EEMEM to determine the EEPROM address
  // Most common use
  reseedRandom( &reseedRandomSeed );

/*
  // Example that sets the seed to a specific value
  // Typically only done during debugging
  // EEPROM address 0 (through 3) is used to store the seed
  reseedRandomInit( (unsigned short) 0, 42 );
*/

/*
  // Example that reseeds the random number generator each time the application starts
  // EEPROM address 0 (through 3) is used to store the seed
  reseedRandom( (unsigned short) 0 );
*/
}


void loop( void )
{
}

Edit: 937 changed to 127807 to avoid the “dead zone”.

Thanks,

If I see correctly the code is essentially the same, mostly the reseeding improved Do you have performance numbers / footprint numbers ?

Time to make a class of it ? => multiple (pseudo)random sequences side by side :)

robtillaart: If I see correctly the code is essentially the same, mostly the reseeding improved

I simplified it a bit and added some comments. The code is basically the same as the first version.

Do you have performance numbers / footprint numbers ?

At the very most, the do-while executes twice so it should be faster than generating a random number.

I'll check the size tomorrow.

Time to make a class of it ? => multiple (pseudo)random sequences side by side :)

:D I think I've spent enough time on it. I have an ATtiny84 that has been begging to play with my three new thermistors.

Regarding analogRead on a floating pin...

http://www.academia.edu/1161820/Ardrand_The_Arduino_as_a_Hardware_Random-Number_Generator

See Section 5.1 if you don't want to wade through the details.

[quote author=Coding Badly link=topic=66206.msg630884#msg630884 date=1324535325]

Regarding analogRead on a floating pin...

http://reykjavik.academia.edu/BenediktKristinsson/Papers/1225216/Ardrand_The_Arduino_as_a_Hardware_Random-Number_Generator

See Section 5.1 if you don't want to wade through the details.

[/quote]

As I recall this doesn't disagree with the general conclusions of our rather long posted threads on the same subject. As I recall we were still in search of a more 'perfect' initialization of the seed function?

Lefty

[quote author=Coding Badly link=topic=66206.msg630884#msg630884 date=1324535325] Regarding analogRead on a floating pin...

http://reykjavik.academia.edu/BenediktKristinsson/Papers/1225216/Ardrand_The_Arduino_as_a_Hardware_Random-Number_Generator [/quote]

Bletcherous Scribd. Anyone have a direct link to a PDF? I'd like to read that.

retrolefty: As I recall this doesn't disagree with the general conclusions of our rather long posted threads on the same subject. As I recall we were still in search of a more 'perfect' initialization of the seed function?

Well, I was not really getting anywhere with that. But I'd like to. However, I'm at a point where I think I really need an o-scope. If not for my decrepit Volvo finally reaching the point where I decided to replace it, I might have picked one up this month. And I probably need some other dual op-amp ICs to try out. I was sorta eyeballing a Tektronix 2336 YA -- portable, 100mhz, dual trace. Appeal for me is the ability to close the case, thus protecting the front panel. With all the junk I have around, that's a big plus.

justjed: Bletcherous Scribd. Anyone have a direct link to a PDF? I'd like to read that.

Yes, Blecherous Scribd indeed (I'm the author of this paper). You can find a normal PDF on http://benedikt.sudo.is/ardrand.pdf.

retrolefty: As I recall this doesn't disagree with the general conclusions of our rather long posted threads on the same subject.

That's my recollection as well.

As I recall we were still in search of a more 'perfect' initialization of the seed function?

Yup.

Well, reseedRandom may not be perfect but it is a reasonable choice. :D

@benediktkr: Thank for the research and the paper.