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 <[email protected]> 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 >> <[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 > > > -- > 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
