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

[Gustavo Carneiro]

2008/8/1 Jeremy <jnorman at mines.edu>

> Gustavo,
>
> Again, great feedback.
>
> 5- The 'placement' files for wired nodes are also a PITA. ...
> >
>
> >From just a quick scan of graphviz I was not able to figure out if there
> was
> a separate library. However, it does have command line tools that might be
> able to be used in the absence of a library. If nothing else, a shell
> script
> could be written and distributed with iNSpect so that graphviz can layout
> the nodes and then have iNSpect run from that automatically. Obviously,
> there are other options that could quite likely be better as well -- even
> maybe creating an interpreter that reads straight from graphviz and a
> command line option that attempts to fork graphviz and pipe information
> back
> into iNSpect?
>

In my Ubuntu system, I have both a graphviz library and graphviz python
bindings.


>
>
> In any event, any of the options are probably going to need to wait a few
> weeks until fall semester starts for the Toilers to do it alone. However, I
> am going to put a ticket into bugzilla so that we at least look into it.
>

I'll probably post something quick made in python soon, then let you use it
(or not) however you see fit.


>
>
> -Jeremy
>
> On Thu, Jul 31, 2008 at 4:35 PM, Gustavo Carneiro <gjcarneiro at gmail.com
> >wrote:
>
> >
> >
> > 2008/7/31 Gustavo Carneiro <gjcarneiro at gmail.com>
> >
> >
> >>
> >> 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>
> <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++ ;-)
> >>
> >
> > I forgot one item:
> >
> >    5- The 'placement' files for wired nodes are also a PITA.  But I
> > completely understand why you want it.  Wired simulations in NS-3 have no
> > mobility models, and so nodes have no position.  Figuring out an optimum
> > layout automatically for nodes with links to other nodes is a complicated
> > problem, and one which a tool called graphviz is good at solving.  It
> also
> > has a library, though I am not sure if the layout engine is exported by
> it,
> > I'll check tomorrow.  So ideally a visualizer should be able to layout
> > automatically even wired nodes, and get rid of the awful .placement file
> > requirement.
> >
> > --
> > Gustavo J. A. M. Carneiro
> > INESC Porto, Telecommunications and Multimedia Unit
> > "The universe is always one step beyond logic." -- Frank Herbert
> >
>
>
>
> --
> Curiosity didn't kill the cat, it taught it something it didn't know
> before.
>



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