[Click] nsclick rng support for ns3

Fri Jan 25 09:34:35 EST 2013

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