[Ns-developers] NS3 Animation Interface and stand-alone animation tool

[Gustavo Carneiro]

2009/1/26 George Riley <riley at ece.gatech.edu>

>
> I am afraid I was unable to run NetAnim.  The included binary is for OSX,
>> and there is some problem in the makefile:
>
>
>       make: *** No rule to make target
> `/usr/local/Trolltech/Qt-4.4.0/mkspecs/macx-g++/qmake.conf', needed by
> `Makefile'.  Stop.
>
> Didn't expect you to be able to run it (included the binary by mistake,
> sorry).
> If you have qt4 installed, you should be able to build it however.  Run the
> "qmake"
> program in the qt4 "bin" directory (wherever qt4 binaries are installed).
> THen the make
> should work.
>

Indeed, after qmake I could compile it with no problem at all.

However when I run the program it starts generating a series of png files to
disk, which slows down the animation a lot.


>
>
> Regarding the core changes, I have to agree with Tom that it might not be a
> good idea to add animation-specific trace sources.  I think we can either
> add Tx and Rx trace sources, with no time or duration (they could be derived
> from Simulator::Now), or we have a single source like "Transfer" with begin
> and end time.  But not both; that would be duplication of functionality,
> IMHO, and to be avoided.   And I think separate Tx and Rx events are
> slightly more flexible than a single event for both.
>
> I think Tom was objecting to the name "Anim" rather than the existence of
> animation specific trace sources.
> Can you explain why you object to more functionality that someone might
> want?  If you don't need it,
> don't use it.
>

My objection is not strong, however I could point out a couple of
disadvantages:

  1- Many trace sources providing the same information can be confusing for
the programmer;

  2- Each trace source represents a small bit of added maintenance burden
for the maintainer of the netdevice.  Each time a developer refactors de
code of the netdevice he has figure out how to keep providing each of the
existing trace sources, even though some of them may be redundant.

The objection for the Anim name is simply that, if a trace source is useful
for animation then it is probably also useful for simulations in general,
and so it makes sense to use a more generic name.


>
>
> Regarding the "animation interface", well I guess it tries to fulfill a
> role similar to pcap or ascii tracing functions.  So following similar style
> as them makes some sense, i.e. helper-like functions.
>
> Regarding wireless, in the case of pyviz I do not try to represent an
> animated packet traveling, only an arrow at the time of packet reception by
> the receiving node, so my job is simplified.  Nevertheless, it was easy
> enough to obtain the needed information via Tx and Rx event in the
> WifiNetDevice.  But if you want to represent a packet traveling you cannot
> use Tx plus Rx and take the time difference as transmission time because, as
> I recently was
> surprised to discover, Tx is a trace source when a packet is queued, not
> when its transmission begins.
>
> This sounds like it should be fixed; at Tx trace source should call back
> when a packet is transmited.
>

I would agree with such a fix.  I have to confess that for a long time I
assumed Tx in wifi meant the packet about to be prepared for transmission,
i.e. the start a DCF medium acquisition process.  But no, when Tx is emitted
the packet is simply arriving at the netdevice and entering the
WifiMacQueue, i.e. equivalente do a TxQueue/Enqueue event in CSMA.


>
>
>
> The only other thing regarding wireless that I do is to periodically (every
> 100ms) monitor WifiNetDevice::GetBssid() of STAs, match it against AP MAC
> addresses, and represent dashed lines for matching pairs.  This gives you an
> idea of which STAs are associated with which APs.  So it's really nothing
> complicated.
>
> On a related subject, personally I liked better the iNSpect style of
> showing packet transmissions as arrows that appear and disappear, because
> unless the simulation animation is much slower than real time the animated
> packets would be pretty fast since the transmission delays are often very
> low.  And the arrow has added benefits, like being able to condense multiple
> packets in a single arrow, whose thickness can be controlled to give a
> visual cue of the bitrate, as well as adding a label to indicate the flowing
> bitrate.
>
> Clearly, with a generic interface and stand along animator, we could of
> course animate packets in any way
> we want;
>

Definitely.  We should provide information for both approaches, or even the
animator could switch between them depending on speed.

Regards,

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