[Click] NSClick - performance upgrade for NS-2

[Eddie Kohler]

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
>>> click at amsterdam.lcs.mit.edu
>>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>
>
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click