[Click] NSClick - performance upgrade for NS-2

[Björn Lichtblau]

Hi,

Yes exactly. Some of the handling at least needs to be done on the 
simulator side, and i think it would be pretty easy to do all by simply 
stating that each time Click calls simclick_command(...SCHEDULE...) 
(which is at most once each time Click is run by the simulator) schedule 
an event and drop the previous request if existing. Idea is to never 
keep (track of) multiple schedulings anywhere, one, the next, is enough, 
and it's always passed when Click is returning to the simulator.

But i never thought of running multiple Click nodes in one simulator 
event, may  change things.. and beeing in doubt about my previous 
performance statement clever management on Click's side could make a 
difference..

Regards, Björn



On 20.01.2012 14:02, Michael Neufeld wrote:
> 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