From: Joshua Blanton (firstname.lastname@example.org)
Date: Wed, 29 Sep 2004 01:01:23 -0400 From: Joshua Blanton <email@example.com> Subject: Re: tcptrace-bugs Using tcptrace with ns traces Message-ID: <20040929050123.GA25128@jtb.ipx.ath.cx>
Bharath Bhushan wrote:
> Actually I am using the FullTcp Agent in ns. I am running a simple
> fulltcp based simulation (tcl file attached with this mail along with
> the trace file). I have not modified ns source code.
> About the flags that you mention for proper processing of ns traces, I
> assume they are tcptrace compilation flags. Am I right here?
> ns version I am using - 2.27
> The traces that I have are the "normal traces" with 14 fields (18 for
> tcp specific traces). I have not worked with the ns "new" traces.
> After applying the patch related to the trace file format recognition
> (sent by Joshua Blanton), the ns trace files are getting recognized
> properly but lots of hardware duplicates are seen in the tcptrace
As Wes said, the hardware duplicates come from having more than just a
sender-side trace (the + packets that the sender sends, and the -
packets from the receiver as they are received by the sender). If you
want to plot all connections in a file, write a simple script that
chooses and endpoint for each connection and filters out the correct
packets to display; you can then generate the corresponding "other
side" (with the senders and receivers reversed) and trace that as well,
if it is useful.
Basically, tcptrace is not smart enough (and I would argue *cannot* be
smart enough, without specifying more information about the simulation
to it) to understand that the multiple instances of one packet are just
that packet propogating across a path. You must filter out all but one
instance of each packet, to avoid getting errors about duplicated
-- Those who beat their swords into plowshares usually end up plowing for those who didn't. -- Ben Franklin
This archive was generated by hypermail 2.1.7 : 09/30/04 EDT