[Click] NSClick - performance upgrade for NS-2

[Björn Lichtblau]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: one-schedule-max.patch
Type: text/x-patch
Size: 1973 bytes
Desc: not available
Url : http://amsterdam.lcs.mit.edu/pipermail/click/attachments/20120119/e2823cda/attachment.bin