Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Oct 1999 22:58:22 -0700
From:      "Craig Critchley" <craigc@nwlink.com>
To:        "Garrett Wollman" <wollman@khavrinen.lcs.mit.edu>, <net@FreeBSD.ORG>
Subject:   Re: FTP Net Performance
Message-ID:  <216001bf2109$718c8500$0201010a@fuzzer.com>
References:  <1df701bf1f84$32751020$0201010a@fuzzer.com><199910261606.MAA83232@khavrinen.lcs.mit.edu><1f6601bf200e$c8e476b0$0201010a@fuzzer.com> <199910271525.LAA87666@khavrinen.lcs.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Ok, all the extra stuff is out of the machine, so it's down to motherboard,
video card, and netcard.

Still getting the same lousy throughput.

I took another look at tcpdump, not the graphs, but the data itself.  It
appears that Windows is sort of behind in its acks and eventually acks twice
with the same sequence number.  When this happens, everybody holds their
breath for a second and a half, then the BSD machine resends the
double-acked packet.  This is my first tcpdump analysis effort, so if I have
misinterpreted something, please let me know.  I just ran tcpdump with no
switches after setting up BPF and captured the output.

If this rings any bells with anyone, I would love to hear your theory.
Unfortunately, I only have the one BSD machine, so I can't easily test
whether this is restricted to Windows clients.  I'm not enough of a TCP
expert to know whether the sequence below breaks the rules.

Here's a representative sample.  I've trimmed down the timestamps and
machine names and took off the window and flag information.  The windows on
both ends were constant.  There were no other packets between these, TCP or
otherwise.

#the server sends some data:
17.55 fuzz.ftp-data > win.1786: . 281781:283241(1460) ack 1
17.55 fuzz.ftp-data > win.1786: . 283241:284701(1460) ack 1
17.55 fuzz.ftp-data > win.1786: . 284701:286161(1460) ack 1

#Windows acks the middle one
17.55 win.1786 > fuzz.ftp-data: . ack 283241
17.55 fuzz.ftp-data > win.1786: . 286161:287621(1460) ack 1

#Windows acks the third
17.55 win.1786 > fuzz.ftp-data: . ack 284701
17.55 fuzz.ftp-data > win.1786: . 287621:289081(1460) ack 1

#Hmm... Windows ack's the same number!
17.55 win.1786 > fuzz.ftp-data: . ack 284701

#Oh no!  Big delay, then resend of double acked packet.
19.05 fuzz.ftp-data > win.1786: . 284701:286161(1460) ack 1

                        ...Craig

From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
>
> TCP performance is going to suck with that level of packet loss.  TCP
> only works well with less than about 1% packet loss; if you're losing
> 15%, that explains what's going on.
>
> -GAWollman
>
> --
> Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the
same
> wollman@lcs.mit.edu  | O Siem / The fires of freedom
> Opinions not those of| Dance in the burning flame
> MIT, LCS, CRS, or NSA|                     - Susan Aglukark and Chad
Irschick
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
>



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?216001bf2109$718c8500$0201010a>