Post processing NS2 Result using NS2 Trace

In this post, I will show you a simple (and perhaps the most common way) to create an NS2 trace file. This trace file contains a lot of information. In fact, it contains too much information, which intimidates NS2 users. Don’t worry about it. We will try to interpret NS2 trace files later. For now, let’s focus on how an NS2 trace file can be created.

To create a trace file, you need to do the following two steps:

1. Create a file to record tracing information.
2. Record the tracing information to the created file.

Create a File for Writing :-

Tcl uses a command “open” to open a file. The syntax of the command “open” is as follows:

open <filename> <purpose>

where <filename> is the name of the file to be opened, and <purpose> can be

“w” for writing,

“r” for reading, or

“a” for appending

This statement returns a file handle, which can be used to refer to the opened file.

An example of a Tcl statement which opens a file whose name is “tracefile.tr” for writing and stores to the file handle in the variable $var is shown below:

set var [ open tracefile.tr w ]

Record tracing information in the opened trace file :-

The next step is to record trace information in the opened file. This can be achieved using the following Tcl statement:

$ns trace-all $var

where $ns is the Simulator instance, and $var is the file handle. This statement tells all the tracing objects (e.g., enqT_, deqT_, rcvT_, and drpT_ in the SimpleLink object below) to record information of traversing packets in the trace file whose variable is $var.

There is only one requirement for tracing: The above statement must be located prior to “$ns run”.

After the simulation complete, a trace file would be created. Here is an example of trace files.

The statement “$ns trace-all” inserts tracing object into various places in network topology. The most common place is in a SimpleLink usually used to connect two nodes. The statement “$ns trace-all” inserts few tracing objects into the SimpleLink object as shown above.

A tracing object sits between two NsObject intercepting objects. Once receiving a packet, it prints related tracing information as a line into the trace file. In the above figure, we have four tracing objects:

• enqT_: Print a line beginning with “+”, indicating an enqueuing event
• deqT_: Print a line beginning with “-”, indicating a dequeuing event
• rcvT_: Print a line beginning with “r”, indicating a packet reception event
• drpT_: Print a line beginning with “d”, indicating a packet dropping event

Tracing Statements in the Trace File:

These tracing objects print information of all traversing packets. Information of packets which do not pass through any of these objects would not appear on the trace file.

The only object responsible for dropping packets in the above figure is queue_. It does so by invoking function drop(p). The function drop(p) in turn sends the packet p to the forwarding NsObject, which in this case is drpT_. It is drpT_, who is responsible for printing dropping information statements (i.e., those begin with ‘d’) in the trace file.

This means that if you drop the packet explicitly (e.g., using drop(p)) without passing the packet through drpT_, no information about dropping packet would appear on the trace file.