[Click] nsclick rng support for ns3

Eddie Kohler ekohler at gmail.com
Fri Jan 25 14:01:00 EST 2013 

It's well worth your time to learn Git. It's very, very easy to "fork"
a repository on Github—sign up, and then it's one click.

That said I'm happy to take patches if that's much easier for you.

I felt it was better to have uniform seeding behavior on NS: seeding
*never* works. That's more self consistent (& we could imagine a
warning). But it'd be fine to seed the userlevel RNG too.
E


On Fri, Jan 25, 2013 at 10:32 AM, Sascha Alexander Jopen
<jopen at informatik.uni-bonn.de> wrote:
> Hi Eddie,
>
> but shouldn't we allow seeding the userlevel random number generator, in
> case there is no support for ns3 random numbers?
>
> I do not have any git repositories and do not understand git workflows
> very well. Do i have to create a github repository as a fork of the
> click git repository to issue pull requests? Or does any other git
> repository work, too?
>
> Sascha
>
> On 25.01.2013 15:34, Eddie Kohler wrote:
>> Hi Sascha!
>>
>> I like this one much better, and checked in a version of it with a few changes.
>> - Explicit case for srandom() which does nothing
>> - Don't chatter if no node, just fall back to user level
>> - No userlevel_random(), just put click_random() in ns/nsclick.cc
>>
>> I hope it works for you. If it doesn't, send a pull request?
>> E
>>
>> On Fri, Jan 25, 2013 at 7:06 AM, Sascha Alexander Jopen
>> <jopen at informatik.uni-bonn.de> wrote:
>>> Hey,
>>>
>>> i just tested this new patchset for random number support. It includes
>>> fallback to userlevel random() or rand() in case of lacking support on
>>> the ns3 side. Furthermore, ns3 returns random numbers in the range [0,
>>> CLICK_RAND_MAX] whatever CLICK_RAND_MAX is on the platform where click
>>> was compiled, as long as CLICK_RAND_MAX <= 0xFFFFFFFFU. This is done by
>>> sending the actual CLICK_RAND_MAX value along with simclick_sim_command.
>>> The ns3 side patch includes the changes suggested by Lalith.
>>> Is this an acceptable solution?
>>>
>>> Regards,
>>> Sascha
>>>
>>> On 23.01.2013 18:54, Eddie Kohler wrote:
>>>> Why not just set the CLICK_RAND_MAX to 0x7FFFFFFFU, which NS can handle
>>>> as well as normal code?
>>>>
>>>> Eddie
>>>>
>>>>
>>>> On 1/23/13 12:35 PM, Sascha Alexander Jopen wrote:
>>>>> Hi Eddie,
>>>>>
>>>>> I did not implement a fallback method, because i was not sure how to
>>>>> handle CLICK_RAND_MAX in case a fall back is necessary. In
>>>>> include/click/glue.hh CLICK_RAND_MAX is defined as the maximum value
>>>>> supported by the ns3 implementation. However, if we find the simulator
>>>>> not supporting random numbers at runtime, falling back to random() or
>>>>> rand() could lead to a RAND_MAX, which is different from the defined
>>>>> CLICK_RAND_MAX. This could lead to unexpected simulation behaviour. Any
>>>>> comments, how to handle this?
>>>>>
>>>>> Regarding the CLICK_RAND_MAX value itself, i can change the maximum
>>>>> value to 0xFFFFFFFFU.
>>>>>
>>>>> I used 0xFFFFFFFEU in the first place, because, although the ns3
>>>>> documentation says, that calling
>>>>>
>>>>>    uint32_t GetInteger(uint32_t min, uint32_t max)
>>>>>
>>>>> returns an integer in the range [min,max], this seems not to be true for
>>>>> max = 0xFFFFFFFFU. Because this calls internally another method, with
>>>>> GetValue(min, max + 1), this results in an overflow. So 0xFFFFFFFEU
>>>>> would be the largest possible integer. See around line 187 in file
>>>>> src/core/model/random-variable-stream.cc. Either i'm wrong, or this is
>>>>> something to report to the ns3 team.
>>>>>
>>>>> However, i certainly missed the alternative call with a cast of the max
>>>>> value 0xFFFFFFFFU to double and back to uint32_t after a call to the
>>>>> double based GetValue function. This would lead to a RAND_MAX of
>>>>> 0xFFFFFFFFU. I will fix this.
>>>>>
>>>>> Thanks for reviewing,
>>>>> Sascha
>>>>>
>>>>> On 23.01.2013 16:52, Eddie Kohler wrote:
>>>>>> Hey,
>>>>>>
>>>>>> Two comments.
>>>>>> - Breaking random numbers except for nses that export random numbers
>>>>>> considered lame. Why not fall back to the normal random number
>>>>>> generator?
>>>>>> - The RAND_MAX value seems odd. (-2??) Why this value?
>>>>>>
>>>>>> Eddie
>>>>>>
>>>>>> On Wed, Jan 23, 2013 at 3:52 AM, Lalith Suresh
>>>>>> <suresh.lalith at gmail.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Mon, Jan 21, 2013 at 12:16 PM, Sascha Alexander Jopen
>>>>>>> <jopen at informatik.uni-bonn.de> wrote:
>>>>>>>> Hey,
>>>>>>>>
>>>>>>>> please find attached a patchset for click and ns3 which adds
>>>>>>>> support for
>>>>>>>> drawing random numbers within click simulations from the underlying
>>>>>>>> ns3
>>>>>>>> random number generator. Each simulated click node has its own
>>>>>>>> uniformly
>>>>>>>> distributed random number stream (as opposed to my previously
>>>>>>>> submitted
>>>>>>>> patch). This way all nodes have independent random number streams.
>>>>>>>>
>>>>>>>> Setting the seed or run numbers is done within the simulation by
>>>>>>>> means of
>>>>>>>>
>>>>>>>> RngSeedManager::SetSeed ();
>>>>>>>> RngSeedManager::SetRun ();
>>>>>>>>
>>>>>>>> or with environment variables or command line parameters.
>>>>>>>> See http://www.nsnam.org/docs/manual/html/random-variables.html
>>>>>>>>
>>>>>>>> I still have no ns2 available. Currently, missing rng support from the
>>>>>>>> simulator side is detected and reported but no random numbers are
>>>>>>>> available to the simulation. Implementing a fallback method should be
>>>>>>>> possible, however. Maybe someone who uses ns2 could provide this?
>>>>>>>>
>>>>>>>> click-ns3-rng.diff is for the click side and ns3-nsclick-rng.diff for
>>>>>>>> the ns3 side.
>>>>>>>>
>>>>>>>
>>>>>>> I had a look through this patch. For clarity, my comment is to rename
>>>>>>> the simclick command to SIMCLICK_GET_RANDOM_INT and the
>>>>>>> Ipv4ClickRouting method's name to GetRandomVariable(). Otherwise, it
>>>>>>> looks good.
>>>>>>>
>>>>>>> I can push this to ns-3-dev when the click side gets committed.
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Sascha
>>>>>>>>
>>>>>>>> --
>>>>>>>> Dipl.-Inform. Sascha Jopen
>>>>>>>>
>>>>>>>> University of Bonn                     Tel.:   +49-228-73-54219
>>>>>>>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>>>>>>>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>>>>>>>> D-53113 Bonn, Germany
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> click mailing list
>>>>>>>> click at amsterdam.lcs.mit.edu
>>>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Lalith Suresh
>>>>>>> www.lalith.in
>>>>>>> _______________________________________________
>>>>>>> click mailing list
>>>>>>> click at amsterdam.lcs.mit.edu
>>>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Dipl.-Inform. Sascha Jopen
>>>
>>> University of Bonn                     Tel.:   +49-228-73-54219
>>> Institute of Computer Science 4        Fax:    +49-228-73-4571
>>> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
>>> D-53113 Bonn, Germany
>
>
> --
> Dipl.-Inform. Sascha Jopen
>
> University of Bonn                     Tel.:   +49-228-73-54219
> Institute of Computer Science 4        Fax:    +49-228-73-4571
> Friedrich-Ebert-Allee 144              E-mail: jopen at cs.uni-bonn.de
> D-53113 Bonn, Germany

More information about the click mailing list