[Click] NSClick - performance upgrade for NS-2

[Michael Neufeld]

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