[Ns-developers] NS-3 GUI (visualization again)

Gustavo Carneiro gjcarneiro at gmail.com
Wed Jul 30 11:18:22 PDT 2008

2008/7/30 <craigdo at ee.washington.edu>

> > > void MySimulatorRun ()
> > > {
> > >     while (!Simulator::IsFinished ())
> > >    {
> > >       Simulator::Lock ();
> > >       Simulator::RunOne ();
> > >       Simulator::UnLock ();
> > >    }
> > > }
> > >
> > > I would expect the above to work and make sense even for
> > the threaded
> > > simulator.  It's all about documentation.  No need to assert in
> > > Simulator::RunOne, just put in the documentation that you must hold
> > > the simulator lock before calling it.
> There's more to the story than this.
> What I wrote earlier was that I would have an assert there for a realtime
> simulator.  I think this is correct.
> How does the code above have any relation whatsoever to real time?  You
> can't just call RunOne at random times.  You have to run the event at the
> head of the queue at the real time at which it expects to be run.  This is
> the realtime piece of the puzzle that you will have to solve in your GUI.
> There are other interesting (more difficult) things you have got to do if
> you want to be able to have other threads scheduling events while your run
> thread is (sleep) waiting for the current event deadline to expire.  This
> is
> the interruptible-wait piece of the puzzle.  This is what I meant when I
> said that if you want to implement your own realtime scheduler loop you,
> "move basically the whole multithreaded interruptible-wait
> realtime-synchronizer thing up into the GUI application."  This still
> sounds
> like a bad plan to me although nothing is stopping you (use the default
> simulator implementation and make your own realtime scheduling of RunOne in
> your GUI).
> There is another level of simulation you can use, however, which seems to
> be
> the case you are assuming.  This is *not* a realtime simulator, this is
> using the multithreaded simulator in a free-time simulation.  By default
> the
> emu code comes as a realtime simulator, however, you can decide that you
> don't want to sync to realtime and set what I called a null synchronizer.
> Then your GUI loop could start to look like yours above.  This would buy
> the
> ability to support Simulator::ScheduleNow or Simulator::Schedule calls from
> other threads (real devices) in a non-realtime environment; but I'm not
> sure
> how meaningful of a scenario that would be.

Hm.. using your real time scheduler with a custom synchronizer is another
option I should probably evaluate...

But I have to confess this all a bit more complex than it sounds, and some
of these problems I already had to deal with in some degree in the
gjc/ns-3-viz branch:

  1- The simulation thread can run faster than real time, and we need to
slow it down;

  2- The simulation thread can be slower than real time, and we just let it
run as fast as it can.

The visualizer, in both cases, must _sample_ the state of the network at
real-time rate of 10-30 times per second.

I think a single lock can be used for both cases:

  1- If the simulation runs slower than real time, the simulator holds the
lock most of the time, and releases it every 33ms of real time;

 2- If the simulation runs faster than real time, the simulator still holds
the lock some of the time, and the visualizer holds the lock some other part
of the time.

Yes, I know it's complicated, but it can be done.  Unless the "synchronizer"
of ns-3-emu makes it easier, somehow.  I don't know.

> In any case, if you thought it was a reasonable case to support, RunOne
> could check to see if there is realtime going on under the sheets and look
> more like,
>  bool
>  DefaultSimulatorImpl::RunOne (void)
>  {
>    if (m_synchronizer->Realtime () == false)
>      {
>         if (!m_events->IsEmpty ())
>          {
>            ProcessOneEvent ();
>          }
>           ...
>      }
>     else
>       {
>        NS_ASSERT_MSG(false, "No, you really don't want to do that");
>        return false;
>      }
>  }
> The bottom line is that I think running an event without consideration of
> the event execution time in a realtime simulation is a nonsense request and
> the system should respond with an assert.  If you want to admit the
> possibility of degenerate cases, okay, we could refine the assert to admit
> another case.  If you are a brave user and know exactly what you are doing,
> you can provide a simulator implementation that does anything your heart
> desires including building some kind of realtime GUI.

OK, I missed the real time part.  I was just a assuming it to be a
thread-safe scheduler, nothing more.  Agree with you it should just assert.

But it is ok for the normal scheduler, right?

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

More information about the Ns-developers mailing list