Re: NSClick - performance upgrade for NS-2

Hello,

2012/1/20 Björn Lichtblau <[email protected]>:
> 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..
>

Your patch would suffice for multiple Click nodes as well, because the
scheduling is done on a per node/Ipv4ClickRouting-object basis, and
the scope of the event-id variable that you've added is specific to
each Click router instance in the simulation.

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



-- 
Lalith Suresh
www.lalith.in