Re: wierd dsl performance with -CURRENT

In the last episode (Jul 09), Kenneth Culver said:
> > In the last episode (Jul 09), Kenneth Culver said:
> > > > look of any large values in the timestamps and see if there is
> > > > anything before that indicates a lost packet or a re-ordered one or
> > > > something (or a retransmitted ack)
> > > >
> > > > The key is to find the gap in the arriving packets and figure out
> > > > what caused it..
> > > >
> > > Alright, I'll have to do this later this evening, don't have time
> > > right now. Thanks for the help though.
> >
> > Tcptrace is great for this; the tsg output graph will mark out-of-order
> > packets and duplicate acks for you.
> >
> Alright, I used this and got a bunch of xpl graphs, but I'm not really
> sure what I'm looking at or for. The only graph I really understand is the
> d2c_tput.xpl, which is the thruput of the ftp data connection from
> ftp2.freebsd.org to my machine. I have posted the xpl's, along with the
> binary tcpdump output used to create the graphs. I've also posted the
> ascii output of the same download. All of these are posted at
> http://www.glue.umd.edu/~culverk/
> 
> the graphs are *.xpl, the binary output is tcpdump.out, and the ascii is
> tcpdump.ascii.

I don't see anything majorly wrong here..

>   2: kenshin:49179 - ftp2.freebsd.org:58751 (c2d)  717> 1022<  (complete)

This is the data transfer, so the d2c_* plots are the interesting ones
(they graph the traffic from ftp2 to you).  If you load up
d2c_tput.xpl, you can see that your throughput averaged ~164K/s for
almost the entire time.  The red line is the short-term average, and
you can see there were four dips, corresponding to packet loss.  Flip
over to the d2c_tsg.xpl plot, which graphs the sent packets, ACKs, and
the receive window.  At 21:52:32.8, it looks like four consecutive
packets were dropped.  Luckily, the packets were resent quickly, and
transmission resumed at full speed.  Dips 3 and 4 look the same.  Dip 2
has an extra .2 second delay for some reason.  It looks like fast
restransmit kicked in on all three dips, but for some reason it didn't
recover fast enough on #2.  A TCP guru will have to tell you what to do
next...

-- 
	Dan Nelson
	dnelson_at_allantgroup.com