[Click] NSClick - performance upgrade for NS-2

[Michael Neufeld]

Hello-
I don't recall exactly why I did all the bookkeeping in the original
hack, though I have some dim recollection that it might have had
something to do with only running the subset of Click nodes that
actually needed to be run at any given timer firing. Quite possibly
the Click router/scheduling system worked a bit differently back then,
so my original reasons may not make sense in Click today.

I agree with Björn about the extra bookkeeping being ugly. It struck
me as being pretty kludgey when I wrote it, which is why I wasn't
inclined to just toss it into the nsclick patch without putting some
thought into doing it more cleanly. My initial take on this from an
architectural standpoint is that if we could do something easy to
reduce the number of events coming out of Click (even though it may
not get rid of all of them) we should do it, and then whittle down the
rest of the events as required on the simulator side of things.
However, I get the impression that Björn's scheme relies on redundant
rescheduling of events from Click in order to greatly simplify the
extra bookkeeping required on the simulation end of things. If that's
the case, then leaving the redundant event scheduling in Click could
be an overall win. Is that the idea, Björn?

-Mike

2012/1/20 Björn Lichtblau <lichtbla at informatik.hu-berlin.de>:
> Hello Wim,
>
> i'd like to also highlight what you've pointed out in your PS:
>
> On 01/18/2012 04:25 PM, Wim Vandenberghe wrote:
>> 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
>
> This is also something i observed and what was buried in my notes. It
> tracks down to FullNoteQueue::pull_failure() in
> elements/standard/fullnotequeue.hh. FullNoteQueue tries to "busy wait"
> SLEEPINESS_TRIGGER (9) times before going to sleep, which always results
> in 10 ping-pongs between sim and click although the queue is empty and
> won't get filled in the sim environment. I'm curious what this code is
> for, some kind of concurrent lock-waiting optimization?! Is this
> behaviour common in more places, and an easy way to fix that on click's
> side for the sim?
>
> Anyway, this in combination with not caring on either side  (click or
> sim) about events piling up in the sim queue can lead to very quick
> growth of the event list, because every pull on such elements results in
> 10 unnecessary new schedules given from click to sim and may be the
> difference between 4 minutes and 38 hours runs. Thanks for mentioning
> the QuickNoteQueue.
>
> On 01/20/2012 11:56 AM, Wim Vandenberghe wrote:
>>
>> I agree that it would be ideal if this functionality could be easily
>> kept within Click, since this would result in a simulator-independent
>> solution. However, the thing I liked about the original NS-2 hack of
>> Michael is it's simplicity. You are sure that you tackle the core
>> problem: for a given node and a given point in time, it becomes
>> impossible to have multiple redundant events scheduled. Which was a
>> real big issue in my specific simulation. And because of the clear and
>> limited changes in functionality, chances of introducing unwanted
>> side-effects are quite small.
>>
> I do not agree. The patch introduces a map for bookkeeping about all
> events that were passed to the sim (duplication of functionality of what
> is already in the sim and duplication of information already passed to
> the sim).
> My patch essentially is a one liner (what i attached was extra-safe, you
> can boil it down to just keeping one event from click without even
> checking how a new event is relative to the previous one, because if
> there is another timer event click will currently always schedule the
> next) and is also constant in time (again, only quite sure for ns3) vs a
> bookkeeping map (duplication of code, duplication of information, higher
> complexity) ?!
>
> Why should click do complex bookkeeping of events it passed to the sim
> while the strategy on the sim is much easier, and it is the sims event
> queue anyway .. I believe i'm sure about the core problem with one
> simple thought: Just keep one event max from click, multiple redundant
> events become simply impossible because the sim enforces that.
> The question for correctness then maybe is "can we loose something by
> doing that", and i'm quite sure that not, because  click will always
> schedule the next on each invocation (with the current impl).
>
> But whatever, if there is an easy way to do this in click without
> bookkeeping i'm happy to just put something like
> NS_ASSERT(m_lastClickEvent.IsExpired()) into ns3!
>
> Regards, Björn
>
>
>
>
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click