From: Bharath Bhushan (bharath.bhushan@gmail.com)
Date: 09/29/04
Message-ID: <29683db204092822256537d6ad@mail.gmail.com> Date: Wed, 29 Sep 2004 10:55:53 +0530 From: Bharath Bhushan <bharath.bhushan@gmail.com> Subject: Re: tcptrace-bugs Using tcptrace with ns traces
Hi weddy,
That helped a lot. Thanks.
The only thing I am not able to correlate now is the number of drops
in the trace file and the number of retx shown in tcptrace. Since I am
not using SACK, this is what is expected, maybe.
-- Bharath
On Tue, 28 Sep 2004 10:39:21 -0400, Wesley Eddy <weddy@grc.nasa.gov> wrote:
> On Tue, Sep 28, 2004 at 03:56:44PM +0530, Bharath Bhushan wrote:
> >
> > 2) The final statistics shows lots of duplicates. When I looked at the
> > pread_ns_fulltcp() function, it doesn't seem t care about the
> > different kinds of events happening on a packet. So the
> > enque/deque/recv etc are all recognized as duplicate packets. Is there
> > a way to overcome this?
> >
>
> You want to apply a filter (using awk or equivalent) to grap only the
> relevant events. For example, if you have 3 links in your network, your
> trace file might contain all events on all 3 links, so single segments
> show up dozens of times. For tcptrace, you want to filter out only the
> data segments with sent (+) on the sender's link, and ACKs recieved (r)
> in the opposite direction on that link. That gives you a "sender-side"
> trace, and should satisfy all of tcptrace's algorithmic assumptions.
>
> -Wes
>
>
>
>
This archive was generated by hypermail 2.1.7 : 09/29/04 EDT