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@amsterdam.lcs.mit.edu https://amsterdam.lcs.mit.edu/mailman/listinfo/click
