I'm trying to get a random seed for srand function, but it seems like
I can't use the time as seed, since the only function that allows that
is ctime, and when I use it inside my code I pass from 39Kb of binary
to 52Kb or so.. which exceeds my available memory... is there any
other way to get a random seed?
Or maybe is there a way to tell the compiler to just use the ctime
function and forget about all the rest of the library?
I'm programming on a C5471 Texas Instruments DSP.. and I don't see any
other way of getting a random event as seed... I mean... everything
not really random, but the time you start running the code...
Thanks and sorry for the OT
Cheers
RM

InuY4sha <inuy4sha@gmail.com> wrote:
> I'm trying to get a random seed for srand function, but it seems like
> I can't use the time as seed, since the only function that allows that
> is ctime,

ctime() looks to me rather useless for that purpose since it
just converts a time_t value to a string, did you perhaps
meant time()?

> and when I use it inside my code I pass from 39Kb of binary
> to 52Kb or so.. which exceeds my available memory... is there any
> other way to get a random seed?
> Or maybe is there a way to tell the compiler to just use the ctime
> function and forget about all the rest of the library?

That's not possible to answer without knowing what compiler
and linker you are using. But then things wouldn't be a
question of C anymore but about the specific tools on your
machine and better discussed somewhere else.

> I'm programming on a C5471 Texas Instruments DSP.. and I don't see any
> other way of getting a random event as seed... I mean... everything
> not really random, but the time you start running the code...

If your system has a clock (otherwise where would time() etc.
get its time from?) then there are probably also some system
specific ways (I guess you wouldn't mind to use them) to get
at it. But that's hardly a question for this group (perhaps
you will find some experts in comp.dsp and perhaps there's
even a random generator in the DSP for creating white noise?)
and none that I could answer.

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de

InuY4sha ha scritto:

> is there any
> other way to get a random seed?

(srand(getpid());

nembo kid <nembo@kid> wrote:

> InuY4sha ha scritto:
>
> > is there any
> > other way to get a random seed?
>
> (srand(getpid());

That's a fabulous way of getting a _non_-random seed when you call it
under several circumstances, many of which can happen on a DSP.

Richard

On May 27, 5:13 pm, nembo kid <nembo@kid> wrote:
> InuY4sha ha scritto:
>
> > is there any
> > other way to get a random seed?
>
> (srand(getpid());

Linux' default limit of pids is SHRT_MAX, so that's a bad idea.
It's not random at all.

On May 27, 2:07 pm, InuY4sha <inuy4...@gmail.com> wrote:
> I'm trying to get a random seed for srand function, but it seems like
> I can't use the time as seed, since the only function that allows that
> is ctime, and when I use it inside my code I pass from 39Kb of binary
> to 52Kb or so.. which exceeds my available memory... is there any
> other way to get a random seed?
> Or maybe is there a way to tell the compiler to just use the ctime
> function and forget about all the rest of the library?
> I'm programming on a C5471 Texas Instruments DSP.. and I don't see any
> other way of getting a random event as seed... I mean... everything
> not really random, but the time you start running the code...

http://xkcd.com/221/

There is no such thing as a software random number generator, so
hardware is the only true answer to your question. If your DSP has a
spare ADC you can create a chaotic resistor-capacitor network very
simply and use that.

If you don't have access to much hardware, then you can use something
like the process-id (as already suggested) but note that that will
only be random if it is directly influenced by hardware - that is, a
user application on a multi-user system is influenced by the hardware
(user-interfaces) that start processes. If your system process-ids
are not influenced by the user - eg: you always have the same small
set of services running - then they are no good.

So the answer is - think hardware, and if that fails think about
indirect hardware.

HTH
viza

InuY4sha <inuy4sha@gmail.com> writes:
> I'm trying to get a random seed for srand function, but it seems like
> I can't use the time as seed, since the only function that allows that
> is ctime, and when I use it inside my code I pass from 39Kb of binary
> to 52Kb or so.. which exceeds my available memory... is there any
> other way to get a random seed?
> Or maybe is there a way to tell the compiler to just use the ctime
> function and forget about all the rest of the library?
> I'm programming on a C5471 Texas Instruments DSP.. and I don't see any
> other way of getting a random event as seed... I mean... everything
> not really random, but the time you start running the code...

A common way to seed the random number generator is

srand(time(NULL));

Since using ctime makes no sense, I'm guessing that's what you meant.

Note that srand(time(NULL)) has several problems. One is that the
result of the time() function is of type time_t. The standard's only
guarantee about time_t is that it's an arithmetic type capable of
representing times. It could conceivably be a floating-point value
between 0.0 and 1.0; in that case, the above call would be equivalent
to srand(0). On real-world systems, this isn't likely to be a
problem, particularly if you're not concerned with 100% perfect
portability.

Another problem is predictability. If an observer knows, or can
guess, when the program started, he can anticipate the stream of
random numbers it's going to use. For cryptographic applications,
this is a fatal flaw. For other applications, it might not matter.

Finally, the algorithm used by the rand() provided with a C
implementation is often not very good.

If the system time and the rand() function are good enough for your
purposes, but you can't use the time() function, you'll have to find
some system-specific way to get the current time. I have no idea what
that might be, but the time() implementation must use some underlying
mechanism.

Is there any possibility of obtaining some random data (to be used as
a seed) from an external source? Or can you maintain the state of
your random number generator on the system between runs, so you don't
have to re-initialize it each time (though that could cause
predictability problems).

Beyond that, I don't think there's much we can offer here. You
might try comp.arch.embedded or comp.dsp.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Richard Bos writes:
>nembo kid <nembo@kid> wrote:
>>InuY4sha ha scritto:
>>
>>> is there any
>>> other way to get a random seed?
>>
>> (srand(getpid());
>
> That's a fabulous way of getting a _non_-random seed when you call it
> under several circumstances, many of which can happen on a DSP.

Can still grab it in addition to time() though, and mix both to get a
seed. Other things one could try to mix in:
- clock() with time used by the eprocess.
- an uninitialized unsigned int variable on the stack - might
get a garbage value from elsewhere in the program.
- (unsigned) <the address of a variable on the stack>
- (unsigned) <some malloced pointer>
Though first look around for system-dependent functions. Such as:
- Are you sure there is no equivalent to a /dev/random device?
- Or some other input device you can grab some garbage data from?
- a time function with better resultion. gettimeofday()/ftime()?
- old user input or events which might be lying around in a buffer
somewhere. In particular if these have times attached.
Anyway, all that belongs on a forum for your OS/C implementation.

--
Hallvard

Keith Thompson writes:
> Another problem is predictability. If an observer knows, or can
> guess, when the program started, he can anticipate the stream of
> random numbers it's going to use. For cryptographic applications,
> this is a fatal flaw. For other applications, it might not matter.

Yes. If predictability is a problem, some of my user input and
"hopefully random" suggestions may be worse than useless - they may
enable a user to _force_ a particular seed.

--
Hallvard

> A common way to seed the random number generator is
>
> srand(time(NULL));
>
> Since using ctime makes no sense, I'm guessing that's what you meant.

Well I read the includes/time.h header file in the compiler folder, and I
only saw the ctime function It was very stupid of me to think straight
that this would be the required function .. but I hadn't use the time.h
structures and function before, so I fall for that...

> Note that srand(time(NULL)) has several problems. One is that the
> result of the time() function is of type time_t. The standard's only
> guarantee about time_t is that it's an arithmetic type capable of
> representing times. It could conceivably be a floating-point value
> between 0.0 and 1.0; in that case, the above call would be equivalent to
> srand(0).

If I remind correctly, the time_t was a standard unsigned integer... but
I'll check tomorrow and eventually let you know.


> Another problem is predictability. If an observer knows, or can guess,
> when the program started, he can anticipate the stream of random numbers
> it's going to use. For cryptographic applications, this is a fatal
> flaw. For other applications, it might not matter.

I need this random number to generate random backoff idle periods in a
wireless network

> Is there any possibility of obtaining some random data (to be used as a
> seed) from an external source? Or can you maintain the state of your
> random number generator on the system between runs, so you don't have to
> re-initialize it each time (though that could cause predictability
> problems).

I could get the seed from an ARM which the DSP communicates with.. the
ARM is more powerful and doesn't have memory limitations. But it's a
dirty hack.

>
> Beyond that, I don't think there's much we can offer here. You
> might try comp.arch.embedded or comp.dsp.

I'll try that for sure, and this was far more than what I expected



--
InuY4sha

On May 27, 4:50pm, viza <tom.v...@gmail.com> wrote:

> There is no such thing as a software random number generator, so
> hardware is the only true answer to your question. If your DSP has a
> spare ADC you can create a chaotic resistor-capacitor network very
> simply and use that.


That crossed my mind too, i.e. using the A-to-D to get some sort of
random voltage from somewhere, but I wonder how you'd get a random
voltage? What is a "chaotic resistor-capacitor network"?

> ctime() looks to me rather useless for that purpose since it just
> converts a time_t value to a string, did you perhaps meant time()?

I apologize, I saw that in time.h and in the man page of gettimeofday (if
I recall right) so I thought it was the function I was looking for... and
I was wrong I guess

--
InuY4sha

inuy4sha <sorry@nospam.it> wrote:
> If I remind correctly, the time_t was a standard unsigned integer... but
> I'll check tomorrow and eventually let you know.

Not 100% correct, the C standard doesn't require more than
that it is an "arithmetic types capable of representing
times", so in principle it could also be e.g. a double.
And if the time cannot be represented the return value
of time() is (time_t)-1 (whatever that exactly is;-). But
since what you want to do seems to be rather system spe-
cific and not meant to be portable, I wouldn't see any
harm in checking what time_t is on your system and use
it if it's an int or unsigned int.

Regadrs, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de

Hi

On May 27, 6:31 pm, Tomás Ó hÉilidhe <t...@lavabit.com> wrote:
> On May 27, 4:50 pm, viza <tom.v...@gmail.com> wrote:
>
> > There is no such thing as a software random number generator, so
> > hardware is the only true answer to your question. If your DSP has a
> > spare ADC you can create a chaotic resistor-capacitor network very
> > simply and use that.
>
> That crossed my mind too, i.e. using the A-to-D to get some sort of
> random voltage from somewhere, but I wonder how you'd get a random
> voltage? What is a "chaotic resistor-capacitor network"?

one example:
http://en.wikipedia.org/wiki/Chua's_circuit

It's a bit more complicated than I remembered, you need at least a
couple of diodes and an op-amp as well as Rs and Cs (in this one, at
least - others exist if the dual voltage requirement of an op-amp is a
nuisance to you).

viza

On May 27, 6:56 pm, viza <tom.v...@gmail.com> wrote:
> Hi
>
> On May 27, 6:31 pm, Tomás Ó hÉilidhe <t...@lavabit.com> wrote:
>
> > On May 27, 4:50 pm, viza <tom.v...@gmail.com> wrote:
>
> > > There is no such thing as a software random number generator, so
> > > hardware is the only true answer to your question. If your DSP has a
> > > spare ADC you can create a chaotic resistor-capacitor network very
> > > simply and use that.
>
> > That crossed my mind too, i.e. using the A-to-D to get some sort of
> > random voltage from somewhere, but I wonder how you'd get a random
> > voltage? What is a "chaotic resistor-capacitor network"?
>
> one example:http://en.wikipedia.org/wiki/Chua's_circuit
>
> It's a bit more complicated than I remembered, you need at least a
> couple of diodes and an op-amp as well as Rs and Cs (in this one, at
> least - others exist if the dual voltage requirement of an op-amp is a
> nuisance to you).

PS:
An alternative is to use some kind of sensor (eg: microphone) to input
random data. If you use something like that you will have to test by
experiment how random it really is, eg: does it consistently give zero
at night when it is quiet, does it always saturate in the rush hour
when it is noisy. Can attackers reproducibly influence the value, and
does that matter to your application.

inuy4sha wrote:
> [...]
> I need this random number to generate random backoff idle periods in a
> wireless network

Then you can probably make do with a fairly weak notion
of "randomness:" Your only concern is making sure that all
the network participants don't back off in lock-step with
each other and re-collide. You could probably get away with
not calling srand() at all and just using rand() with its
default seed, if the participating stations join the network
at different moments and/or see different histories of when
they need to back off.

If that's too simplistic for your peace of mind, then
seeding with the wall-clock time probably isn't enough to let
you rest easy, either. After all, the "current time of day"
as reported by N different computers is likely to be highly
correlated! On most systems, time() has a precision of one
second (C does not require this, but it's common practice),
so if the various clocks are all within five seconds, say, of
some external time standard there will be fewer than a dozen
different srand() seeds ...

Perhaps you could just generate and discard a rand() value
every so often, like each time a packet arrives. If different
stations see different packet streams, their rand() sequences
will get out of step even if they all started identically, and
that might be good enough.

--
Eric.Sosman@sun.com

inuy4sha <sorry@nospam.it> writes:
>> A common way to seed the random number generator is
>>
>> srand(time(NULL));
>>
>> Since using ctime makes no sense, I'm guessing that's what you meant.
>
> Well I read the includes/time.h header file in the compiler folder, and I
> only saw the ctime function It was very stupid of me to think straight
> that this would be the required function .. but I hadn't use the time.h
> structures and function before, so I fall for that...
[...]

I wrote the above quoted text, starting with "A common way ...".

Your newsreader should have generated an attribution line, something
like "kst-u@mib.org (Keith Thompson) writes:".

Please leave that line in place when you quote somebody in a followup.
It makes the discussion easier to follow, and it's just polite to give
credit when you quote somebody else's words.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

vipps...@gmail.com wrote:
> nembo kid <nembo@kid> wrote:
> > InuY4sha ha scritto:
> > > [Other than time()...] is there any
> > > other way to get a random seed?
> >
> > (srand(getpid());
>
> Linux' default limit of pids is SHRT_MAX, so
> that's a bad idea. It's not random at all.

There's no requirement for unsigned int to have
a range larger than USHRT_MAX. You're effectively
saying that _any_ attempt to portably call srand
is a bad idea.

--
Peter

In article <e0d87e22-71b4-4afa-8526-8a97250a6845@p39g2000prm.googlegroups.com>,
Peter Nilsson <airia@acay.com.au> wrote:

>> > (srand(getpid());

>> Linux' default limit of pids is SHRT_MAX, so
>> that's a bad idea. It's not random at all.

>There's no requirement for unsigned int to have
>a range larger than USHRT_MAX.

Given that the system has getpid(), this is not likely to be the case.

-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

"Eric Sosman" <Eric.Sosman@sun.com> wrote in message
news:1211913709.594405@news1nwk...
> inuy4sha wrote:
>> [...]
>> I need this random number to generate random backoff idle periods in a
>> wireless network
>
> Then you can probably make do with a fairly weak notion
> of "randomness:" Your only concern is making sure that all
> the network participants don't back off in lock-step with
> each other and re-collide. You could probably get away with
> not calling srand() at all and just using rand() with its
> default seed, if the participating stations join the network
> at different moments and/or see different histories of when
> they need to back off.
>
> If that's too simplistic for your peace of mind, then
> seeding with the wall-clock time probably isn't enough to let
> you rest easy, either. After all, the "current time of day"
> as reported by N different computers is likely to be highly
> correlated!
[...]

:^)

On May 28, 1:18 am, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
> In article <e0d87e22-71b4-4afa-8526-8a97250a6...@p39g2000prm.googlegroups.com>,
> Peter Nilsson <ai...@acay.com.au> wrote:
>
> >> > (srand(getpid());
> >> Linux' default limit of pids is SHRT_MAX, so
> >> that's a bad idea. It's not random at all.
> >There's no requirement for unsigned int to have
> >a range larger than USHRT_MAX.
>
> Given that the system has getpid(), this is not likely to be the case.
As Mr Tobin noted, this is not the case with systems that have POSIX
getpid(), because POSIX requires UINT_MAX to at least be 2**32-1.
(However, standard C requires UINT_MAX to be at least 2**16-1, 65535)
There was a security issue with debian a while ago in the OpenSSL
package. The initial seed was only the getpid() value.
<http://www.debian.org/security/2008/dsa-1571> for more information.

inuy4sha <sorry@nospam.it> writes:

> I need this random number to generate random backoff idle periods in a
> wireless network

If you have access to the network hardware, the MAC address (or
similar) might be all you need. In addition, wireless hardware often
records things like signal and noise levels that are likely to vary
from node to node.

--
Ben.

Ben Bacarisse wrote:
> inuy4sha <sorry@nospam.it> writes:
>
>> I need this random number to generate random backoff idle periods in
>> a wireless network
>
> If you have access to the network hardware, the MAC address (or
> similar) might be all you need.
But that then would create very predictable 'random' numbers.

> In addition, wireless hardware often
> records things like signal and noise levels that are likely to vary
> from node to node.
But not so much for a certain node. Probably more than the MAC though...

Bye, Jojo

Joachim Schmitz wrote:

> Ben Bacarisse wrote:
>> inuy4sha <sorry@nospam.it> writes:
>>
>>> I need this random number to generate random backoff idle
>>> periods in a wireless network
>>
>> If you have access to the network hardware, the MAC address
>> (or similar) might be all you need.
> But that then would create very predictable 'random' numbers.

That's not the point, if the OPs intention is to resolve network
collisions. He'll be fine if the method ensures, that no two
stations are likely to start transmission at the same time.

Given a good PRNG (like mersene twister) it's sufficient to start
each PRNG with it's own seed. In the OPs applications it even is
no problem if single PRNGs get reinitialized by a system reset.

OTOH he's implementing it on a DSP. I bet there's some hardware
attached, that delivers some entropy. Like the lowest
significant bit of an A/D conversion.

Wolfgang Draxinger
--
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867

"Joachim Schmitz" <nospam.jojo@schmitz-digital.de> writes:

> Ben Bacarisse wrote:
>> inuy4sha <sorry@nospam.it> writes:
>>
>>> I need this random number to generate random backoff idle periods in
>>> a wireless network
>>
>> If you have access to the network hardware, the MAC address (or
>> similar) might be all you need.
> But that then would create very predictable 'random' numbers.

That isn't a problem for this case. The values aren't be used for
cryptographic reasons, but rather to make sure the different machines
exhibit slightly different behaviour.


--
Lowell Gilbert, embedded/networking software engineer
http://be-well.ilk.org/~lowell/