1.1 --- a/src/simulator/realtime-simulator-impl.cc	Thu Aug 28 15:06:49 2008 -0700
     1.2 +++ b/src/simulator/realtime-simulator-impl.cc	Thu Aug 28 15:11:55 2008 -0700
     1.3 @@ -47,13 +47,6 @@
     1.4    static TypeId tid = TypeId ("ns3::RealtimeSimulatorImpl")
     1.5      .SetParent<Object> ()
     1.6      .AddConstructor<RealtimeSimulatorImpl> ()
     1.7 -#ifdef PERMIT_WALLCLOCK_SIMULATION_TIME
     1.8 -    .AddAttribute ("ReportSimulatedTime", 
     1.9 -                   "Report simulated time in Simulator::Now if true, otherwise wall-clock time (will be different).",
    1.10 -                   BooleanValue (true),
    1.11 -                   MakeBooleanAccessor (&RealtimeSimulatorImpl::m_reportSimulatedTime),
    1.12 -                   MakeBooleanChecker ())
    1.13 -#endif
    1.14      .AddAttribute ("SynchronizationMode", 
    1.15                     "What to do if the simulation cannot keep up with real time.",
    1.16                     EnumValue (SYNC_BEST_EFFORT),
    1.17 @@ -643,34 +636,7 @@
    1.18  Time
    1.19  RealtimeSimulatorImpl::Now (void) const
    1.20  {
    1.21 -#ifdef PERMIT_WALLCLOCK_SIMULATION_TIME
    1.22 -  //
    1.23 -  // The behavior of Now depends on the setting of the "ReportSimulatedTime"
    1.24 -  // attribute.  If this is set to true, then Now will pretend that the realtime
    1.25 -  // synchronization is perfect and that event execution consumes no time.  This
    1.26 -  // allows models written with this kind of assumption to work as they did in 
    1.27 -  // non-real-time cases.  However, if the attribute is set to false, we're going
    1.28 -  // to give the caller the bad news right in the face.  If it sets an event to 
    1.29 -  // be executed at 10.0000000 seconds, and calls Simulator::Now it will get the 
    1.30 -  // realtime clock value which almost certainly will *not* be ten seconds.  We'll
    1.31 -  // get as close as possible, but we won't be perfect and we won't pretend to be.
    1.32 -  // Also, if the client calls Simulator::Now multiple times in an event, she will
    1.33 -  // get different times as the underlying realtime clock will have moved.  However
    1.34 -  // if the simulation is not actually running, we'll use the last event timestamp
    1.35 -  // as the time, which will be a precise simulation time (0 sec before the sim
    1.36 -  // starts, or the end time after the simulation ends).
    1.37 -  //
    1.38 -  if ((m_reportSimulatedTime == false) && Running ())
    1.39 -    {
    1.40 -      return TimeStep (m_synchronizer->GetCurrentRealtime ());
    1.41 -    }
    1.42 -  else
    1.43 -    {
    1.44 -      return TimeStep (m_currentTs);
    1.45 -    }
    1.46 -#else // Do not PERMIT_WALLCLOCK_SIMULATION_TIME (the normal case)
    1.47    return TimeStep (m_currentTs);
    1.48 -#endif // Do not PERMIT_WALLCLOCK_SIMULATION_TIME (the normal case)
    1.49  }
    1.50  
    1.51  Time 
    1.52 @@ -685,39 +651,7 @@
    1.53        return TimeStep (0);
    1.54      }
    1.55  
    1.56 -#ifdef PERMIT_WALLCLOCK_SIMULATION_TIME
    1.57 -  //
    1.58 -  // If we're running in real-time mode, it is possible that an event has been
    1.59 -  // entered into the system using ScheduleNow, which used the current real
    1.60 -  // time as the invocation time.  By the time the scheduler gets around to
    1.61 -  // running the event, there will be an implied negative GetDelayLeft.  From
    1.62 -  // a client point of view, if someone were to ScheduleNow an event and follow
    1.63 -  // that immediately by a GetDelayLeft on that event there would be a negative 
    1.64 -  // GetDelayLeft since it is almost certain that at least one minimum time 
    1.65 -  // quantum has passed.  We don't allow these cases to happen.  GetDelayLeft
    1.66 -  // reports zero if the event has expired OR if it is late.
    1.67 -  // 
    1.68 -  if ((m_reportSimulatedTime == false) && Running ())
    1.69 -    {
    1.70 -      uint64_t tsEvent = id.GetTs ();
    1.71 -      uint64_t tsNow = m_synchronizer->GetCurrentRealtime ();
    1.72 -
    1.73 -      if (tsEvent > tsNow)
    1.74 -        {
    1.75 -          return TimeStep (tsEvent - tsNow);
    1.76 -        }
    1.77 -      else
    1.78 -        {
    1.79 -          return TimeStep (0);
    1.80 -        }
    1.81 -    }
    1.82 -  else
    1.83 -    {
    1.84 -      return TimeStep (id.GetTs () - m_currentTs);
    1.85 -    }
    1.86 -#else  // Do not PERMIT_WALLCLOCK_SIMULATION_TIME (the normal case)
    1.87    return TimeStep (id.GetTs () - m_currentTs);
    1.88 -#endif // Do not PERMIT_WALLCLOCK_SIMULATION_TIME (the normal case)
    1.89  }
    1.90  
    1.91  void

     2.1 --- a/src/simulator/realtime-simulator-impl.h	Thu Aug 28 15:06:49 2008 -0700
     2.2 +++ b/src/simulator/realtime-simulator-impl.h	Thu Aug 28 15:11:55 2008 -0700
     2.3 @@ -114,32 +114,6 @@
     2.4  
     2.5    Ptr<Synchronizer> m_synchronizer;
     2.6  
     2.7 -#ifdef PERMIT_WALLCLOCK_SIMULATION_TIME
     2.8 -  /*
     2.9 -   * In calls to Simulator::Now we have a basic choice to make.  We can either
    2.10 -   * report back the time the simulator thinks it should be, or we can report 
    2.11 -   * the time it actually is.
    2.12 -   *
    2.13 -   * The synchronizer will make an attempt to cause these two numbers to be as
    2.14 -   * close as possible to each other, but they will never be exactly the same.
    2.15 -   * We give the client a choice in this respect.  
    2.16 -   *
    2.17 -   * If the client sets m_reportSimulatedTime to true, the behavior will be that 
    2.18 -   * the simulator runs as close as possible to real time, but reports back to the
    2.19 -   * client that it is running at exactly real time, and consuming no real time 
    2.20 -   * as each event executes.  This allows for deterministic execution times and
    2.21 -   * repeatable trace files.
    2.22 -   *
    2.23 -   * If the client sets m_reportSimulatedTime to false, the behavior will be that 
    2.24 -   * the simulator runs as close as possible to real time, and reports back to the
    2.25 -   * client the real wall-clock time whenever it asks.  Real time will be consumed
    2.26 -   * as each event executes.  This allows for non-deterministic execution times and
    2.27 -   * real variations in event executions.  Simulation time will be influenced by
    2.28 -   * variations in host process scheduling, for example.
    2.29 -   */
    2.30 -  bool m_reportSimulatedTime;
    2.31 -#endif
    2.32 -
    2.33    /**
    2.34     * The policy to use if the simulation cannot keep synchronized to real-time.
    2.35     */