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

[Gustavo Carneiro]

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>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