--- a/doc/tutorial/tracing.texi Tue Oct 20 10:05:57 2009 -0700
+++ b/doc/tutorial/tracing.texi Tue Oct 20 10:45:12 2009 -0700
@@ -1127,9 +1127,9 @@
Here you see that the @code{TracedValue} is templated, of course. In the simple
example case at the start of the section, the typename is int32_t. This means
-that the member variable being traced (@code>m_v} in the private section of the
+that the member variable being traced (@code{m_v} in the private section of the
class) will be an @code{int32_t m_v}. The @code{Set} method will take a
-@code{const uint32_t &v} as a parameter. You should now be able to understand
+@code{const int32_t &v} as a parameter. You should now be able to understand
that the @code{Set} code will fire the @code{m_cb} callback with two parameters:
the first being the current value of the @code{TracedValue}; and the second
being the new value being set.
@@ -1146,7 +1146,7 @@
@verbatim
void
- MyCallback (uint32_t oldValue, uint32_t newValue)
+ MyCallback (int32_t oldValue, int32_t newValue)
{
...
}
@@ -1246,7 +1246,7 @@
@subsection What Script to Use?
It's always best to try and find working code laying around that you can
-modify, rather than starting from scratch. So the fist order of business now
+modify, rather than starting from scratch. So the first order of business now
is to find some code that already hooks the ``CongestionWindow'' trace source
and see if we can modify it. As usual, grep is your friend:
@@ -1277,7 +1277,7 @@
you will find that it looks just like an @code{ns-3} script. It turns out that
is exactly what it is. It is a script run by the test framework, so we can just
pull it out and wrap it in @code{main} instead of in @code{DoRun}. Rather than
-walk through this step, by step, we have provided the file that results from
+walk through this, step, by step, we have provided the file that results from
porting this test back to a native @code{ns-3} script --
@code{examples/tutorial/fifth.cc}.
@@ -1287,7 +1287,7 @@
must understand before using any kind of @code{Attribute}: you must ensure
that the target of a @code{Config} command exists before trying to use it.
This is no different than saying an object must be instantiated before trying
-to call it, Although this may seem obvious when stated this way, it does
+to call it. Although this may seem obvious when stated this way, it does
trip up many people trying to use the system for the first time.
Let's return to basics for a moment. There are three basic time periods that
@@ -1300,7 +1300,7 @@
executing the simulation, @code{Simulator::Run} will return control back to
the @code{main} function. When this happens, the script enters what can be
called ``Teardown Time,'' which is when the structures and objects created
-during setup and taken apart and released,
+during setup and taken apart and released.
Perhaps the most common mistake made in trying to use the tracing system is
assuming that entities constructed dynamically during simulation time are
@@ -1314,7 +1314,7 @@
tries to do anything (what would happen if it tried to connect to a node
that didn't exist yet during configuration time). The answer to this
issue is to 1) create a simulator event that is run after the dynamic object
-is created and hook the trace when that event is executedl or 2) create the
+is created and hook the trace when that event is executed; or 2) create the
dynamic object at configuration time, hook it then, and give the object to
the system to use during simulation time. We took the second approach in
the @code{fifth.cc} example. This decision required us to create the
@@ -1323,7 +1323,7 @@
@subsection A fifth.cc Walkthrough
-Now, let's take a look at the example program we constructed by disecting
+Now, let's take a look at the example program we constructed by dissecting
the congestion window test. Open @code{examples/tutorial/fifth.cc} in your
favorite editor. You should see some familiar looking code:
@@ -1551,7 +1551,7 @@
The following @code{Connect} will do what is required to establish a connection
with the TCP at @code{Address} m_peer. It should now be clear why we need to defer
a lot of this to simulation time, since the @code{Connect} is going to need a fully
-functioning network to comlete. After the @code{Connect}, the @code{Application}
+functioning network to complete. After the @code{Connect}, the @code{Application}
then starts creating simulation events by calling @code{SendPacket}.
The next bit of code explains to the @code{Application} how to stop creating
@@ -1627,7 +1627,7 @@
@end verbatim
Here, you see that @code{ScheduleTx} does exactly that. If the @code{Applciation}
-is running (if @code{StopApplication}) has not been called) it will schedule a
+is running (if @code{StopApplication} has not been called) it will schedule a
new event, which calls @code{SendPacket} again. The alert reader will spot
something that also trips up new users. The data rate of an @code{Application} is
just that. It has nothing to do with the data rate of an underlying @code{Channel}.
@@ -1656,8 +1656,8 @@
could load the resulting output into a graphics program (gnuplot or Excel) and
immediately see a nice graph of the congestion window behavior over time.
-We added a new trace sink to show where are dropped. We are going to add an
-error model to this code also, so we wanted to demonstrate this working.
+We added a new trace sink to show where packets are dropped. We are going to
+add an error model to this code also, so we wanted to demonstrate this working.
@verbatim
static void
@@ -1700,7 +1700,7 @@
This creates two nodes with a point-to-point channel between them, just as
shown in the illustration at the start of the file.
-The next few lines of code show somthing new. If we trace a connection that
+The next few lines of code show something new. If we trace a connection that
behaves perfectly, we will end up with a monotonically increasing congestion
window. To see any interesting behavior, we really want to introduce link
errors which will drop packets, cause duplicate ACKs and trigger the more
@@ -1714,7 +1714,7 @@
Ptr<RateErrorModel> em = CreateObjectWithAttributes<RateErrorModel> (
"RanVar", RandomVariableValue (UniformVariable (0., 1.)),
"ErrorRate", DoubleValue (0.00001));
- devices.Get (0)->SetAttribute ("ReceiveErrorModel", PointerValue (em));
+ devices.Get (1)->SetAttribute ("ReceiveErrorModel", PointerValue (em));
@end verbatim
The above code instantiates a @code{RateErrorModel} Object. Rather than
@@ -1856,17 +1856,17 @@
@verbatim
./waf --run fifth
- Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
+ Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
- 'build' finished successfully (0.525s)
- 1.21397 1072
- 1.22755 1608
- 1.24114 2144
+ 'build' finished successfully (0.684s)
+ 1.20919 1072
+ 1.21511 1608
+ 1.22103 2144
...
- 1.35211 8576
- 1.36136 9112
- 1.37061 9648
- RxDrop at 1.3729
+ 1.2471 8040
+ 1.24895 8576
+ 1.2508 9112
+ RxDrop at 1.25151
...
@end verbatim
@@ -1889,7 +1889,7 @@
pretty pictures:
@verbatim
- gnuplot> set terminal png size 1024,768
+ gnuplot> set terminal png size 640,480
gnuplot> set output "cwnd.png"
gnuplot> plot "cwnd.dat" using 1:2 title 'Congestion Window' with linespoints
gnuplot> exit
--- a/examples/tutorial/fifth.cc Tue Oct 20 10:05:57 2009 -0700
+++ b/examples/tutorial/fifth.cc Tue Oct 20 10:45:12 2009 -0700
@@ -179,7 +179,7 @@
nodes.Create (2);
PointToPointHelper pointToPoint;
- pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("1Mbps"));
+ pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));
pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));
NetDeviceContainer devices;
@@ -208,7 +208,7 @@
ns3TcpSocket->TraceConnectWithoutContext ("CongestionWindow", MakeCallback (&CwndChange));
Ptr<MyApp> app = CreateObject<MyApp> ();
- app->Setup (ns3TcpSocket, sinkAddress, 1040, 1000, DataRate ("5Mbps"));
+ app->Setup (ns3TcpSocket, sinkAddress, 1040, 1000, DataRate ("1Mbps"));
nodes.Get (0)->AddApplication (app);
app->Start (Seconds (1.));
app->Stop (Seconds (20.));
