[Click] NSClick - performance upgrade for NS-2

[Björn Lichtblau]

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