[Ns-developers] Proposed Simulator Changes

[mathieu lacage]

hi craig,


> Then you will get a system that attempts to pace the simulation time (as
> defined completely be the non-real-time simulation implementation) to an
> underlying real-time clock.  This should be sufficient for most people.
> Your familiar methods:
> 
>   Simulator::Schedule ()
>   Simulator::ScheduleNow ()
>   Simulator::Now ()

1) I see that ::RunOneEvent is not implemented in RealtimeSimulatorImpl.
Is it not possible to implement it by a single call to ProcessOneEvent ?

2) In ::Run, I see that there is a call NS_ASSERT_MSG to ensure
that ::Run is called only once at the start of a simulation. It seems to
me that if you remove that assert, you will allow sequential calls
to ::Run, ::Stop, and, ::Run (which is a legal sequence of calls in the
non-realtime implementation). If so, I see no reason to forbid this so,
please, remove that assert.

> all behave exactly as they do now, basing all of their timing on the current
> simulation time which is set once at the start of event execution and does
> not change until the start of the next event.  The simulator will basically
> become a multi-threaded simulator that just paces events (introduces
> real-time delays between events) with a system real-time clock.
> 
> There is a need to provide a way for external events to drive the simulation
> time forward.  Since using a method that updates the simulation time based
> on an underlying real-time clock is apparently like playing with fire, I
> have taken these new methods and moved them behind a "firewall."  I have
> created a new class called RealtimeSimulatorExtension (a friend of class
> Simulator) that contains only the "dangerous" methods:
> 
>   RealtimeSimulatorExtension::ScheduleReal ()
>   RealtimeSimulatorExtension::ScheduleRealNow ()
>   RealtimeSimulatorExtension::RealNow ()


I would also appreciate that you remove the return type of
ScheduleReal/ScheduleRealNow:

void ScheduleReal (Time delay, ...);

because we don't really need the ability to cancel an event once it is
scheduled by these methods (for now) and because doing so will make it
possible to remove the EventImpl threaded reference counting. If I turn
out to be wrong, that is, we need to cancel some of these events, we can
easily add the return type later in a compatible way.

I assume that you introduced RealtimeSimulatorExtension to outline more
clearly to users the semantics of these methods and separate them from
the other simulator methods: I think that this is a bit over-the-top and
that careful method naming within the context of the Simulator class is
enough. If you feel that the 'Real' keyword is not
sufficiently-explicit, 'Realtime' or 'WallClock' seem fine:

class Simulator 
{
static void ScheduleXXX (Time delay, ...);
static void ScheduleXXXNow (...);
static Time XXXNow (void);
};

where XXX is one of Real, Realtime, RealTime, WallClock.

> I've also made the Schedule methods explicitly use relative semantics all
> the way down to the implementation code to allow atomic operation in
> multithreaded environments.  Basically this just means moving the Now() +
> time code from the Simulator class to the implementation classes.

That sounds great.

Mathieu