Date: Wed, 22 Dec 1999 20:12:53 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "B. Scott Michel" <scottm@CS.UCLA.EDU> Cc: Jonathan Lemon <jlemon@americantv.com>, Brad Knowles <brad@shub-internet.org>, Joe Abley <jabley@patho.gen.nz>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, freebsd-current@freebsd.org Subject: Re: Odd TCP glitches in new currents Message-ID: <199912230412.UAA15384@apollo.backplane.com> References: <Pine.BSF.4.10.9911301923440.686-100000@mordred.cs.ucla.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:There's some oddities in the 3.3 and 3.4 kernels as well -- I've actually
:nailed down the plexicity and speed on both the Accellar and my humble PC,
:and yet, I'm looking at weird TCP lockups from time to time.
:
:Mostly seems to be related to NFSv3, but will also happen when doing
:cvsup. There's no magic number of how many bytes are queued waiting to go
:out the interface. And it seems to be limited to specific connections,
:i.e. an NFS TCP connection can be jammed and yet I can be happily talking
:to cvsup3 doing an update.
If an NFS TCP connection is jammed you can easily determine whether
the problem is NFS or the TCP stack by looking at the netstat -tn output.
'netstat -tn | fgrep tcp' on both the client and server and locate the
NFS tcp connection in question, then see if there is traffic built-up on
it.
If there is input traffic built-up on either the client or server then
NFS isn't reading the socket. But if there is output traffic built-up
(and no input traffic built-up by the receiving end) then the problem is
somewhere in the TCP stack.
---
Well, My problem still persists -- it wasn't the link between my two
switches. I am having the same problem across just about every tcp
connection I make, whether it's over a local switch or a hub and it
doesn't seem to matter what kind of ethernet cards I have either.
I am clueless as to what is going on. It seems to only happen with TCP
connections. I wrote a UDP-based packet loss test program that sends
UDP packets at varying rates and sizes in both directions and figures
out where the loss is occuring, and I get nada. In fact, while its
running in the background I am *still* getting TCP stutters and tcpdump
still shows one machine sending a packet that the other machine never
gets! I have no friggin clue as to why TCP packets fail when UDP packets
don't.
I am beginning to seriously suspect a software problem.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912230412.UAA15384>