--- a/doc/tutorial/tracing.texi	Thu Oct 08 10:36:58 2009 -0700
+++ b/doc/tutorial/tracing.texi	Thu Oct 08 11:37:29 2009 -0700
@@ -26,29 +26,36 @@
 @section Background
 
 As mentioned in the Using the Tracing System section, the whole point of running
-an @code{ns-3} simulation is to generate output for study.  One has two basic s
-trategies to work with in @code{ns-3}: using generic pre-defined output 
+an @code{ns-3} simulation is to generate output for study.  You have two basic 
+strategies to work with in @code{ns-3}: using generic pre-defined bulk output 
 mechanisms and parsing their content to extract interesting information; or 
-developing your own output mechanisms that convey exactly (and perhaps only) 
-the information you want.
+somehow developing an output mechanism that conveys exactly (and perhaps only) 
+the information wanted.
+
+Using pre-defined bulk output mechansims has the advantage of not requiring any
+changes to @code{ns-3}, but it does require programming.  Often, pcap or NS_LOG
+output messages are gathered during simulation runs and separately run through 
+scripts that use grep, sed or awk to parse the messages and reduce and transform
+the data to a manageable form.  Programs must be written to do the 
+transformation, so this does not come for free.  Of course, if the information
+of interest in does not exist in any of the pre-defined output mechanisms,
+this approach fails.
 
-Using pre-defined output mechansims has the advantage of not requiring any
-changes to @code{ns-3}, but does require programming.  Often, pcap or NS_LOG
-output messages are gathered and run through scripts that use grep, sed or awk
-to parse the messages and reduce and transform the data to a manageable form.
-You do have to write programs to do the transformation, so this does not come
-for free.  Of course, if the information you are interested in does not exist
-in any of the pre-defined output mechanisms, you are stuck.
+If you need to add some tidbit of inforamtion to the pre-defined bulk mechanisms,
+this can certainly be done; and if you use one of the @code{ns-3} mechanisms, 
+you may get your code added as a contribution.
 
-If you develop your own output mechanisms, you trade the programming in grep,
-sed or awk scripts for programming the use of some form of output in ns-3.  This 
-has several important advantages.  First, you can reduce the amount of data
-you have to manage and wade through by only tracing interesting events.  
-Perhaps the most important reason for becoming familiar with this method is
-that you can add the ability to trace any piece of information you want.  You
-will no longer be limited by what the authors of a given model felt was 
-important to trace.  For this reason, we believe that the tracing subsystem 
-is one of the most important mechansisms to understand in @command{ns-3}.
+@code{ns-3} provides another mechanism, called Tracing, that avoids some of the 
+problems inherent in the bulk output mechanisms.  It has several important 
+advantages.  First, you can reduce the amount of data you have to manage by only
+tracing the events of interest to you.  Second, if you use this method, you can 
+control the format of the output directly so you avoid the postprocessing step 
+with sed or awk script.  If you desire, your output can be formatted directly into
+a form acceptable by gnuplot, for example.  You can add hooks in the core which 
+can then be accessed by other users, but which will produce no information unless
+explicitly asked to do so.  For these reasons, we believe that the @code{ns-3>
+Tracing system is the best way to get information out of a simulation and is also
+therefore one of the most important mechansisms to understand in @command{ns-3}.
 
 @subsection Blunt Instruments
 There are many ways to get information out of a program.  The most 
@@ -69,9 +76,9 @@
 @end verbatim
 
 Nobody is going to prevent you from going deep into the core of @code{ns-3} and
-adding print statements.  After all, you have complete control of your own 
-@node{ns-3} branch.  This will probably not turn out to be very satisfactory in
-the long term, though.
+adding print statements.  This is insanely easy to do and, after all, you have 
+complete control of your own @node{ns-3} branch.  This will probably not turn 
+out to be very satisfactory in the long term, though.
 
 As the number of print statements increases in your programs, the task of 
 dealing with the large number of outputs will become more and more complicated.  
@@ -83,18 +90,18 @@
 is using @code{NS_LOG} itself.
 
 We mentioned above that one way to get information out of @code{ns-3} is to 
-parse existing NS_LOG output for interesting information.  However, what happens
-if you discover that some tidbit of information you need is not present in
-existing log output.  You could edit the core of @code{ns-3} and simply add to the 
-output.  This is certainly better than adding print statements since it 
-follows @code{ns-3} coding conventions and could potentially be useful to other
-people as a patch to the existing core.
+parse existing NS_LOG output for interesting information.  If you discover that 
+some tidbit of information you need is not present in existing log output, you 
+could edit the core of @code{ns-3} and simply add your interesting information
+to the output stream.  Now, this is certainly better than adding your own
+print statements since it follows @code{ns-3} coding conventions and could 
+potentially be useful to other people as a patch to the existing core.
 
-If, for example, you wanted to add more logging to the @code{ns-3} TCP socket
-(@code{tcp-socket-impl.cc}) you could just add a new message down in the 
-implementation.  Notice that in TcpSocketImpl::ProcessAction() there is no log 
-message for the @code{ACK_TX} case.  You could simply add one, changing the code 
-from:
+Let's pick a random example.  If you wanted to add more logging to the 
+@code{ns-3} TCP socket (@code{tcp-socket-impl.cc}) you could just add a new 
+message down in the implementation.  Notice that in TcpSocketImpl::ProcessAction()
+there is no log message for the @code{ACK_TX} case.  You could simply add one, 
+changing the code from:
 
 @verbatim
   bool TcpSocketImpl::ProcessAction (Actions_t a)
@@ -129,12 +136,12 @@
       ...
 @end verbatim
 
-This may seem fairly satisfying at first glance, but somthing to consider is that
-you will be writing code to add the @code{NS_LOG} statement and you will also
-have to write code (as in grep, sed or awk scripts) to parse the log output in
-order to isolate and format your information.  This is because even though you
-have some control over what is output by the logging system, you only have control
-down to the log component level.
+This may seem fairly simple and satisfying at first glance, but somthing to
+consider is that you will be writing code to add the @code{NS_LOG} statement 
+and you will also have to write code (as in grep, sed or awk scripts) to parse
+the log output in order to isolate your information.  This is because even 
+though you have some control over what is output by the logging system, you 
+only have control down to the log component level.  
 
 If you are adding code to an existing module, you will also have to live with the
 output that every other developer has found interesting.  You may find that in 
@@ -143,13 +150,22 @@
 may be forced to save huge log files to disk and process them down to a few lines
 whenever you want to do anything.
 
-We consider prints to @code{std::cout} and NS_LOG messages simple ways to get 
-more information out of @code{ns-3}, but they are really quite blunt instruments.
+Since there are no guarantees in @code{ns-3} about the stability of @code{NS_LOG}
+messages, you may also discover that pieces of log output on which you depend 
+disappear or change between releases.  If you depend on the structure of the 
+output, you may find other messages being added or deleted which may affect your
+parsing code.
 
-It is desirable to have a facility that allows one to reach into the core system
-and only get the information required without having to change and recompile the
+For these reasons, we consider prints to @code{std::cout} and NS_LOG messages 
+simple ways to get more information out of @code{ns-3}, but they are really 
+unstable and quite blunt instruments.
+
+It is desirable to have a stable facility using stable APIs that allow one to 
+reach into the core system and only get the information required.  It is
+desirable to be able to do this without having to change and recompile the
 core system.  Even better would be a system that notified the user when an item
-of interest changed or an interesting event happened.
+of interest changed or an interesting event happened so the user doesn't have 
+to actively go poke around in the system looking for things.
 
 The @command{ns-3} tracing system is designed to work along those lines and is 
 well-integrated with the Attribute and Config substems allowing for relatively

--- a/test.py	Thu Oct 08 10:36:58 2009 -0700
+++ b/test.py	Thu Oct 08 11:37:29 2009 -0700
@@ -119,6 +119,7 @@
     ("tutorial/hello-simulator", "True"),
     ("tutorial/second", "True"),
     ("tutorial/third", "True"),
+    ("tutorial/fourth", "True"),
 
     ("udp/udp-echo", "True"),