[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