[Ns-developers] Comment on ns Simulator::Schedule (re-post to ns-developers)

[Tom Henderson]

Gustavo Carneiro wrote:
> On 11/21/06, *Mathieu Lacage* <Mathieu.Lacage at sophia.inria.fr 
> <mailto:Mathieu.Lacage at sophia.inria.fr>> wrote:
> 
>     hi tom,
> 
>     On Mon, 2006-11-20 at 21:14 -0800, Tom Henderson wrote:
> 
>      > > I can't understand why the time passed to schedule is absolute
>     time as
>      > > opposed to relative time.  The expected use case is that the time
>      > > calculated
>      > > is relative to current time (transmission time, speed of light
>     delay,
>      > > time out values
>      > > in TCP, etc).  The only absolute time use case is if we want an
>      > > application to
>      > > start at some particular time, or the simulation to finish at some
>      > > time.  I think
>      > > we need to optimize for the expected case, and say:
>      > >
>      > > Schedule(rxTime, .....) // Schedule packet rx event
>      > >
>      > > and
>      > >
>      > > Schedule(myAppStartTime - Now())
>      > >
>      > > when the abs time is needed.
>      > >
>      >
>      > George and Mathieu,
>      > I am fine with switching this to relative time, since it is
>     relative in
>      > ns-2 and might make for a more readable port of code, and since
>     relative
>      > event timing is probably more frequent than absolute.
>      >
>      > This was suggested also by tommaso originally in this thread;
>     forgive me
>      > for losing track if there was a reason cited to move to absolute.
> 
>     The reason was that the following is much easier to read since it does
>     exactly what is written:
> 
>     Schedule (Now () + Seconds (1.0), &foo, ...);
> 
>     The alternatives are:
>     1) make Schedule relative
>     2) add ScheduleRel and ScheduleAbs
> 
>     2) is arguably also pretty readable since it makes it very clear what
>     the code is doing. 1) generates code which is the least obvious to
>     read.
> 
> 
> Suppose a user makes a mistake and assumes the time is relative even 
> though Schedule takes absolute time, and so issues:
> 
>     Schedule (Seconds (1.0), &foo, ...);
> 
> Hopefully this will trigger an assertion error like
>     assert(time > Now());
> 
> Unless Now() < Seconds(1.0)... making simulations start at an 
> arbitrarily large time value would take care of catching most errors.
> 
> Now the reverse... suppose an user thinks the time is absolute but 
> Schedule takes a relative time:
> 
>     Schedule (Now() + Seconds (1.0), &foo, ...);
> 
> This will effectively delay for a longer time than expected; how much 
> longer depends on how long the simulator has been running.  Impossible 
> to catch the error automatically, and difficult to catch it even by the 
> programmer.
> 
>   I think this argument advocates the current absolute time API.  But 
> there are other arguments for and against, of course..
>  
Yes, I understand this argument, but it seems to me that it is a minor 
burden for the user to understand what the semantics of Schedule() are; 
presumably a user would have to read either the scheduler API where it 
should be clearly documented, or read existing code where it should 
usually be clear from the context.  I am not aware of problems in ns-2 
of this sort, where Schedule(delay) is relative and seems to be the 
common use case.

I don't have a strong opinion but I was asked to give one to resolve 
this so I opted towards relative scheduling, mainly just for consistency 
with ns-2, and Mathieu agreed to make this change.

I also suggest that we document that if a user wants to schedule 
something at absolute time t, that he or she should call Schedule(t - 
Now()).

Tom