[Ns-developers] Ns-3 time objects and events

[Tommaso Pecorella]

Hi,

first my deeper compliments on the project. To be honest I've always  
looked (and used) ns-2 with some diffidence due to the amount of bugs  
in the contributed code that made adding stuff more a slalom around  
ugly programming than a joy. Ns-3 can be a great opportinity.

Now, since I've done a bit of work in simulators and simulation  
frameworks, I'd like to submit some ideas about some points.

Time: horaay to the idea of using integers. It's mandatory for ultra- 
long simulations, and OSs already use integer math for that.
Events: I like the yank approach, but there's an hidden source of  
bugs (fortunately there's also a nice way to solve 'em).

For the time class, I'd like to submit some ideas, included in the  
attachs. It's the Time class i wrote for my own simulation framework  
(NePSing, http://nepsing.sourceforge.net) and basically it's very  
similar to the one in Ns-3. The only thing added is a slot/frame/ 
superframe structure, very useful for managing the slot-based  
protocols like ATM.
I'll not comment the code because it's already commented (Doxygen),  
but I'll be happy to discuss it.
Btw, since time-related basic functions are always needed, there's a  
lot of overloading for the basic operations + - * / %, and the  
relative stuff for the slot/frame/superframe structures. All the code  
is [should be] optimized to avoid overflow errors, and the minus  
function is bound to yell if a negative time is found.

About events, I found that not-so-good users always forget to check  
if the result of an operation is in the future. As a result, I had to  
debug a lot of simulations where the time was jumping from future to  
past. Since we're not in a film, this is quite annoying.
Solution... the Simulator::schedule (time, make_event (&method,  
arguments)); should not contain the absolute time of the event, but  
the relative time from the current time. The scheduler can use the  
absolute time by simply adding the current time and storing it.
This have two positive effects: since time cannot be negative, all  
the events will be scheduled in the future, and never in the past.  
Moreover this allow to have a Simulator::schedule (make_event  
(&method, arguments)); (i.e., without any time). That event is meant  
to occur immediately (relative time null, as is right now), and the  
scheduler can use a separate queue and avoid the reordering overhead.

This is expecially important since for events that are meant to be  
"immediate" usually the [bad] programmer just call the final function  
in order to avoid the scheduling overhead, and this is definitely  
bad. If you need an example of events with time differences and the  
corresponding scheduling functins, feel free to borrow NePSing code.  
Strange enough NePSing already have event cancelling, dequeueing,  
etc. Maybe it's not an example of perfect programming style, but the  
code have grown trough years without any real attention to perfection.

Best regards,

Tommaso




-------------- next part --------------

------------------------------------------------------------------------ 
--------
The nice thing about standards is that there are so many to choose  
from. And if you really don't like all the standards you just have to  
wait another year until the one arises you are looking for.
-- A. Tanenbaum, "Introduction to Computer Networks"