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

[Gustavo Carneiro]

2008/7/30 Joseph Kopena <tjkopena at cs.drexel.edu>

> On Tue, Jul 29, 2008 at 7:13 PM, Gustavo Carneiro <gjcarneiro at gmail.com>
> wrote:
> >  I need to start thinking seriously about visualization in NS-3.  Mathieu
> > thinks I should share my thoughts, in case anyone has some suggestion, so
> > here it is :-)
>
> Gustavo,
>
> We should all talk about this before you jump into hacking something
> up.  Tom, Mathieu, and I had a long f2f discussion about this a few
> weeks ago, and I have prototype code that discussion was based on,
> experiences of which have suggested a solid forward path.  Long story
> short, there's been some discussion about this & good ideas developed
> for globally useful directions.
>
>
> You should take a look at [1].  You don't necessarily have to
> build/use the code, but there's well documented sample output in there
> that's a good prototype sketch of the kind of language needed for this
> (the rendering approach is terrible, but I was in a super rush).  In
> particular, that code & language have been used to generate
> screenshots and movies like the samples at [2].  They demo visualizing
> exactly the kinds of things you're talking about---relationships
> between nodes, events at nodes, state being stored, etc.
>
> While that prototype is very usable, the real lesson was that we need
> to change the way the annotations happen.  That draft language
> essentially provides a small set of graphics primitives which the
> simulation uses to describe how to render itself.  What should happen
> is that the simulation should use tags with no implied graphical
> meaning, but presumably meaning within its context.  I.e., instead of
> outputting commands to flash a double border on the node for a few
> moments, simply tag it with "reg-rcvd" or something that has meaning
> to you.  Then, in addition to output from the simulation, the user
> should input a stylesheet to the rendering specifying how to render
> those events, i.e. "reg-rcvd" triggers a double border flashed for a
> few moments.  There should probably be a default sheet with basic
> events, e.g. "packet-tx," which people can use to quick start.
>
>
> As far as the workflow, I don't understand why you believe you need to
> do this live, as the simulation runs, and you don't actually give the
> reasons for this in the email---everything after you said you would
> can be done w/ either approach.  What is the rationale?  The only
> thing I can see is the difficulty in storing all of the information
> you might want to query with the right-click feature (which is a cool
> idea).  I don't see that as being an issue; I'm comfortable with
> simulation writers specifying data to be recorded for that purpose.
> I'm also not too concerned with the data management.  I think a log
> format could handle it easily, and moving the output to a database
> would be another good, perhaps better, approach.


Joseph, post-mortem visualization has the problem that it is impossible for
the visualizer to guess what/when I want to inspect.  I guess this is
related to the use case I have in mind, which is debugging.  It is
impossible to store every possible state you might want at every possible
instant.  To summarise, downsides that I see are:

  1- It's just too much information to store;

  2-  Additionally, it would be a huge implementation effort, as you'd have
to come up with a serialization format for all your data.  Development
resources just don't scale to everything you want to visualize.



>
>
> On the flip side, doing the visualization has the following
> post-mortem has the following advantages:
>
> - Consumes less run-time memory and processor power.


Since I want to use visualization for debugging, processing requirements
don't matter a lot.  Moreover, it may consumore more CPU and RAM, but uses
much less disk space.


>
>
> - Further seperates the simulator code from any library dependencies.


OTOH you need to come up with a "decorator" language, emit it in the
simulator, collect it in the visualizer.  There's still a strong dependency
between visualizer and simulator.


>
>
> - Ensures some output will be preserved & can help in debugging even
>  if the whole thing crashes---which having a GUI involved only raises
>  the changes of.


If the whole thing crashes, usually you want gdb or valgrind to fix the
problem, not a visualizer.  The worst problems to fix are not crashes, they
are easy to fix, worst are "semantic" problems, of a simulation not doing
what you want it to do :P


> - Enables you to easily share all of the results.


Well, with my approach I can share results by providing the simulation
script (with random seed).  Your approach is slightly better (just provide a
trace file), I agree.


>
>
> - It greatly eases interactions with the simulation.  We're already
>  having a long discussion about how to deconflict interactions w/ the
>  scheduler.  Notably, I didn't have to solve these issues to make [1]
>  work.  Further, we're only going to have more issues as more modules
>  are brought in that people want to use and simulation scripts and
>  applications get more complex.  I don't think the post-mortem
>  approach doesn't suffer these effects nearly as badly.


OTOH post-mortem suffers from the problem of having to define an annotations
file format.


>
>
> - Perhaps most importantly, it allows you to leave, do something else,
>  then come back and quickly visualize the simulation.  I definitely
>  want to be able to script a bunch of simulations to run, possibly
>  for hours each, then come back later and watch what happened.  I
>  also want to make sure I have that output if one of them crashed.
>  Live playback doesn't help with compute-intensive simulations.


But post-mortem does not allow you to inspect any simulation state you
desire, just a predefined set.


>
>
>
> Note that I'm not opposed at all to the kind of playback control you
> discuss, I think that'd be great.  I just don't want to have to sit
> there while the simulation runs in order to see it, and worry the
> whole time that it's going to crash...
>
> Let me know your thoughts & I'd be curious to hear comments from
> others.



To summarize, I think we have slightly different use cases in mind.  You are
more interested in demonstrations, I am more interested in debugging.

Post-mortem is certainly interesting, but live visualization has other
advantages.  An ideal system would have both capabilities.  In that sense,
it might be interesting to figure out how to converge both approaches,
reusing code for both?

For instance, I am still interested in a visualizer written in PyGtk, but
perhaps can function both as live analyzer or post-mortem one.  The
annotations language would be the "unifier" of both approaches if the live
visualizer could generate and consume a stream with annotations, while
optionally saving it to disk.  The same visualizer code could also read the
annotations file from disk, if so desired, although some capabilities (live
inspection) would be disabled in that mode.

Thanks for the useful comments.


PS: Here's a bug report:

gjc at dark-tower:ns-3-decorator$
NS3_LIB_DIR=/home/gjc/projects/ns/ns-3-dev/build/debug/ make
mkdir -p bin/ obj/decorator obj/test
cp src/decorator/decorator.h bin/`basename bin/decorator/decorator.h`
echo bin/decorator/decorator.h
bin/decorator/decorator.h
g++ -Wall -g -DNS3_LOG_ENABLE -DNS3_ASSERT_ENABLE
-I/home/gjc/projects/ns/ns-3-dev/build/debug/ -Ibin/
-L/home/gjc/projects/ns/ns-3-dev/build/debug/ -o obj/decorator/decorator.o
-c src/decorator/decorator.cc
g++ -Wall -g -DNS3_LOG_ENABLE -DNS3_ASSERT_ENABLE -fpic
-I/home/gjc/projects/ns/ns-3-dev/build/debug/ -Ibin/
-L/home/gjc/projects/ns/ns-3-dev/build/debug/ -shared
-Wl,-soname,libns3decorator.so -o bin/libns3decorator.so
obj/decorator/decorator.o
/usr/bin/ld: obj/decorator/decorator.o: relocation R_X86_64_32 against `a
local symbol' can not be used when making a shared object; recompile with
-fPIC
obj/decorator/decorator.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [bin/libns3decorator.so] Error 1


Patch:

diff -r 435b9cddcc7b Makefile
--- a/Makefile    Mon Jul 07 13:54:07 2008 -0400
+++ b/Makefile    Wed Jul 30 11:08:46 2008 +0100
@@ -7,7 +7,7 @@
 INCPATH=-I$(NS3_LIB_DIR) -I$(BIN_DIR)
 LIBPATH=-L$(NS3_LIB_DIR)

-CFLAGS += -Wall -g -DNS3_LOG_ENABLE -DNS3_ASSERT_ENABLE
+CFLAGS += -Wall -g -DNS3_LOG_ENABLE -DNS3_ASSERT_ENABLE -fPIC -DPIC

 SONAME=libns3decorator.so
 ANAME=libns3decorator.a


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