[Ns-developers] Proposed Simulator Changes

[craigdo@ee.washington.edu]

> > 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 ?

It can be made to run, but what do you expect it to do?  It certainly isn't
going to do anything based on a real-time clock.  Would you expect it to
just set m_current, execute the event at the head of the queue and return?
ProcessOneEvent tries to synchronize to a real-time clock, and if you're
stopped there's no real time clock to synchronize to and the relationship
between simulation time and real-time is not valid.  You could resync the
time bases, but that seems like a hard way to execute an event immediately.

Basically, if you call Stop, the realtime aspects of the simulator go away
until you call Run.  RunOneEvent could check for the simulator stopped state
and run one event like the default simulator implementation runs one event
if it is stopped.  I think that makes sense. 

> 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.

Sure.  I can make sure that the simulator will start if m_currentTs != 0.

> > 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.

Removing the multithread safety from EventImpl and moving ScheduleRealNow
back into Simulator would mean that we'd have some methods of the simulator
that were multithread safe and some that were not.  This really doesn't
sound like a very good idea to me.

> 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. 

Yes, I wanted to separate out the "dangerous" methods to discourage people
from trying them out and finding out the very, very, very hard way that
using them may cause hard-to-find problems.

> 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 could be convinced that moving these methods back into Simulator would be
okay if we plastered enough warning signs all over them.  If you actually
want to remove the multihread-safety from some simulator methods, and move
some multithread-safe methods in, I would say that is a recipe for disaster.

> > 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.