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

[mathieu lacage]

On Fri, 2006-10-06 at 20:29 +0200, Tommaso Pecorella wrote:

> It's a matter of design atm. Working with students I found that  
> forcing them is sometimes good.
> So I designed NePSing to convert everything is supposed to be a  
> "time" (i.e., used in a Event) to a Time class.
> Users are still free to use what they want, but they'll have to face  
> a conversion sooner or later, so better to have it done early and  
> avoid mistakes.
> Again, it's just a matter of design.

Yes. I don't know. I see the advantage and I considered it before: what
I am most worried about is integer overflows and stuff like this is
which is often rather cumbersome to avoid and detect correctly. Wrapping
integer operations in a class which can do this in a smart way would be
nice but I am not sure this functionality should be integrated in the
scheduler API. Maybe as a separate class.

> > I don't have any negative a-priori with your suggestion but I must
> > confess I have never witnessed the type of problem you describe.  
> > Or, to
> > be more specific, I have never witnessed problemes like this which  
> > could
> > not be readily caught and fixed by an assert in the scheduler  
> > method to
> > check for time not being in the past.
> 
> Assertions is another way, I avoided it because they could slow down  
> the code. And yes, the drawback of my approach is that. If you need 

only for debug builds. So, performance is probably not an issue I think.

> to schedule something at an absolute time, you'll have to do a  
> subtraction (TargetTime - CurrentTime). As a side note, you're lucky  
> or I'm unlucky, my students are so dumb that they think that Time is  
> just another dimesion and that they can jump ahead and behind :)

I understand your point. I am lucky enough not to have to deal with
students myself.

> Btw, I think the AbsS() function are very useful, I just found that  
> using relS() in event scheduling is more foolproof.

I agree that they are more foolproof. I never use the Abs functions
myself so, I would not mind losing them but I fear being flamed for
suggesting this.

> >> 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.
> >
> > I don't really understand what you are talking about. Could you
> > elaborate ? With a small example maybe ?
> 
> Of course.
> 
> Let's say we have this code:
> functionA() {
> 
> [...]
> 
> Simulator::schedule (Time::now(), make_event (some_method, arguments));
> }
> 
> (note, event is last instruction of the function, either some more  
> things should be said)
> 
> This is [almost] equivalent to call some_method(arguments), and this  
> saves the overhead due to the scheduler insertion, reordering,  
> deletion of the event. However it's definitely a bad approach, as it  
> make the simulation harder to understand, debug and maintain.
> 
> What I did is to have two Simulator::schedule() functions, one of  
> them is without the time (remember that I work with relative times in  
> event scheduling).
> 
> The "nomal" function add the event to the scheduling queue with the  
> usual overheads.
> The "cut down" one use a simple FIFO list.
> 
> Whenever a new event must be scheduled, the sceduler simply check if  
> the FIFO list is not empty. If it's not, executes one of the events  
> there. Else it use the normal behavior. Time for adding and removing  
> from the FIFO queue is very small (constant), so it's almost a no- 
> overhead call and the "clever but ugly" trick of using a direct  
> function call is no more necessary.
> 
> The drawback (ofc there's a drawback) is that the event removal  
> function Simulator::cancel (eventId) and Simulator::remove (eventId)  
> are slightly more complex.
> 
> Btw, right now I don't have the time to carefully look at ns-3 code  
> to check if there is such a capability, but I found very useful one  
> feature in simulating mobile environments. As is to be able to remove  
> from the scheduler ALL the events directed to a particular object.
> 
> Let's say that object A is a mobile wireless node and his battery run  
> out (or it's deactivated, or whatever), it's very handy to have a  
> function able to remove from the scheduler all the events for that  
> object, so you can simply write in the destructor something like
> Simulator::destroyAllMyEvents(this);
> It saves the headache of having to remember all the scheduled and not  
> executed events.

There are at least two different issues to consider:
1) do you want to be able to "cancel" scheduled events not yet
executed ?
2) do you want to be able to schedule events in a special way for the
"now" time which would be defined as immediately after the currently
executing event ?

The answer to 1) is a definite yes. It is possible to do this in ns-3
and there are at least two different wants to do this: Simulator::remove
and Simulator::cancel, two functions with different complexity behavior.

The answer to 2) is less easy. When I implemented this functionality
(schedule_now) in yans, I ended up implementing slightly different
semantics: the "now" events were scheduled only before changing the
value of the current time which can result in a different scheduling
order (from what you suggested) if multiple events have already been
scheduled for the same time. In ns-3, I implemented the same semantics:
"now" events are scheduled only before changing the value of the current
time.

Do you think that the slight semantic difference is an issue ? Or, let
me rephrase: based on your existing codebase, do you envision problems
if you had to move your schedule_now function to the semantics
implemented in ns-3 ? I am honestly curious and interested in an
answer :)

Mathieu
--