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 <[email protected]> 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 >>>> <[email protected]> wrote: >>>>> Hi, >>>>> >>>>> On Mon, Jan 21, 2013 at 12:16 PM, Sascha Alexander Jopen >>>>> <[email protected]> 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: [email protected] >>>>>> D-53113 Bonn, Germany >>>>>> >>>>>> _______________________________________________ >>>>>> click mailing list >>>>>> [email protected] >>>>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Lalith Suresh >>>>> www.lalith.in >>>>> _______________________________________________ >>>>> click mailing list >>>>> [email protected] >>>>> 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: [email protected] > D-53113 Bonn, Germany _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
