NS-3 Study Notes 3

The 5th chapter of Ns-3 Tutorial, tweaking 5, is studied today . Tweaking (NS3 coup) 5.1 using logging module

In the first.cc script has seen the use of logging statements, the following to see the specific situation of the logging subsystem.
1.Logging Overview
Large systems have logging capabilities, and NS-3 is no exception. NS-3 think of various information levels (for example: Error, warning, info, debug ...). Logs are useful, so an optional, multi-level message log system is provided. The log can be turned off completely, or it can be started or globally enabled by module.
To record debugging info, warnings, error messages, or you want to get the output quickly from your model, the log system is your first choice. Currently, there are 7 levels of log messages: Log_error, logging errors, corresponding macro Ns_log_error Log_warn, recording warnings, corresponding macro Ns_log_warn log_debug, recording debug information, corresponding macro Ns_log_debug Log_ info, records general information, corresponds to Macro Ns_log_info log_function, records the information of the called function. Macro Ns_log_function, used to record member functions, and macro Ns_log_function_noargs for recording static function information. Log_logic, the logical process of recording functions, corresponding to the macro ns_log_logic Log_all, record all the above mentioned information, no corresponding macro.
There is also an unconditional log, the corresponding macro is Ns_log_uncond
Let's use some of the above knowledge to get some interesting details about the first.cc simulation process.
2. Start Logging
Just to get our bearings, run the original Myfirst script first:

./waf–run Scratch/myfirst

If you want udpechoclientapplication to output more information, set the environment variable at the command line:

Export Ns_log=udpechoclientapplication=level_all

Run the script again to get the following results:

As you can see from the image above, the method of udpechoclientapplication from creating, matching parameters, sending, receiving, and finally ending the destruction is shown. These additional messages are at the ns_log_function level, which shows the procedure for the function call.
In some cases, it may not be possible to know from the above log which object or function the message originated from, to find out who sent the message, you can use the OR operator to append prefix_func to the NS_LOG environment variable, for example:

Export ' Ns_log=udpechoclientapplication=level_all|prefix_func '
Note the above quotation mark ", or number |, there must be no space in the middle

The white highlighted section shows the 1024-byte packets emitted by the Send function. All other messages from Udpechoclientapplication are appended with a function name prefix, so you know who sent the message. For example, you can look at udpechoserverapplication similar to the following:

Export ' Ns_log=udpechoclientapplication=level_all|prefix_func:udpechoserverapplication=level_all|prefix_func '
Note the above quotation mark ', or operation number |, connection number:

If you also want to see the time that the log message was generated, you can append prefix_time using or operation notation, for example:

Export ' ns_log=udpechoclientapplication=level_all|prefix_func|prefix_time:udpechoserverapplication=level_all| Prefix_func|prefix_time '

The highlighted part of the above figure is the result of appending the prefix_time.
PS. To my curiosity, I do experiments on my own computer, Udpechoclientapplication:handleread is called at 2.00737s, and the official tutorial time is 2.00737s. The simulation process is not dependent on the host hardware performance. This reflects what the problem, in the analysis of the results of the simulation should pay attention to what, temporarily do not know, first marked.

To see all the hidden details during the simulation, we can set the following system variables:

Export ' Ns_log=*=level_all|prefix_func|prefix_time '

Then run and save a large amount of output to log.out:

./waf–run Scratch/myfirst > Log.out 2>&1
Note:> Log.out indicates that the result is output to log.out, and 2>&1 indicates that the standard error output is redirected to standard output; The above statement can also be written like this:./waf–run scratch/myfirst &> Log.out, that is, the standard output and the standard error output are all redirected to file.

Consider using this setting when you don't know what's wrong with the simulation process, or if you want to manually check if there are any problems.

3. Add as logging in the Code
In addition to setting the command-line environment variable Ns_log, you can also append logs at various levels in your code. Before in the first.cc there is a sentence: Ns_log_component_define ("firstscriptexample");
For example, we can use Ns_log_info to add some hint messages before building the node process:

...
Ns_log_info ("Creating Topology");
Nodecontainer nodes;
...

Modify the environment variables below and then execute the script:

Export Ns_log=firstscriptexample=info
./waf–run Scratch/myfirst

5.2 Using command-line arguments

1. Overriding default attributes
Without changing the ns-3 script, the way to change its behavior is to use command-line arguments. NS-3 designed a set of mechanisms to parse these parameters and complete them as global or local variables.
Declare it in the script before using the command line parameter system. This requires writing the following sentence in the main function:

int
Main (int argc, char *argv[])
{
...
CommandLine cmd;
Cmd. Parse (argc, argv);
...
}

These two lines open the NS-3 global variable and the property system. If not added, the subsequent operation will not have the expected result:
Enter the command:

./waf–run "Scratch/myfirst–printhelp"

Shows which print commands are available, including printgroups, Printtypeids, Printgroup, Printattributes, printglobals

Now let's take a look at printattributes and see NS3: What are the attributes of the:P Ointtopointnetdevice:

./waf–run "SCRATCH/MYFIRST–PRINTATTRIBUTES=NS3::P ointtopointnetdevice"

Some of these properties have been set in the program, while others have not been set and their values are the default values. For example: Datarate we set to 5Mbps in first.cc, and its default value is 32768bps, if it is not explicitly modified in the script, it will run with the default value. The experiment is not done, the idea is to remove the relevant script statements, and then set the log environment variable to

Export ' Ns_log=udpechoserverapplication=level_all|prefix_time '

Then run the program to view the log, and you will see that the time that Echoserver receives the packet becomes longer (slower). The point here is to describe how to change the default value of a property at run time, using the following command:

./waf–run "SCRATCH/MYFIRST–NS3::P ointtopointnetdevice::D atarate=5mbps"

This is the same as the effect of modifying datarate in code, but in a different way. In the following example, look at the properties of the Pointtopointchannel and then modify some of its properties:

./waf–run "SCRATCH/MYFIRST–PRINTATTRIBUTES=NS3::P ointtopointchannel"
./waf–run "SCRATCH/MYFIRST–NS3::P ointtopointnetdevice::D atarate=5mbps–ns3::P ointtopointchannel::D elay=5ms"

After modifying datarate, the above command modifies the value of the channel delay delay, the value of Maxpackets, and the two settings are separated by a space in the middle.

./waf–run "SCRATCH/MYFIRST–NS3::P ointtopointnetdevice::D atarate=5mbps–ns3::P ointtopointchannel::D elay=5ms–ns3:: Udpechoclient::maxpackets=2 "

2.hook of its own value
With AddValue, you can add your own hooks to the command line. As an example, we'll use this feature to set the number of sends for the ECHO package. First, add a local variable npckets to the first.cc:

int
Main (int argc, char *argv[])
{
uint32_t npackets = 1;
CommandLine cmd;
Cmd. AddValue ("Npackets", "number of packets to echo", npackets);
Cmd. Parse (argc, argv);
...
Echoclient.setattribute ("Maxpackets", Uintegervalue (npackets));

and use CMD. AddValue (), CMD. The Parse () method joins the command-line system and replaces the existing constant 1 with npackets, where the Maxpackets property is set later.
Now run the script and print out the command line parameters using –printhelp, and you will see Npackets in the program Argument (the old version appears to be the user Argument) column.

./waf–run "Scratch/myfirst–printhelp"
./waf–run "scratch/myfirst–npackets=2"

As you can see from the image above, Echo sends two back and forth. 5.3 Using the tracing system

The simulation program to get the output results, this is the goal of the simulation. NS-3 's tracing system is the main mechanism used to generate output results. There are some problems with the standard C + + output, so NS3 provides a universal time tracking subsystem to solve the output problem. There are 3 goals for this system: for basic tasks, the tracing system allows users to generate standard tracing for generic tracing sources and customize which objects generate these tracing. The intermediate users intermediate user must be able to extend the tracing system, change the output format, or insert a new tracing source without changing the analog core module. Advanced users can modify the analog core module to add new tracing sources and sinks.

NS-3 's tracing system consists of independent tracing sources and tracing sinks, as well as a standard mechanism for connecting source and sinks. The tracing sources is an entity that can emit event signals during the simulation and access the relevant data. For example, a trace source might indicate when a packet is received by a network device and can access the contents of the package.
Tracing sources is not very useful to itself, they must be connected to other code, that is, using the information provided by the source to complete some work sinks. Tracing sinks is a consumer of events and time, and tracing sources is a producer. For example, a sink that is connected to a source can print an accepted packet of interest to us.
The clear division between tracing sources and tracing sinks facilitates the user to connect a new type of sinks to an existing sources without writing or recompiling the emulator core module. The user can define a new sink in their own code, and then connect to the source defined by the core module. Below we will explore the predefined tracing sources and sinks, and how to customize. and "Ns-3 Manual" in the book is detailed explained.

1.ASCII Tracing
NS3 provides a number of tools to package the underlying tracing system, enabling users to configure some simple package tracking.
Below we try to view the output as an ASCII file. Open scratch/myfirst.cc, and add the following code before Simulator::run ():

Asciitracehelper ASCII;
Pointtopoint.enableasciiall (ASCII. Createfilestream ("myfirst.tr"));

Ascii. The Createfilestream () method generates an object that represents the file myfirst.tr and hands the object to Enableasciiall (). Enableasciiall () tells the tool that you want to use ASCII tracing for the point-to-point device, turn on the tracing of the device, and want to use trace sinks to output information about the packet in ASCII format. Compile and run the script below:

./waf–run Scratch/myfirst

After running, you will find that the current directory appears in the myfirst.tr file, open later content as follows: 2/nodelist/0/devicelist/0/$ns 3::P ointtopointnetdevice/txqueue/enqueue ns3: :P Ppheader (Point-to-Point Protocol:ip (0x0021)) Ns3::ipv4header (TOS 0x0 DSCP Default ECN not-ect ttl 0 Protocol 1 7 offset (bytes) 0 flags [None] length:1052 10.1.1.1 > 10.1.1.2) ns3::udpheader (length:1032 49153 > 9) Payload (s ize=1024) 2/nodelist/0/devicelist/0/ns3::P ointtopointnetdevice/txqueue/dequeuens3::P ppheader ( Point−to−pointprotocol:ip (0x0021)) ns3::ipv4header (Tos0x0dscpdefaultecnnot−ectttl64id0protocol17offset (bytes) 0f