clean up tutorial up through tweaking section
authorCraig Dowell <craigdo@ee.washington.edu>
Tue, 24 Mar 2009 12:45:30 -0700
changeset 4293 11a2cda6a096
parent 4292 ef09115f80ca
child 4294 ebb973fdb763
clean up tutorial up through tweaking section
doc/tutorial/conceptual-overview.texi
doc/tutorial/getting-started.texi
doc/tutorial/introduction.texi
doc/tutorial/tweaking.texi
--- a/doc/tutorial/conceptual-overview.texi	Tue Mar 24 00:51:10 2009 -0700
+++ b/doc/tutorial/conceptual-overview.texi	Tue Mar 24 12:45:30 2009 -0700
@@ -362,21 +362,6 @@
 INFO level for echo clients and servers.  This will result in the application
 printing out messages as packets are sent and received during the simulation.
 
-The next line of code is used to give a fixed seed to the random number 
-generators so that they will generate repeatable results.  In the example
-programs, it allows us to thouroughly document the output of the trace files
-in a consistent way.  Having a fixed seed also allows us to use the examples 
-in our regression testing framework.
-
-@verbatim
-  RandomVariable::UseGlobalSeed (1, 1, 2, 3, 5, 8);
-@end verbatim
-
-Random variables are very important in understanding how to get repeatable
-results, so you are encouraged to read the Doxygen and manual sections to
-understand what is going on there.  For us, the main concern is in making 
-random backoff algorithms consistent across runs.
-
 Now we will get directly to the business of creating a topology and running 
 a simulation.  We use the topology helper objects to make this job as
 easy as possible.
@@ -439,7 +424,7 @@
     pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));
 @end verbatim
 
-The first line 
+The first line,
 
 @verbatim
     PointToPointHelper pointToPoint;
@@ -738,34 +723,46 @@
 the @code{scratch} directory.
 
 @verbatim
-  ~/repos/ns-3-dev > cp examples/first.cc scratch/
+  ~/repos/ns-3-dev > cp examples/first.cc scratch/myfirst.cc
 @end verbatim
 
-and then build it using waf,
+Warning:  We use the file @code{first.cc} as one of our regression tests to
+verify that it works exactly as we expect.  This means that an executable
+named @code{first} already exists in the project.  If you want to execute
+what you compile, and not a previously compiled program, please do the 
+renaming suggested below.)
+
+Now build your example using Waf:
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf
-  Entering directory `/home/craigdo/repos/ns-3-dev/build'
-  [467/511] cxx: scratch/first.cc -> build/debug/scratch/first_1.o
-  [468/511] cxx: scratch/multiple-sources/simple-main.cc -> build/debug/scratch/multiple-sources/simple-main_2.o
-  [469/511] cxx: scratch/multiple-sources/simple-simulation.cc -> build/debug/scratch/multiple-sources/simple-simulation_2.o
-  [470/511] cxx: scratch/simple.cc -> build/debug/scratch/simple_3.o
-  [508/511] cxx_link: build/debug/scratch/first_1.o -> build/debug/scratch/first
-  Compilation finished successfully 
-  ~/repos/ns-3-dev >
+  ./waf
+@end verbatim
+
+You should see messages reporting that your @code{myfirst} example was built
+successfully.
+
+@verbatim
+  Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+  [563/648] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_3.o
+  [646/648] cxx_link: build/debug/scratch/myfirst_3.o -> build/debug/scratch/myfirst
+  Build finished successfully (00:00:02)
 @end verbatim
 
 You can now run the example (note that if you build your program in the scratch
 directory you must run it out of the scratch directory):
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run scratch/first
-  Entering directory `/home/craigdo/repos/ns-3-dev/build'
-  Compilation finished successfully
+  ./waf --run scratch/myfirst
+@end verbatim
+
+You should see some output:
+
+@verbatim
+  Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+  Build finished successfully (00:00:00)
   Sent 1024 bytes to 10.1.1.2
   Received 1024 bytes from 10.1.1.1
   Received 1024 bytes from 10.1.1.2
-  ~/repos/ns-3-dev >
 @end verbatim
 
 Here you see that the build system checks to make sure that the file has been
@@ -793,38 +790,42 @@
 
 The top-level directory for one of our @emph{repositories} will look 
 something like:
+
 @verbatim
-drwxr-xr-x  [up]   
-drwxr-xr-x         doc             manifest 
-drwxr-xr-x         examples        manifest 
-drwxr-xr-x         ns3             manifest 
-drwxr-xr-x         regression      manifest 
-drwxr-xr-x         samples         manifest 
-drwxr-xr-x         scratch         manifest 
-drwxr-xr-x         src             manifest 
-drwxr-xr-x         tutorial        manifest 
-drwxr-xr-x         utils           manifest 
--rw-r--r-- 135     .hgignore       file | revisions | annotate 
--rw-r--r-- 891     .hgtags         file | revisions | annotate 
--rw-r--r-- 441     AUTHORS         file | revisions | annotate 
--rw-r--r-- 17987   LICENSE         file | revisions | annotate 
--rw-r--r-- 4948    README          file | revisions | annotate 
--rw-r--r-- 4917    RELEASE_NOTES   file | revisions | annotate 
--rw-r--r-- 7       VERSION         file | revisions | annotate 
--rwxr-xr-x 99143   waf             file | revisions | annotate 
--rwxr-xr-x 28      waf.bat         file | revisions | annotate 
--rw-r--r-- 30584   wscript         file | revisions | annotate 
+drwxr-xr-x   [up]   
+drwxr-xr-x   bindings python                          files 
+drwxr-xr-x   doc                                      files 
+drwxr-xr-x   examples                                 files 
+drwxr-xr-x   ns3                                      files 
+drwxr-xr-x   regression                               files 
+drwxr-xr-x   samples                                  files 
+drwxr-xr-x   scratch                                  files 
+drwxr-xr-x   src                                      files 
+drwxr-xr-x   utils                                    files 
+-rw-r--r-- 2009-03-24 00:51 -0700 505   .hgignore     file | revisions | annotate 
+-rw-r--r-- 2009-03-24 00:51 -0700 1682  .hgtags       file | revisions | annotate 
+-rw-r--r-- 2009-03-24 00:51 -0700 686   AUTHORS       file | revisions | annotate 
+-rw-r--r-- 2009-03-24 00:51 -0700 14893 CHANGES.html  file | revisions | annotate 
+-rw-r--r-- 2009-03-24 00:51 -0700 17987 LICENSE       file | revisions | annotate 
+-rw-r--r-- 2009-03-24 00:51 -0700 3742  README        file | revisions | annotate 
+-rw-r--r-- 2009-03-24 00:51 -0700 13505 RELEASE_NOTES file | revisions | annotate 
+-rw-r--r-- 2009-03-24 00:51 -0700 6     VERSION       file | revisions | annotate 
+-rw-r--r-- 2009-03-24 00:51 -0700 9257  regression.py file | revisions | annotate 
+-rwxr-xr-x 2009-03-24 00:51 -0700 81285 waf           file | revisions | annotate 
+-rwxr-xr-x 2009-03-24 00:51 -0700 28    waf.bat       file | revisions | annotate 
+-rw-r--r-- 2009-03-24 00:51 -0700 26270 wscript       file | revisions | annotate 
+-rw-r--r-- 2009-03-24 00:51 -0700 6636  wutils.py     file | revisions | annotate 
 @end verbatim
 
 The source code is mainly in the @code{src} directory.  You can view source
-code by clicking on the @code{manifest} link to the right of the directory 
-name.  If you click on the @code{manifest} link to the right of the src
-directory you will find a subdirectory.  If you click on the @code{manifest}
-link next to the @code{core} subdirectory in under @code{src}, you will find
-a list of files.  The first file you will find is @code{assert.h}.  If you 
-click on the @code{file} link, you will be sent to the source file for
-@code{assert.h}.
+code either by clicking on the directory name or by clicking on the @code{files}
+link to the right of the directory name.  If you click on the @code{src}
+directory you be taken to the lising of the @code{src} subdirectories.  If you 
+click on @code{core} subdirectory, you will find a list of files.  The first file
+you will find (as of this writing) is @code{abort.h}.  If you 
+click on @code{abort.h} link, you will be sent to the source file for @code{abort.h}.
 
 Our example scripts are in the @code{examples} directory.  The source code for
 the helpers we have used in this chapter can be found in the 
-@code{src/helpers} directory.
+@code{src/helpers} directory.  Feel free to poke around in the directory tree to
+get a feel for what is there and the style of @command{ns-3} programs.
--- a/doc/tutorial/getting-started.texi	Tue Mar 24 00:51:10 2009 -0700
+++ b/doc/tutorial/getting-started.texi	Tue Mar 24 12:45:30 2009 -0700
@@ -53,9 +53,9 @@
 @cindex repository
 The simplest way to get started using Mercurial repositories is to use the
 @code{ns-3-allinone} environment.  This is a set of scripts that manages the 
-downloading and building of various subystems of ns-3 for you.  We recommend
-that you begin your @command{ns-3} adventures in this environment as it can
-really simplify your life at this point.
+downloading and building of various subystems of @command{ns-3} for you.  We 
+recommend that you begin your @command{ns-3} adventures in this environment
+as it can really simplify your life at this point.
 
 @subsection Downloading ns-3 Using Mercurial
 One practice is to create a directory called @code{repos} in one's home 
@@ -133,7 +133,7 @@
 
 Go ahead and change into the @code{ns-3-allinone} directory you created when
 you cloned that repository.  We are now going to use the @code{download.py} 
-script to pull down the various pieces of @code{ns-3} you will be using/
+script to pull down the various pieces of @command{ns-3} you will be using/
 
 Go ahead and type the following into your shell (remember you can substitute
 the name of your chosen release number instead of @code{ns-3-dev} -- like
@@ -240,7 +240,7 @@
 You are now ready to build the @command{ns-3} distribution.
 
 @subsection Downloading ns-3 Using a Tarball
-The process for downloading @code{ns-3} via tarball is simpler than the
+The process for downloading @command{ns-3} via tarball is simpler than the
 Mercurial process since all of the pieces are pre-packaged for you.  You just
 have to pick a release, download it and decompress it.
 
@@ -470,30 +470,33 @@
 @cindex regression tests
 You can also run our regression test suite to ensure that your distribution and
 tool chain have produced binaries that generate output that is identical to
-reference output files stored in a central location.  To run the regression 
-tests, you provide Waf with the regression flag.
+known-good reference output files.  You downloaded these reference traces to 
+your machine during the download process above.  (Warning:  The @code{ns-3.2} 
+and @code{ns-3.3} releases do not use the @code{ns-3-allinone} environment
+and require you to be online when you run regression tests because they
+dynamically synchronize the reference traces directory with an online
+repository immediately prior to the run).
+
+During regression testing Waf will run a number of tests that generate what we
+call trace files.  The content of these trace files are compared with the 
+reference traces.  If they are identical, the regression tests report a PASS 
+status.  If a regression test fails you will see a FAIL indication along with a
+pointer to the offending trace file and its associated reference trace file
+along with a suggestion on diff parameters and options in order to see what 
+has gone awry.  If the error was discovered in a pcap file, it will be useful
+to convert the pcap files to text using tcpdump prior to comparison.
+
+Some regression tests wmay be SKIPped if the required support
+is not present.
+
+To run the regression tests, you provide Waf with the regression flag.
 
 @verbatim
   ./waf --regression
 @end verbatim
 
-Waf will verify that the current files in the @command{ns-3} distribution are
-built and will then look for trace files in the aforementioned centralized 
-location.  If your tool chain includes Mercurial, the regression tests will 
-be downloaded from a repository at @code{code.nsnam.org}.  If you do not have 
-Mercurial installed, the reference traces will be downloaded from a tarball 
-located in the releases section of @code{www.nsnam.org}.  The particular name 
-of the reference trace location is built from the @command{ns-3} version 
-located in the VERSION file, so don't change that string yourself unless you 
-know what you are doing.  (Warning:  The ns-3.2 release requires you
-to be online when you run regression tests because it synchronizes the
-trace directory with an online repository).
-
-Once the reference traces are downloaded to your local machine, Waf will run
-a number of tests that generate what we call trace files.  The content of 
-these trace files are compared with the reference traces just downloaded.  If 
-they are identical, the regression tests report a PASS status.  If the 
-regression tests pass, you should see something like,
+You should see messages indicating that many tests are being run and are
+passing.
 
 @verbatim
   Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
@@ -510,11 +513,23 @@
   Build finished successfully (00:00:23)
 @end verbatim
 
-If a regression tests fails you will see a FAIL indication along with a
-pointer to the offending trace file and its associated reference trace file
-along with a suggestion on diff parameters and options in order to see what 
-has gone awry.  Some regression tests wmay be SKIPped if the required support
-is not present.
+If you want to take a look at an example of what might be checked during
+a regression test, you can do the following:
+
+@verbatim
+  cd build/debug/regression/traces/second.ref
+  tcpdump -nn -tt -r second-1-1.pcap
+@end verbatim
+
+The output should be clear to anyone who is familiar with tcpdump or net
+sniffers.  We'll have much more to say on pcap files later in this tutorial.
+
+Remember to cd back into the top-level @command{ns-3} directory
+after you are done:
+
+@verbatim
+  cd ../../../../..
+@end verbatim
 
 @c ========================================================================
 @c Running a Script
--- a/doc/tutorial/introduction.texi	Tue Mar 24 00:51:10 2009 -0700
+++ b/doc/tutorial/introduction.texi	Tue Mar 24 12:45:30 2009 -0700
@@ -24,7 +24,7 @@
 The @command{ns-3} simulator is a discrete-event network simulator targeted 
 primarily for research and educational use.  The 
 @uref{http://www.nsnam.org,,ns-3 project}, 
-started in 2006, is an open-source project developing ns-3.
+started in 2006, is an open-source project developing @command{ns-3}.
 
 Primary documentation for the @command{ns-3} project is available in four
 forms:
@@ -43,7 +43,7 @@
 several example simulations, introducing and explaining key concepts and
 features as we go.
 
-As the tutorial unfolds, we will introduce the full ns-3 documentation 
+As the tutorial unfolds, we will introduce the full @command{ns-3} documentation 
 and provide pointers to source code for those interested in delving deeper
 into the workings of the system.
 
@@ -52,9 +52,9 @@
 @item Ns-3 is not an extension of @uref{http://www.isi.edu/nsnam/ns,,ns-2}; 
 it is a new simulator.  The two simulators are both written in C++ but 
 @command{ns-3} is a new simulator that does not support the ns-2 APIs.  Some 
-models from ns-2 have already been ported from ns-2 to ns-3. The project will
-continue to maintain ns-2 while ns-3 is being built, and will study transition
-and integration mechanisms.
+models from ns-2 have already been ported from ns-2 to @command{ns-3}. The 
+project will continue to maintain ns-2 while @command{ns-3} is being built,
+and will study transition and integration mechanisms.
 @item @command{Ns-3} is open-source, and the project strives to maintain an 
 open  environment for researchers to contribute and share their software.  
 @end itemize
@@ -63,36 +63,36 @@
 @section For ns-2 Users
 
 For those familiar with ns-2, the most visible outward change when moving to 
-ns-3 is the choice of scripting language.  Ns-2 is 
+@command{ns-3} is the choice of scripting language.  Ns-2 is 
 scripted in OTcl and results of simulations can be visualized using the 
 Network Animator @command{nam}.  It is not possible to run a simulation
 in ns-2 purely from C++ (i.e., as a main() program without any OTcl).
 Moreover, some components of ns-2 are written in C++ and others in OTcl.
-In ns-3, the simulator is written entirely in C++, with optional
+In @command{ns-3}, the simulator is written entirely in C++, with optional
 Python bindings.  Simulation scripts can therefore be written in C++
 or in Python.  The results of some simulations can be visualized by
-@command{nam}, but new animators are under development.  Since ns-3
+@command{nam}, but new animators are under development.  Since @command{ns-3}
 generates pcap packet trace files, other utilities can be used to
 analyze traces as well.
 In this tutorial, we will first concentrate on scripting 
 directly in C++ and interpreting results via ascii trace files.  
 
 But there are similarities as well (both, for example, are based on C++ 
-objects, and some code from ns-2 has already been ported to ns-3).
-We will try to highlight differences between ns-2 and ns-3
+objects, and some code from ns-2 has already been ported to @command{ns-3}).
+We will try to highlight differences between ns-2 and @command{ns-3}
 as we proceed in this tutorial.
 
 A question that we often hear is "Should I still use ns-2 or move to
-ns-3?"  The answer is that it depends.  ns-3 does not have all of the
-models that ns-2 currently has, but on the other hand, ns-3 does have
-new capabilities (such as handling multiple interfaces on nodes 
+@command{ns-3}?"  The answer is that it depends.  @command{ns-3} does not have
+all of the models that ns-2 currently has, but on the other hand, @command{ns-3}
+does have new capabilities (such as handling multiple interfaces on nodes 
 correctly, use of IP addressing and more alignment with Internet
 protocols and designs, more detailed 802.11 models, etc.).  ns-2
-models can usually be ported to ns-3 (a porting guide is under
-development).  There is active development on multiple fronts for ns-3.
-The ns-3 developers believe (and certain early users have proven) that
-ns-3 is ready for active use, and should be an attractive alternative
-for users looking to start new simulation projects.  
+models can usually be ported to @command{ns-3} (a porting guide is under
+development).  There is active development on multiple fronts for 
+@command{ns-3}.  The @command{ns-3} developers believe (and certain early users
+have proven) that @command{ns-3} is ready for active use, and should be an 
+attractive alternative for users looking to start new simulation projects.  
 
 @node Contributing
 @section Contributing
@@ -119,7 +119,7 @@
 the project is probably not your foremost concern at this point, but
 we want you to be aware that contributing is in the spirit of the project and
 that even the act of dropping us a note about your early experience 
-with ns-3 (e.g. "this tutorial section was not clear..."), 
+with @command{ns-3} (e.g. "this tutorial section was not clear..."), 
 reports of stale documentation, etc. are much appreciated. 
 
 @node Tutorial Organization
@@ -160,14 +160,14 @@
 @cindex architecture
 There are several important resources of which any @command{ns-3} user must be
 aware.  The main web site is located at @uref{http://www.nsnam.org} and 
-provides access to basic information about the ns-3 system.  Detailed 
+provides access to basic information about the @command{ns-3} system.  Detailed 
 documentation is available through the main web site at
 @uref{http://www.nsnam.org/documents.html}.  You can also find documents 
 relating to the system architecture from this page.
 
-There is a Wiki that complements the main ns-3 web site which you will find at 
-@uref{http://www.nsnam.org/wiki/}.  You will find user and developer FAQs 
-there, as well as troubleshooting guides, third-party contributed code, 
+There is a Wiki that complements the main @command{ns-3} web site which you will
+find at @uref{http://www.nsnam.org/wiki/}.  You will find user and developer 
+FAQs there, as well as troubleshooting guides, third-party contributed code, 
 papers, etc. 
 
 @cindex mercurial repository
@@ -221,7 +221,7 @@
 
 The build system @code{Waf} is used on the @command{ns-3} project.  It is one 
 of the new generation of Python-based build systems.  You will not need to 
-understand any Python to build the existing ns-3 system, and will 
+understand any Python to build the existing @command{ns-3} system, and will 
 only have to understand a tiny and intuitively obvious subset of Python in 
 order to extend the system in most cases.
 
@@ -233,9 +233,9 @@
 
 @cindex C++
 @cindex Python
-As mentioned above, scripting in ns-3 is done in C++ or Python.
-As of ns-3.2, most of the ns-3 API is available in Python, but the models
-are written in C++ in either case.  A working 
+As mentioned above, scripting in @command{ns-3} is done in C++ or Python.
+As of ns-3.2, most of the @command{ns-3} API is available in Python, but the 
+models are written in C++ in either case.  A working 
 knowledge of C++ and object-oriented concepts is assumed in this document.
 We will take some time to review some of the more advanced concepts or 
 possibly unfamiliar language features, idioms and design patterns as they 
@@ -255,7 +255,7 @@
 for development.  A 
 software toolchain is the set of programming tools available in the given 
 environment. For a quick review of what is included in the GNU toolchain see,
-@uref{http://en.wikipedia.org/wiki/GNU_toolchain}.  ns-3 uses gcc, 
+@uref{http://en.wikipedia.org/wiki/GNU_toolchain}.  @command{ns-3} uses gcc, 
 GNU binutils, and gdb.  However, we do not use the GNU build system,
 either make or autotools, using Waf instead.
 
--- a/doc/tutorial/tweaking.texi	Tue Mar 24 00:51:10 2009 -0700
+++ b/doc/tutorial/tweaking.texi	Tue Mar 24 12:45:30 2009 -0700
@@ -82,8 +82,8 @@
 documentation if you have not done so.
 
 Now that you have read the documentation in great detail, let's use some of
-that knowledge to get some interesting information out of the @code{first.cc}
-example script you have already built.
+that knowledge to get some interesting information out of the 
+@code{scratch/myfirst.cc} example script you have already built.
 
 @node Enabling Logging
 @subsection Enabling Logging
@@ -92,17 +92,22 @@
 to get our bearings, go ahead and run the script just as you did previously,
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run scratch/first
+  ./waf --run scratch/myfirst
+@end verbtim
+
+You should see the now familiar output of the first @command{ns-3} example
+program
+
+@verbatim
   Entering directory `/home/craigdo/repos/ns-3-dev/build'
   Compilation finished successfully
   Sent 1024 bytes to 10.1.1.2
   Received 1024 bytes from 10.1.1.1
   Received 1024 bytes from 10.1.1.2
-  ~/repos/ns-3-dev >
 @end verbatim
 
-It turns out that the ``Sent'' and ``Received'' messages are actually logging
-messages from the @code{UdpEchoClientApplication} and 
+It turns out that the ``Sent'' and ``Received'' messages you see above are
+actually logging messages from the @code{UdpEchoClientApplication} and 
 @code{UdpEchoServerApplication}.  We can ask the client application, for 
 example, to print more information by setting its logging level via the 
 NS_LOG environment variable.  
@@ -113,7 +118,7 @@
 required by those shells.
 
 Right now, the UDP echo client application is responding to the following line
-of code in @code{first.cc},
+of code in @code{scratch/myfirst.cc},
 
 @verbatim
   LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);
@@ -127,7 +132,7 @@
 script and recompiling by setting the NS_LOG environment variable like this:
 
 @verbatim
-  ~/repos/ns-3-dev > export NS_LOG=UdpEchoClientApplication=level_all
+  export NS_LOG=UdpEchoClientApplication=level_all
 @end verbatim
 
 This sets the shell environment variable @code{NS_LOG} to the string,
@@ -143,21 +148,19 @@
 system will pick up the change and you should see the following output:
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run scratch/first
-  Entering directory `/home/craigdo/repos/ns-3-dev/build'
-  Compilation finished successfully
+  Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+  Build finished successfully (00:00:00)
   UdpEchoClientApplication:UdpEchoClient()
   UdpEchoClientApplication:StartApplication()
   UdpEchoClientApplication:ScheduleTransmit()
   UdpEchoClientApplication:Send()
   Sent 1024 bytes to 10.1.1.2
   Received 1024 bytes from 10.1.1.1
-  UdpEchoClientApplication:HandleRead(0x62c640, 0x62cd70)
+  UdpEchoClientApplication:HandleRead(0x638180, 0x6389b0)
   Received 1024 bytes from 10.1.1.2
   UdpEchoClientApplication:StopApplication()
   UdpEchoClientApplication:DoDispose()
   UdpEchoClientApplication:~UdpEchoClient()
-  ~/repos/ns-3-dev >
 @end verbatim
 
 The additional debug information provided by the application is from
@@ -198,21 +201,19 @@
 name.
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run scratch/first
-  Entering directory `/home/craigdo/repos/ns-3-dev/build'
-  Compilation finished successfully
+  Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+  Build finished successfully (00:00:00)
   UdpEchoClientApplication:UdpEchoClient()
   UdpEchoClientApplication:StartApplication()
   UdpEchoClientApplication:ScheduleTransmit()
   UdpEchoClientApplication:Send()
   UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
   Received 1024 bytes from 10.1.1.1
-  UdpEchoClientApplication:HandleRead(0x62c710, 0x62ce40)
+  UdpEchoClientApplication:HandleRead(0x638180, 0x6389b0)
   UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
   UdpEchoClientApplication:StopApplication()
   UdpEchoClientApplication:DoDispose()
   UdpEchoClientApplication:~UdpEchoClient()
-  ~/repos/ns-3-dev >
 @end verbatim
 
 You can now see all of the messages coming from the UDP echo client application
@@ -227,17 +228,16 @@
                  UdpEchoServerApplication=level_all|prefix_func'
 @end verbatim
 
-Note that you will need to remove the newline after the @code{:} in the
-example text above.
+Warning:  You will need to remove the newline after the @code{:} in the
+example text above which is only there for document formatting purposes.
 
 Now, if you run the script you will see all of the log messages from both the
 echo client and server applications.  You may see that this can be very useful
 in debugging problems.
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run scratch/first
-  Entering directory `/home/craigdo/repos/ns-3-dev/build'
-  Compilation finished successfully
+  Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+  Build finished successfully (00:00:00)
   UdpEchoServerApplication:UdpEchoServer()
   UdpEchoClientApplication:UdpEchoClient()
   UdpEchoServerApplication:StartApplication()
@@ -247,7 +247,7 @@
   UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
   UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
   UdpEchoServerApplication:HandleRead(): Echoing packet
-  UdpEchoClientApplication:HandleRead(0x62c760, 0x62ce90)
+  UdpEchoClientApplication:HandleRead(0x638320, 0x638b50)
   UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
   UdpEchoServerApplication:StopApplication()
   UdpEchoClientApplication:StopApplication()
@@ -255,7 +255,6 @@
   UdpEchoServerApplication:DoDispose()
   UdpEchoClientApplication:~UdpEchoClient()
   UdpEchoServerApplication:~UdpEchoServer()
-  ~/repos/ns-3-dev >
 @end verbatim
 
 It is also sometimes useful to be able to see the simulation time at which a
@@ -266,12 +265,12 @@
                  UdpEchoServerApplication=level_all|prefix_func|prefix_time'
 @end verbatim
 
-If you run the script now, you should see the following output:
+Again, you will have to remove the newline above.  If you run the script now,
+you should see the following output:
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run scratch/first
-  Entering directory `/home/craigdo/repos/ns-3-dev/build'
-  Compilation finished successfully
+  Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+  Build finished successfully (00:00:00)
   0s UdpEchoServerApplication:UdpEchoServer()
   0s UdpEchoClientApplication:UdpEchoClient()
   1s UdpEchoServerApplication:StartApplication()
@@ -281,7 +280,7 @@
   2s UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
   2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
   2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
-  2.00737s UdpEchoClientApplication:HandleRead(0x62c8c0, 0x62d020)
+  2.00737s UdpEchoClientApplication:HandleRead(0x638490, 0x638cc0)
   2.00737s UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
   10s UdpEchoServerApplication:StopApplication()
   10s UdpEchoClientApplication:StopApplication()
@@ -289,15 +288,14 @@
   UdpEchoServerApplication:DoDispose()
   UdpEchoClientApplication:~UdpEchoClient()
   UdpEchoServerApplication:~UdpEchoServer()
-  ~/repos/ns-3-dev >
 @end verbatim
 
 You can see that the constructor for the UdpEchoServer was called at a 
 simulation time of 0 seconds.  This is actually happening before the 
 simulation starts.  The same for the UdpEchoClient constructor.
 
-Recall that the @code{first.cc} script started the echo server application at
-one second into the simulation.  You can now see that the 
+Recall that the @code{scratch/first.cc} script started the echo server 
+application at one second into the simulation.  You can now see that the 
 @code{StartApplication} method of the server is, in fact, called at one second
 (or one billion nanoseconds).  You can also see that the echo client 
 application is started at a simulation time of two seconds as we requested in
@@ -322,29 +320,29 @@
 
 The asterisk above is the logging component wildcard.  This will turn on all 
 of the logging in all of the components used in the simulation.  I won't 
-reproduce the output here (as of this writing it produces 772 lines of output
+reproduce the output here (as of this writing it produces 974 lines of output
 for the single packet echo) but you can redirect this information into a file 
 and look through it with your favorite editor if you like,
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run scratch/first >& log.out
+  ./waf --run scratch/myfirst > log.out 2>&1
 @end verbatim
 
-I personally use this quite a bit when I am presented with a problem and I
-have no idea where things are going wrong.  I can follow the progress of the
-code quite easily without having to set breakpoints and step through code
-in a debugger.  When I have a general idea about what is going wrong, I 
-transition into a debugger for fine-grained examination of the problem.  This
-kind of output can be especially useful when your script does something 
-completely unexpected.  If you are stepping using a debugger you may miss an
-unexpected excursion completely.  Logging the excursion makes it quickly
-visible.
+I personally use this volume of logging quite a bit when I am presented with 
+a problem and I have no idea where things are going wrong.  I can follow the 
+progress of the code quite easily without having to set breakpoints and step 
+through code in a debugger.  When I have a general idea about what is going 
+wrong, I transition into a debugger for fine-grained examination of the 
+problem.  This kind of output can be especially useful when your script does 
+something completely unexpected.  If you are stepping using a debugger you
+may miss an unexpected excursion completely.  Logging the excursion makes it
+quickly visible.
 
 @node Adding Logging to your Code
 @subsection Adding Logging to your Code
 @cindex NS_LOG
 You can add new logging to your simulations by making calls to the log 
-component via several macros.  Let's do so in the @code{first.cc} script we
+component via several macros.  Let's do so in the @code{myfirst.cc} script we
 have in the @code{scratch} directory.
 
 Recall that we have defined a logging component in that script:
@@ -357,43 +355,56 @@
 setting the @code{NS_LOG} environment variable to the various levels.  Let's
 go ahead add some logging to the script.  The macro used to add an 
 informational level log message is @code{NS_LOG_INFO}.  Go ahead and add one 
-just before we start creating the nodes that tells you that the script is 
+(just before we start creating the nodes) that tells you that the script is 
 ``Creating Topology.''  This is done as in this code snippet,
 
+Open @code{scratch/myfirst.cc} in your favorite editor and add the line,
+
 @verbatim
   NS_LOG_INFO ("Creating Topology");
 @end verbatim
 
+right before the lines,
+
+@verbatim
+  NodeContainer nodes;
+  nodes.Create (2);
+@end verbatim
+
 Now build the script using waf and clear the @code{NS_LOG} variable to turn 
 off the torrent of logging we previously enabled:
 
 @verbatim
-  ~/repos/ns-3-dev > export NS_LOG=
+  ./waf
+  export NS_LOG=
 @end verbatim
 
-Now, if you run the script, you will not see your new message since its 
-associated logging component (@code{FirstScriptExample}) has not been enabled.
-In order to see your message you will have to enable the 
-@code{FirstScriptExample} logging component with a level greater than or equal
-to @code{NS_LOG_INFO}.  If you just want to see this particular level of 
-logging, you can enable it by,
+Now, if you run the script, 
 
 @verbatim
-  ~/repos/ns-3-dev > export NS_LOG=FirstScriptExample=info
+  ./waf --run scratch/myfirst
+@end verbatim
+
+you will @emph{not} see your new message since its associated logging 
+component (@code{FirstScriptExample}) has not been enabled.  In order to see your
+message you will have to enable the @code{FirstScriptExample} logging component
+with a level greater than or equal to @code{NS_LOG_INFO}.  If you just want to 
+see this particular level of logging, you can enable it by,
+
+@verbatim
+  export NS_LOG=FirstScriptExample=info
 @end verbatim
 
 If you now run the script you will see your new ``Creating Topology'' log
 message,
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run scratch/first
-  Entering directory `/home/craigdo/repos/ns-3-dev/build'
-  Compilation finished successfully
+  Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+  Build finished successfully (00:00:00)
   Creating Topology
   Sent 1024 bytes to 10.1.1.2
   Received 1024 bytes from 10.1.1.1
   Received 1024 bytes from 10.1.1.2
-  ~/repos/ns-3-dev >
 @end verbatim
 
 @c ========================================================================
@@ -428,30 +439,28 @@
 
 This simple two line snippet is actually very useful by itself.  It opens the
 door to the @command{ns-3} global variable and attribute systems.  Go ahead 
-and add that two lines of code to the @code{first.cc} script at the start of 
-@code{main}.  Go ahead and build the script and run it, but ask the script 
+and add that two lines of code to the @code{scratch/first.cc} script at the 
+start of @code{main}.  Go ahead and build the script and run it, but ask the script 
 for help in the following way,
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run "scratch/first --PrintHelp"
+  ./waf --run "scratch/myfirst --PrintHelp"
 @end verbatim
 
-This will ask Waf to run the @code{scratch/first} script and pass the command
+This will ask Waf to run the @code{scratch/myfirst} script and pass the command
 line argument @code{--PrintHelp} to the script.  The quotes are required to 
 sort out which program gets which argument.  The command line parser will
 now see the @code{--PrintHelp} argument and respond with,
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run ``scratch/first --PrintHelp''
-  Entering directory `/home/craigdo/repos/ns-3-dev/build'
-  Compilation finished successfully
+  Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+  Build finished successfully (00:00:00)
   --PrintHelp: Print this help message.
   --PrintGroups: Print the list of groups.
   --PrintTypeIds: Print all TypeIds.
   --PrintGroup=[group]: Print all TypeIds of group.
   --PrintAttributes=[typeid]: Print all attributes of typeid.
   --PrintGlobals: Print the list of globals.
-  ~/repos/ns-3-dev >
 @end verbatim
 
 Let's focus on the @code{--PrintAttributes} option.  We have already hinted
@@ -472,7 +481,7 @@
 be @code{ns3::PointToPointNetDevice}.  Let's go ahead and type in,
 
 @verbatim
-  ./waf --run "scratch/first --PrintAttributes=ns3::PointToPointNetDevice"
+  ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointNetDevice"
 @end verbatim
 
 The system will print out all of the attributes of this kind of net device.
@@ -518,24 +527,26 @@
 If you run the script, you should now see the following output,
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run scratch/first
-  Entering directory `/home/craigdo/repos/ns-3-dev/build'
-  Compilation finished successfully
-  0ns UdpEchoServerApplication:UdpEchoServer()
-  1000000000ns UdpEchoServerApplication:StartApplication()
+  Build finished successfully (00:00:00)
+  0s UdpEchoServerApplication:UdpEchoServer()
+  1s UdpEchoServerApplication:StartApplication()
   Sent 1024 bytes to 10.1.1.2
-  2257324218ns Received 1024 bytes from 10.1.1.1
-  2257324218ns Echoing packet
+  2.25732s Received 1024 bytes from 10.1.1.1
+  2.25732s Echoing packet
   Received 1024 bytes from 10.1.1.2
-  10000000000ns UdpEchoServerApplication:StopApplication()
+  10s UdpEchoServerApplication:StopApplication()
   UdpEchoServerApplication:DoDispose()
   UdpEchoServerApplication:~UdpEchoServer()
-  ~/repos/ns-3-dev >
 @end verbatim
 
 Recall that the last time we looked at the simulation time at which the packet
-was received by the echo server, it was at 2.0036864 seconds.  Now it is
-receiving the packet at about 2.257 seconds.  This is because we just dropped
+was received by the echo server, it was at 2.00369 seconds.
+
+@verbatim
+  2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
+@end verbatim
+
+Now it is receiving the packet at 2.25732 seconds.  This is because we just dropped
 the data rate of the @code{PointToPointNetDevice} down to its default of 
 32768 bits per second from five megabits per second.
 
@@ -544,17 +555,18 @@
 the formula implied by the help item:
 
 @verbatim
-  ./waf --run "scratch/first --ns3::PointToPointNetDevice::DataRate=5Mbps"
+  ./waf --run "scratch/myfirst --ns3::PointToPointNetDevice::DataRate=5Mbps"
 @end verbatim
 
 This will set the default value of the @code{DataRate} attribute back to 
-five megabits per second.  To get the original behavior of the script back, 
-we will have to set the speed-of-light delay of the channel.  We can ask the 
-command line system to print out the @code{Attributes} of the channel just 
-like we did the net device:
+five megabits per second.  Are you surprised by the result?  It turns out that
+in order to get the original behavior of the script back, we will have to set 
+the speed-of-light delay of the channel as well.  We can ask the command line 
+system to print out the @code{Attributes} of the channel just like we did for
+the net device:
 
 @verbatim
-  ./waf --run "scratch/first --PrintAttributes=ns3::PointToPointChannel"
+  ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointChannel"
 @end verbatim
 
 We discover the @code{Delay} attribute of the channel is set in the following
@@ -568,7 +580,7 @@
 We can then set both of these default values through the command line system,
 
 @verbatim
-  ./waf --run "scratch/first
+  ./waf --run "scratch/myfirst
     --ns3::PointToPointNetDevice::DataRate=5Mbps
     --ns3::PointToPointChannel::Delay=2ms"
 @end verbatim
@@ -577,19 +589,20 @@
 @code{DataRate} and @code{Delay} in the script:
 
 @verbatim
-  Compilation finished successfully
-  0ns UdpEchoServerApplication:UdpEchoServer()
-  1000000000ns UdpEchoServerApplication:StartApplication()
+  Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+  Build finished successfully (00:00:00)
+  0s UdpEchoServerApplication:UdpEchoServer()
+  1s UdpEchoServerApplication:StartApplication()
   Sent 1024 bytes to 10.1.1.2
-  2003686400ns Received 1024 bytes from 10.1.1.1
-  2003686400ns Echoing packet
+  2.00369s Received 1024 bytes from 10.1.1.1
+  2.00369s Echoing packet
   Received 1024 bytes from 10.1.1.2
-  10000000000ns UdpEchoServerApplication:StopApplication()
+  10s UdpEchoServerApplication:StopApplication()
   UdpEchoServerApplication:DoDispose()
   UdpEchoServerApplication:~UdpEchoServer()
 @end verbatim
 
-Note that the packet is again received by the server at 2.0036864 seconds.  We 
+Note that the packet is again received by the server at 2.00369 seconds.  We 
 could actually set any of the attributes used in the script in this way.  In
 particular we could set the @code{UdpEchoClient} attribute @code{MaxPackets} 
 to some other value than one.
@@ -604,7 +617,7 @@
 like,
 
 @verbatim
-  ./waf --run "scratch/first 
+  ./waf --run "scratch/myfirst 
     --ns3::PointToPointNetDevice::DataRate=5Mbps 
     --ns3::PointToPointChannel::Delay=2ms 
     --ns3::UdpEchoClient::MaxPackets=2"
@@ -619,7 +632,7 @@
 to the @code{main} function.  We'll initialize it to one to match our previous 
 default behavior.  To allow the command line parser to change this value, we
 need to hook the value into the parser.  We do this by adding a call to 
-@code{AddValue}.  Go ahead and change the @code{scratch/first.cc} script to
+@code{AddValue}.  Go ahead and change the @code{scratch/myfirst.cc} script to
 start with the following code,
 
 @verbatim
@@ -646,10 +659,15 @@
 Now if you run the script and provide the @code{--PrintHelp} argument, you 
 should see your new @code{User Argument} listed in the help display.
 
+Try,
+
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run "scratch/first --PrintHelp"
-  Entering directory `/home/craigdo/repos/ns-3-dev/build'
-  Compilation finished successfully
+  ./waf --run "scratch/myfirst --PrintHelp"
+@end verbatim
+
+@verbatim
+  Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+  Build finished successfully (00:00:00)
   --PrintHelp: Print this help message.
   --PrintGroups: Print the list of groups.
   --PrintTypeIds: Print all TypeIds.
@@ -658,23 +676,33 @@
   --PrintGlobals: Print the list of globals.
   User Arguments:
       --nPackets: Number of packets to echo
-  ~/repos/ns-3-dev >
 @end verbatim
 
 If you want to specify the number of packets to echo, you can now do so by
 setting the @code{--nPackets} argument in the command line,
 
 @verbatim
-  ~/repos/ns-3-dev > ./waf --run "scratch/first --nPackets=2"
-  Entering directory `/home/craigdo/repos/ns-3-dev/build'
-  Compilation finished successfully
+  ./waf --run "scratch/myfirst --nPackets=2"
+@end verbatim
+
+You should now see
+
+@verbatim
+  Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+  Build finished successfully (00:00:00)
+  0s UdpEchoServerApplication:UdpEchoServer()
+  1s UdpEchoServerApplication:StartApplication()
   Sent 1024 bytes to 10.1.1.2
-  Received 1024 bytes from 10.1.1.1
+  2.25732s Received 1024 bytes from 10.1.1.1
+  2.25732s Echoing packet
   Received 1024 bytes from 10.1.1.2
   Sent 1024 bytes to 10.1.1.2
-  Received 1024 bytes from 10.1.1.1
+  3.25732s Received 1024 bytes from 10.1.1.1
+  3.25732s Echoing packet
   Received 1024 bytes from 10.1.1.2
-  ~/repos/ns-3-dev >
+  10s UdpEchoServerApplication:StopApplication()
+  UdpEchoServerApplication:DoDispose()
+  UdpEchoServerApplication:~UdpEchoServer()
 @end verbatim
 
 You have now echoed two packets.
@@ -764,17 +792,26 @@
 
 @cindex tracing packets
 Let's just jump right in and add some ASCII tracing output to our 
-@code{first.cc} script.  The first thing you need to do is to add the 
-following code to the script just before the call to @code{Simulator::Run ()}.
+@code{scratch/myfirst.cc} script.  
+
+The first thing you need to do is to add the following include to the top of
+the script just after the GNU GPL comment:
+
+@verbatim
+  #include <fstream>
+@end verbatim
+
+Then, right before the before the call to @code{Simulator::Run ()}, add the
+following lines of code.
 
 @verbatim
   std::ofstream ascii;
-  ascii.open ("first.tr");
+  ascii.open ("myfirst.tr");
   PointToPointHelper::EnableAsciiAll (ascii);
 @end verbatim
 
 The first two lines are just vanilla C++ code to open a stream that will be
-written to a file named ``first.tr.''  See your favorite C++ tutorial if you
+written to a file named ``myfirst.tr.''  See your favorite C++ tutorial if you
 are unfamiliar with this code.  The last line of code in the snippet above
 tells @command{ns-3} that you want to enable ASCII tracing on all 
 point-to-point devices in your simulation; and you want the (provided) trace
@@ -782,32 +819,24 @@
 stream provided. For those familiar with @command{ns-2}, the traced events are
 equivalent to the popular trace points that log "+", "-", "d", and "r" events.
 
-Since we have used a @code{std::ofstream} object, we also need to include the
-appropriate header.  Add the following line to the script (I typically add it
-above the ns-3 includes):
-
-@verbatim
-  #include <fstream>
-@end verbatim
-
 You can now build the script and run it from the command line:
 
 @verbatim
-  ./waf --run scratch/first
+  ./waf --run scratch/myfirst
 @end verbatim
 
-@cindex first.tr
-Just as you have seen previously, you may see some messages from Waf and then
-the ``Compilation finished successfully'' with some number of messages from 
+@cindex myfirst.tr
+Just as you have seen many times before, you will see some messages from Waf and then
+the ``Build finished successfully'' with some number of messages from 
 the running program.  
 
-When it ran, the program will have created a file named @code{first.tr}.  
+When it ran, the program will have created a file named @code{myfirst.tr}.  
 Because of the way that Waf works, the file is not created in the local 
 directory, it is created at the top-level directory of the repository by 
 default.  If you want to control where the traces are saved you can use the 
 @code{--cwd} option of Waf to specify this.  We have not done so, thus we 
 need to change into the top level directory of our repo and take a look at 
-the ASCII trace file @code{first.tr} in your favorite editor.
+the ASCII trace file @code{myfirst.tr} in your favorite editor.
 
 @subsubsection Parsing Ascii Traces
 @cindex parsing ascii traces
@@ -844,7 +873,7 @@
   03 ns3::PppHeader (
   04   Point-to-Point Protocol: IP (0x0021)) 
   05   ns3::Ipv4Header (
-  06     tos 0x0 ttl 64 id 0 offset 0 flags [none] 
+  06     tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none] 
   07     length: 1052 10.1.1.1 > 10.1.1.2)
   08     ns3::UdpHeader (
   09       length: 1032 49153 > 9) 
@@ -917,7 +946,7 @@
 
 The trace source namespace entry (reference 02) has changed to reflect that
 this event is coming from node 1 (@code{/NodeList/1}) and the packet reception
-trace source (@code{/Rx}).  It should be quite easy for you to follow the 
+trace source (@code{/MacRx}).  It should be quite easy for you to follow the 
 progress of the packet through the topology by looking at the rest of the 
 traces in the file.
 
@@ -937,54 +966,54 @@
 The code used to enable pcap tracing is a one-liner.  
 
 @verbatim
-  PointToPointHelper::EnablePcapAll ("first");
+  PointToPointHelper::EnablePcapAll ("myfirst");
 @end verbatim
 
 Go ahead and insert this line of code after the ASCII tracing code we just 
-added to @code{scratch/first.cc}.  Notice that we only passed the string
-``first,'' and not ``first.pcap'' or something similar.  This is because the 
+added to @code{scratch/myfirst.cc}.  Notice that we only passed the string
+``myfirst,'' and not ``myfirst.pcap'' or something similar.  This is because the 
 parameter is a prefix, not a complete file name.  The helper will actually 
 create a trace file for every point-to-point device in the simulation.  The 
 file names will be built using the prefix, the node number, the device number
  and a ``.pcap'' suffix.
 
-In our example script, we will eventually see files named ``first-0-0.pcap'' 
-and ``first.1-0.pcap'' which are the pcap traces for node 0-device 0 and 
+In our example script, we will eventually see files named ``myfirst-0-0.pcap'' 
+and ``myfirst.1-0.pcap'' which are the pcap traces for node 0-device 0 and 
 node 1-device 0, respectively.
 
 Once you have added the line of code to enable pcap tracing, you can run the
 script in the usual way:
 
 @verbatim
-  ./waf --run scratch/first
+  ./waf --run scratch/myfirst
 @end verbatim
 
 If you look at the top level directory of your distribution, you should now
-see three log files:  @code{first.tr} is the ASCII trace file we have 
-previously examined.  @code{first-0-0.pcap} and @code{first-1-0.pcap}
+see three log files:  @code{myfirst.tr} is the ASCII trace file we have 
+previously examined.  @code{myfirst-0-0.pcap} and @code{myfirst-1-0.pcap}
 are the new pcap files we just generated.  
 
 @subsubsection Reading output with tcpdump
 @cindex tcpdump
 The easiest thing to do at this point will be to use @code{tcpdump} to look
-at the @code{pcap} files.  Output from dumping both files is shown below:
+at the @code{pcap} files.  
 
 @verbatim
-  ~/repos/ns-3-dev > /usr/sbin/tcpdump -r first-0-0.pcap -nn -tt
-  reading from file first-0-0.pcap, link-type PPP (PPP)
+  tcpdump -nn -tt -r myfirst-0-0.pcap
+  reading from file myfirst-0-0.pcap, link-type PPP (PPP)
   2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, length 1024
   2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 1024
-  ~/repos/ns-3-dev > /usr/sbin/tcpdump -r first-1-0.pcap -nn -tt
-  reading from file first-1-0.pcap, link-type PPP (PPP)
+
+  tcpdump -nn -tt -r myfirst-1-0.pcap
+  reading from file myfirst-1-0.pcap, link-type PPP (PPP)
   2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, length 1024
   2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 1024
-  ~/repos/ns-3-dev >
 @end verbatim
 
-You can see in the dump of ``first-0.0.pcap'' (the client device) that the 
+You can see in the dump of @code{myfirst-0.0.pcap} (the client device) that the 
 echo packet is sent at 2 seconds into the simulation.  If you look at the
-second dump (of ``first-1-0.pcap'') you can see that packet being received
-at 2.257324 seconds.  You see the packet being echoed at 2.257324 seconds
+second dump (@code{first-1-0.pcap}) you can see that packet being received
+at 2.257324 seconds.  You see the packet being echoed back at 2.257324 seconds
 in the second dump, and finally, you see the packet being received back at 
 the client in the first dump at 2.514648 seconds.