Application::Start/Stop, time parameter inconsistent with Simulator::Schedule

[Gustavo Carneiro]

I am looking at some student's code and I found this:


              ooffi->Start (Simulator::Now ());
              ooffi->Stop(Simulator::Now() +Seconds(120.0));

              Simulator::Schedule (Simulator::Now() +Seconds(120.0),
&GtpUmts::EraseFirstLoadFactor,&umts);

I am guessing that, most likely, the Simulator::Schedule call is wrong and
should be  Simulator::Schedule (Seconds(120.0), ...) instead.

Alas, it's easy to make this mistake since Application::Start/Stop() accept
absolute time, while Simulator::Schedule accepts relative time...

--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[Joseph Kopena]

On Tue, May 27, 2008 at 9:44 AM, Gustavo Carneiro <gjcarneiro@...> wrote:
> Alas, it's easy to make this mistake since Application::Start/Stop() accept
> absolute time, while Simulator::Schedule accepts relative time...

I also agree that this is confusing, though most likely doesn't matter
in almost all cases (i.e., they're scheduled at time 0, so there's no
difference).

--
- joe kopena
right here and now

[Mathieu Lacage]

On Tue, 2008-05-27 at 13:42 -0400, Joseph Kopena wrote:
> On Tue, May 27, 2008 at 9:44 AM, Gustavo Carneiro <gjcarneiro@...> wrote:
> > Alas, it's easy to make this mistake since Application::Start/Stop() accept
> > absolute time, while Simulator::Schedule accepts relative time...
>
> I also agree that this is confusing, though most likely doesn't matter
> in almost all cases (i.e., they're scheduled at time 0, so there's no
> difference).

At some point in time, Schedule was using absolute time but that is not
the case anymore because the extra Simulator::Now () was felt to be too
verbose. It would be nice to align Application with this to avoid this
kind of mistake.

Mathieu

[craigdo]

> > > Alas, it's easy to make this mistake since
> Application::Start/Stop() accept
> > > absolute time, while Simulator::Schedule accepts relative time...
> >
> > I also agree that this is confusing, though most likely
> doesn't matter
> > in almost all cases (i.e., they're scheduled at time 0, so
> there's no
> > difference).
>
> At some point in time, Schedule was using absolute time but
> that is not
> the case anymore because the extra Simulator::Now () was felt
> to be too
> verbose. It would be nice to align Application with this to avoid this
> kind of mistake.

Yes, this kind of thing drives me to distraction.  It's consistent
everywhere except for the most commonly used, highest visibility case ;-)
...

Let's change Application.

-- Craig

[Tom Henderson-2]

craigdo@... wrote:

>>>> Alas, it's easy to make this mistake since
>> Application::Start/Stop() accept
>>>> absolute time, while Simulator::Schedule accepts relative time...
>>> I also agree that this is confusing, though most likely
>> doesn't matter
>>> in almost all cases (i.e., they're scheduled at time 0, so
>> there's no
>>> difference).
>> At some point in time, Schedule was using absolute time but
>> that is not
>> the case anymore because the extra Simulator::Now () was felt
>> to be too
>> verbose. It would be nice to align Application with this to avoid this
>> kind of mistake.
>
> Yes, this kind of thing drives me to distraction.  It's consistent
> everywhere except for the most commonly used, highest visibility case ;-)
> ...
>
> Let's change Application.
>

We already have an example for naming an absolute time event:
Simulator::StopAt();

Would Application::StartAt() and Application::StopAt() make it more clear?

[craigdo]

> Application::Start/Stop() accept absolute time, while
> Simulator::Schedule accepts relative time...

[ ... ]

>
> We already have an example for naming an absolute time event:
> Simulator::StopAt();
>
> Would Application::StartAt() and Application::StopAt() make
> it more clear?

Yes, I think it's is more clear.  It's not the most clear thing to do,
though.

In English, we talk about doing something *at* a wall clock time as an
absolute time (e.g., returning from lunch *at* 1 o'clock or *at* 1 PM or
*at* 13h00); and we talk about doing something *in* some number of seconds,
minutes, etc., as a relative time (e.g., returning from lunch *in* 1 hour or
*in* 30 minutes).  The preposition and the units agree.

In the case of StartAt() we obviously want to schedule a start *at* five
seconds.  I think it is natural to assume that this means, "start at five
seconds on the simulation wall clock."  However, I can imagine someone who
has been doing relative time schedule calls all day thinking, "start at five
seconds in the future."

The pedant in me says that the answer is Simulator::StopAt (Seconds (5.)),
Simulator::ScheduleIn (Seconds (1.)), Application::StartAt (Seconds (0.)),
Application::StartIn (Seconds (10.)).

The realist in me says that is silly and overly pedantic.  I think to
myself, if everything to do with scheduling events is in relative time, it'd
be hard to confuse the one possible option with itself (although I could
probably manage :-).

So I think the simple, straightforward, easy to remember and use thing is to
go with calls like:

Application::Start (Seconds (5.)) means start *in* five seconds (relative).
If you do this before the simulation starts it means start in five seconds
once the simulation starts.  Simulator::Stop (Seconds (5.)) means stop the
simulation in five seconds (relative).  If you do this before the simulation
starts it does what StopAt does now.  Etc., etc.

It's hard to get too excited about this, though.

-- Craig

[Mathieu Lacage]

On Tue, 2008-05-27 at 23:59 -0700, craigdo@... wrote:

> So I think the simple, straightforward, easy to remember and use thing
> is to
> go with calls like:
>
> Application::Start (Seconds (5.)) means start *in* five seconds
> (relative).
> If you do this before the simulation starts it means start in five
> seconds
> once the simulation starts.  Simulator::Stop (Seconds (5.)) means stop
> the
> simulation in five seconds (relative).  If you do this before the
> simulation
> starts it does what StopAt does now.  Etc., etc.

I suspect that a corollary of this proposal is to remove every function
using the At postfix (including Simulator::StopAt) and replace them with
a no-postfix function, right ? If so, that would be fine with me.

> It's hard to get too excited about this, though.

Indeed. But if someone wants to cook a patch along the lines of what you
outlined, I would be fine with it.

Mathieu

[Gustavo Carneiro]

On 28/05/2008, Mathieu Lacage <mathieu.lacage@...> wrote:

>
>
> On Tue, 2008-05-27 at 23:59 -0700, craigdo@... wrote:
>
> > So I think the simple, straightforward, easy to remember and use thing
> > is to
> > go with calls like:
> >
> > Application::Start (Seconds (5.)) means start *in* five seconds
> > (relative).
> > If you do this before the simulation starts it means start in five
> > seconds
> > once the simulation starts.  Simulator::Stop (Seconds (5.)) means stop
> > the
> > simulation in five seconds (relative).  If you do this before the
> > simulation
> > starts it does what StopAt does now.  Etc., etc.
>
>
> I suspect that a corollary of this proposal is to remove every function
> using the At postfix (including Simulator::StopAt) and replace them with
> a no-postfix function, right ? If so, that would be fine with me.
>
>
> > It's hard to get too excited about this, though.
>
>
> Indeed. But if someone wants to cook a patch along the lines of what you
> outlined, I would be fine with it.

I volunteer to prepare the patch.

For now added a bug report:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=191

--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[Gustavo Carneiro]

On 28/05/2008, Gustavo Carneiro <gjcarneiro@...> wrote:

>
>
>
> On 28/05/2008, Mathieu Lacage <mathieu.lacage@...> wrote:
>>
>>
>> On Tue, 2008-05-27 at 23:59 -0700, craigdo@... wrote:
>>
>> > So I think the simple, straightforward, easy to remember and use thing
>> > is to
>> > go with calls like:
>> >
>> > Application::Start (Seconds (5.)) means start *in* five seconds
>> > (relative).
>> > If you do this before the simulation starts it means start in five
>> > seconds
>> > once the simulation starts.  Simulator::Stop (Seconds (5.)) means stop
>> > the
>> > simulation in five seconds (relative).  If you do this before the
>> > simulation
>> > starts it does what StopAt does now.  Etc., etc.
>>
>>
>> I suspect that a corollary of this proposal is to remove every function
>> using the At postfix (including Simulator::StopAt) and replace them with
>> a no-postfix function, right ? If so, that would be fine with me.
>>
>>
>> > It's hard to get too excited about this, though.
>>
>>
>> Indeed. But if someone wants to cook a patch along the lines of what you
>> outlined, I would be fine with it.
>
>
> I volunteer to prepare the patch.
>
> For now added a bug report:
> http://www.nsnam.org/bugzilla/show_bug.cgi?id=191
>

Committed the change.

Since Application::Start/Stop have changed in a subtle way, that is not
detected by either compile time error or run time assertion, I would advise
a warning such as this to be put in the release notes of next release:

Warning: among API changes in this release, Application::Start and
Application::Stop now interprets the time argument differently.  Now the
time is assumed to be a relative to the current simulation time, in the same
way that Simulator::Schedule behaves.  Any code that calls these APIs in the
middle of the simulation will need to be adapted.  Calls done before the
start of the simulation do not need to be changed.

Although it is easily detected by a compilation error, we might as well make
the migration easier with an addition notice like:

The API of Simulator::StopAt (time) has also changed.  Now it is called
Simulator::Stop (time), and takes a relative time, instead of absolute.

--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[George Riley]

>
>>>>
>
> Yes, this kind of thing drives me to distraction.  It's consistent
> everywhere except for the most commonly used, highest visibility  
> case ;-)
> ...
>
> Let's change Application.
Since the most common (only?) use of App::Start/Stop presently is at  
simtime zero,
I think we can and should make this change.
George
>
>
> -- Craig
>
>