[omnetpp] Random seeds selection

549 views
Skip to first unread message

Anna Egorova-Förster

unread,
Oct 24, 2006, 5:45:22 AM10/24/06
to OMNeT++ Discussion List
Hello all,

I am using the random number generator cLCG32 for my omnet++
simulations. My simulation runs under the MF 2.02 and omnet 3.2p1 and
uses the CSMA Nic. Every time I send a packet down or up I am adding a
small random double, so that no messages cross each other:

double delay = dblrand()/10.f;
sendDelayedDown(new_msg, delay);

The problem is, depending on the seed value, I have all possible
scenarios: all messages get through without any problems, NO messages
get through or only a fraction of them.

Does somebody else have the same problem or some idea how to manage the
situation? Obviously, choosing the seed value is important. However,
when running simulations for, e.g. 100 runs, with automatically
generated seed values for each of the runs, it is impossible to track
them and the results get very skewed!

Any ideas are welcome!
Anna
--
__________________________
Anna Egorova-Foerster
PhD Student
University of Lugano
Via G.Buffi 6, 6900 Lugano
Switzerland
_______________________________________________
OMNeT++ Mailing List
options: http://lists.omnetpp.org/mailman/listinfo/omnetpp-l
archive: http://www.omnetpp.org/listarchive/index.php

Andreas Koepke

unread,
Oct 24, 2006, 6:20:27 AM10/24/06
to OMNeT++ Discussion List
Are you sure that you want to use the LCG32? You can only draw about
32000 relatively independent values from it. I'd first change to
Mersenne Twister...

The CSMA Mac layer is non-persistent, so a small random delay is added
anyway. You could try to change the backoff behaviour to a truncated
binary exponential -- this should stabilize things:

In
void CSMAMacLayer::scheduleBackoff()
change:

double time = intrand(initialCW - txAttempts)*slotDuration
+ 2.0*dblrand()*slotDuration;

to: double time = 2.0*(initialCW << txAttempts)*slotDuration*dblrand();

(The first one tries to be a bit fair, at the expense of stability).

Best, Andreas

Anna Egorova-Förster wrote:
> Hello all,
>
> I am using the random number generator cLCG32 for my omnet++
> simulations. My simulation runs under the MF 2.02 and omnet 3.2p1 and
> uses the CSMA Nic. Every time I send a packet down or up I am adding a
> small random double, so that no messages cross each other:
>
> double delay = dblrand()/10.f;
> sendDelayedDown(new_msg, delay);
>
> The problem is, depending on the seed value, I have all possible
> scenarios: all messages get through without any problems, NO messages
> get through or only a fraction of them.
>
> Does somebody else have the same problem or some idea how to manage the
> situation? Obviously, choosing the seed value is important. However,
> when running simulations for, e.g. 100 runs, with automatically
> generated seed values for each of the runs, it is impossible to track
> them and the results get very skewed!
>
> Any ideas are welcome!
> Anna

_______________________________________________

Mirco Musolesi

unread,
Oct 24, 2006, 6:56:50 AM10/24/06
to OMNeT++ Discussion List

Hi Anna,

> Does somebody else have the same problem or some idea how to manage the
> situation? Obviously, choosing the seed value is important. However,
> when running simulations for, e.g. 100 runs, with automatically
> generated seed values for each of the runs, it is impossible to track
> them and the results get very skewed!

I had a similar problem. It seems that after a while, with multiple
runs, in some cases the random number generator provides numbers
completely outside of the range defined by the user.

I solved the problem by running multiple runs from a bash script that is
executing a single run using a cycle (i.e., using run -$i)

Another problem may be related to the fact that global variables may not
be re-initialized correctly executing multiple subsequent runs (I
remember a post about this a while ago).

Mirco


--
Mirco Musolesi
Dept. of Computer Science, University College London
Gower Street London WC1E 6BT United Kingdom
Phone: +44 20 7679 0391 Fax: +44 20 7387 1397
Web: http://www.cs.ucl.ac.uk/staff/m.musolesi

Anna Egorova-Förster

unread,
Oct 25, 2006, 5:22:15 AM10/25/06
to OMNeT++ Discussion List
What do you mean by "completely outside of the range defined by the
user"? And, when using the same run number, the random number generator
starts always with the same seed, so there will be absolutely no random
behavior??

Mirco Musolesi wrote:
> Hi Anna,
>
> > Does somebody else have the same problem or some idea how to manage the
> > situation? Obviously, choosing the seed value is important. However,
> > when running simulations for, e.g. 100 runs, with automatically
> > generated seed values for each of the runs, it is impossible to track
> > them and the results get very skewed!
>
> I had a similar problem. It seems that after a while, with multiple
> runs, in some cases the random number generator provides numbers
> completely outside of the range defined by the user.
>
> I solved the problem by running multiple runs from a bash script that is
> executing a single run using a cycle (i.e., using run -$i)
>
> Another problem may be related to the fact that global variables may not
> be re-initialized correctly executing multiple subsequent runs (I
> remember a post about this a while ago).
>
> Mirco
>
>

--

__________________________
Anna Egorova-Foerster
PhD Student
University of Lugano
Via G.Buffi 6, 6900 Lugano
Switzerland

Mirco Musolesi

unread,
Oct 25, 2006, 5:30:06 AM10/25/06
to OMNeT++ Discussion List

Anna Egorova-Förster wrote:
> What do you mean by "completely outside of the range defined by the
> user"?

Like in the generation of numbers between 0 and 1, I got some negative
numbers of order of magnitude 10^6...

And, when using the same run number, the random number generator
> starts always with the same seed, so there will be absolutely no random
> behavior??

Yes (in theory). However, with multiple runs using the initialisation in
the omnetpp.ini file, after a certain number of runs, I got very strange
results. I was not really able to explain that behaviour...just to
report my experience. As I said, the problem was solved by executing
single runs from a bash file.

Mirco


--
Mirco Musolesi
Dept. of Computer Science, University College London
Gower Street London WC1E 6BT United Kingdom
Phone: +44 20 7679 0391 Fax: +44 20 7387 1397
Web: http://www.cs.ucl.ac.uk/staff/m.musolesi

Reply all
Reply to author
Forward
0 new messages