[Ns-developers] NS-3 GUI (visualization again)
jnorman at mines.edu
Thu Nov 6 10:02:24 PST 2008
Its been a long time since we last spoke about ns-3 visualization. Sorry
I was curious if ns-3 can already do some or all of the stuff we spoke about
in September (nam traces). If so, could point me in the right direction to
getting a nam trace so that we can get iNSpect running on ns-3 simulations?
Otherwise, how would you like to move forward? I'd really like to have
iNSpect able to at least visualize basic simulations before the end of this
On Thu, Sep 4, 2008 at 2:13 PM, Mathieu Lacage <
mathieu.lacage at sophia.inria.fr> wrote:
> On Thu, 2008-09-04 at 14:53 -0600, Jeremy wrote:
> > In ns-3, there is no difference between the initial node
> > position and
> > the changes in the node position and/or velocity. They are all
> > reported
> > as a set of events which indicate that a new position/velocity
> > is about
> > to take effect at a specific time. So, initial node positions
> > are
> > usually reported as events for time 0.0.
> > That works perfectly. The only reason I wrote that in is because the
> > new-trace format for ns-2 used to only report changes in node
> > position. That works fine except for when a node does not move during
> > a simulation (eg a base station).
> Actually, I was wrong so, I have to correct my first statement. The
> first position is not reported automatically anymore (if you use the
> MobilityHelper class) but we can easily add some special code to iterate
> over all nodes with a position and output it anyway as events for time
> 0.0. So, nothing to worry about.
> > In ns-3, you have to register with each layer for its packet
> > events so,
> > the network layer is implicit when you get a packet event. The
> > other
> > items might be problematic depending on your definition:
> > a) involved parties
> > b) port
> > c) packet comment
> > a. Involved parties would be every node that heard the information. So
> > for unicast, it would normally be two nodes on a hop, where broadcast
> > is everyone in range. It could be easier if the packet was formatted
> So, this "involved parties" is a layer-2 specific thing, right ? If so,
> there is no problem to provide a list of nodes (sender + rx). In nam
> format, though, this information is implicit through the 'ghost node'
> thing I describe below. i.e. the rx side is identified by the ghost node
> (I think).
> > such that the involved parties was just a list of nodes with the
> > first one being the sender and the rest being the ones who heard it.
> > However, it is not necessary and maybe not even a good idea since
> > traces would be harder to parse if they were used in other ways by
> > researchers as well. What do you guys think would be easiest or most
> > useful for implementing considering how ns-3 works?
> > b. Port is not necessary, but would be nice to allow filtering when
> > visualizing.
> We have tried to provide something like this by allowing you to 'tag'
> any application-level flow with a magic id which you can retrieve from
> each byte of a packet at any other layer (including layer 2).
> > We have two types of links:
> > - point to point links: duplex with one pair of nodes
> > interconnected.
> > - non-point to point links: multiple nodes potentially
> > talking to all
> > other nodes.
> > We can, of course, report both of these to you: how do you
> > want that
> > information to be formatted ?
> > So currently, nam defines
> > l -t time -s src -d dst -S state -c color -o orientation -r bw -D
> > delay
> > from what I understand as far as the link format. To me, I think
> > extending this would be the best way to go about it. The two
> > impressions I have are to allow multiple -d flags or to make the
> > individual -d flag a list of nodes when reporting multiple links.
> I believe that nam uses so-called 'ghost nodes' to represent shared
> X -t * -n ghostNodeId -r rate -D delay
> L -t * -s ghostNodeId -d node0
> L -t * -s ghostNodeId -d node1
> L -t * -s ghostNodeId -d node2
> L -t * -s ghostNodeId -d node3
> > Either way is easy to deal with for iNSpect's purposes. What do you
> > guys think is a better solution though for long term, etc?
> I don't care much either way: I think that we can easily accomodate your
> needs so, we should do what is the easiest for you.
> > I think that maybe this we can worry about at a later date. The
> > thought was that the simulator would be better suited to tell if two
> > nodes were in range than a simple concentric circle in iNSpect.
> > However, it is noisy data that becomes very useless when more
> > realistic propagation models are applied, so lets just forget it for
> > now.
> Yes. Right now, the ns-3 wifi model has a relatively fancy
> propagation/interference model so, it is hard to give you a simple max
> propagation distance which will depend on the transmission mode used for
> each packet, etc.
> > I also forgot to add, that any other information you can think of
> > would also be nice. If it is information that would be good to
> > visualize, lets start that list up too. If we provide that information
> > through tracing, we are that much closer to providing it in the
> > visualizer.
> that would be, indeed, great.
Curiosity didn't kill the cat, it taught it something it didn't know before.
More information about the Ns-developers