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

George Riley riley at ece.gatech.edu
Mon Jan 26 06:56:35 PST 2009

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

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

Thanks for the feedback Gustavo; much appreciated.


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

More information about the Ns-developers mailing list