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

[Gustavo Carneiro]

2008/7/31 Jeremy <jnorman at mines.edu>

> Hey all,
>
> I am working with the Toilers on updating to NS-3 and have a few thoughts
> on
> the subject of visualization.
>
> First of all, I agree with using postmortum visualization argument for many
> of the reasons that have already been stated. The most important being
> fewer
> libraries. This is a big deal for those of us in research who are looking
> more and more at cloud computing or cluster computing in any way. Adding
> graphics library requirements just makes installation harder and more
> confusing.


I agree post-mortem is interesting.  I just don't agree post-mortem is _all_
that is interesting. :-)


>
>
> Next, the latest version of iNSpect does compile and did when this
> conversation began (in fact the latest version is over a month old). It is
> version 4r2125 and at the bottom of the file list at
> http://alamode.mines.edu/~jnorman/toilers/inspect<http://alamode.mines.edu/%7Ejnorman/toilers/inspect>If you would like some
> help getting iNSpect to compile, we have documentation that is specific to
> many platforms at http://www.google.com/group/nsinspect. Additionally, I'd
> be glad to help anyone get going.


Thanks to your help, it now compiles for me as well.  Thank you.


>
>
> So let me fill everyone in on some of the advances of iNSpect since our
> last
> conversation. Many of them were specific to the questions at hand.
>
> Also, iNSpect has finally been made multi-threaded. The most interesting
> part of this is that the file readers are multi-threaded as well which
> allows the program to read separately from visualizing. The reason that we
> went through all the trouble of doing this was to make iNSpect able to read
> simulation information directly from a pipe and visualize real-time with
> the
> simulator. The only part left of the real time visualization is to connect
> the standard in to a file stream and get a trace file format that NS-3 and
> iNSpect both understand.
> Using pipes addresses the issues of disk space and library dependencies by
> separating the two.
>
> As far as being customizable, we did not create a python/tcl/etc api for
> iNSpect, however, we have been working very hard to break iNSpect into
> clear
> MVC chunks which allow for representation of any information you need.
> There
> is now a data input API for reading from file streams, pipes, or SQL if
> necessary. Also, a model API which allows dynamic non simulation related
> information to be added. Finally we have a separate visualization API which
> allows new ways to visualize old data and easy ways to plug in new data.
> An example of how to add energy (on/off) information to the simulation is
> already up on the google group.
>

>
> So for now, many of the features people want the most are nearly ready for
> use. Right now we are just in a lull because it is summer break on campus
> and are short on people. We welcome any help and especially insight into
> feature requests/etc to make sure that our tool is actually useful to
> people
> rather than just us.
>
> We expect to be wrapping up a lot of loose ends in the features I've
> mentioned and fully documenting them in the next month or so. There are
> only
> two serious steps left before it is a tool I would deem usable for NS-3:
> write a module to trace information we need out of the NS-3 API and get
> some
> more intense user-testing of the code.


I have been now trying to fire up iNSpect and my impressions are:

  1- Lack of ns-3 integration, as you mention in that last paragraph.  I was
unable to get any ns-3 example to display in iNSpect.  So you're working on
it.  I get it.  However, I may not have time to wait for it, but that's
another matter;

  2- Both command line and graphical interfaces are cluttered:

      a) In the command line I need to run: ./iNSpect
sample/simple_wireless.conf   -l2 sample/simple.tr
          I have a problem with the configuration file: I hate configuration
files.  Why can't iNSpect just pick some default values and make the
customization optional?

      b) The GUI has 3 windows, one with the animation, one with controls,
yet another with statistics.  Ideally it should be just one window with
everything.  Also the buttons are huge.

  3- The matter of OpenGL I already discussed a few months back.  Besides my
lack of OpenGL coding skills (that's my own problem, I suppose), OpenGL does
not allow saving figures into vector graphics formats such as EPS, SVG, or
PDF.  A Cairo based renderer easily supports those formats.  On the other
hand, Cairo is usually slower than OpenGL for animations, I get that too :|

  4- Being 100% C++ is a problem if I wanted to hack on it, as I am tired of
so much C++ lately :P  OK, maybe this is another personal quirk, and not
applicable to the project as a whole, I don't know.  Need do spend more time
coding Python and less C++ ;-)


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