Hello- It's been a great while since I did much with the ns interface to click, but here's my 0.02. I'd also lean towards doing the work on the Click end of things - if I'd done it that way in the first place (and integrated the change) there'd be no need to duplicate the work in both the ns-2 and ns-3 specific code.
>> But I think handling by the sim is much easier, the interface is fine as >> is (just needs doc). The sim interface could probably do with a bit of sprucing up (in addition to documentation) at this point - quite likely some of the assumptions I made when designing/coding it aren't true anymore. I'm not swimming in free time for Click work right now, but can at least get started on documenting it as it stands and think a bit about what could be improved. -Mike 2012/1/19 Eddie Kohler <[email protected]>: > Hi Björn, > > That's *exactly* what I was thinking! > > But I think we could do that without an NS patch, by changing Click > (lib/routerthread.cc), so that it doesn't call > "simclick_sim_send(...SCHEDULE...)" unless it knows there is no timer > scheduled. > > I slightly prefer to change the Click side, but only slightly. The > division of functionality between Click and the NS driver is pretty ad hoc. > > E > > > On 1/19/12 2:45 PM, Björn Lichtblau wrote: >> Hi, >> >> I saw the same behaviour recently with ns3. I think you can't prevent >> it? For example: >> >> 0s: An element schedules itself to run in 3s, which click tells the sim. >> 1s: sim has a packet for click which results in another element >> scheduling in 1s. >> >> Now click must tell the sim to get scheduled at 2s, although 3s is still >> pending. And when click is called at 2s it schedules the second time for >> 3s (events may pile up if neither click nor sim cares). >> >> But I think handling by the sim is much easier, the interface is fine as >> is (just needs doc). >> The sim needs to keep the next schedule only, later ones can be dropped >> because click always schedules the next event (if there is one) at the >> end of each routerthread/driver invocation. If an earlier schedule comes >> in you need to replace that, no map for bookkeeping needed on neither side. >> >> Attached is a patch which i intended to submit to ns3 soon and worked >> well for me, am i missing something? >> >> Best regards, Björn >> >> >> On 19.01.2012 18:10, Eddie Kohler wrote: >>> Hi Wim, >>> >>> I'll take a version of this if no one else mentions a problem. But >>> perhaps it would be good to separate out the easy from the hard >>> problems. It would be easy to, entirely on the Click side, prevent a >>> single node from scheduling itself multiple times in the future. That >>> would apply to ns2 and ns3 I think(i am really not an expert on click's >>> ns driver). Should we just do that first& see how much it helps? >>> >>> E >>> >>> >>> On 1/18/12 10:25 AM, Wim Vandenberghe wrote: >>>> Hi everyone, >>>> >>>> because i am having problems with Nsclick simulations that take forever >>>> to complete, i have been looking at possible causes. I've identified a >>>> flaw in the scheduling. Everytime the driver() function of >>>> routerthread.cc is executed (which is caused by timer expiration or >>>> packet reception), it schedules itself again in NS-2 if it has a timer >>>> that is scheduled to go off in the future. As a result, many duplicate >>>> schedules are introduced for the same node for exactly the same point in >>>> simulation time. This introduces great overhead when this point in >>>> simulation time is reached and all these duplicate events have to be >>>> executed. >>>> >>>> I've found a very old post on the mailing list by Michael Neufeld >>>> (http://pdos.csail.mit.edu/pipermail/click/2004-May/002706.html) which >>>> presented a hack to overcome this problem. Basically he keeps a global >>>> map of points in time for which a ClickEvent is scheduled. If a node >>>> schedules a new event, it will be added to the unique already existing >>>> event for that given moment in time. During this addition, a check is >>>> performed to make sure that you schedule a node only once for a single >>>> point in time. >>>> >>>> This code however was never introduced into mainstream click. I have >>>> implemented a new version which should be compatible with recent Click >>>> releases. The files can be found in attachment. They have to be put in >>>> the classifier directory of the NS-2 sources. >>>> >>>> Perhaps it would be interesting if some people using NSClick in NS-2 >>>> could try these files, and see if they also observe an improvement in >>>> performance, and if it does not introduce any bias in the simulation >>>> results? Also, i have tested it with Click 1.7 (upgrading is still on my >>>> to-do list) and NS2.34, experience with current git sources would also >>>> be interesting. >>>> >>>> Regards, >>>> >>>> Wim >>>> >>>> >>>> PS: I also noticed that using a QuickNoteQueue instead of a standard >>>> Queue improves performance since the run_task of the tosimdevice will >>>> halt quicker when there are >>>> no more packets left in the queue >>>> >>>> >>>> >>>> _______________________________________________ >>>> click mailing list >>>> [email protected] >>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >>> _______________________________________________ >>> click mailing list >>> [email protected] >>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> >> >> >> _______________________________________________ >> click mailing list >> [email protected] >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
