From owner-freebsd-current Wed Dec 22 20:12:58 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5330514F2A for ; Wed, 22 Dec 1999 20:12:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA15384; Wed, 22 Dec 1999 20:12:53 -0800 (PST) (envelope-from dillon) Date: Wed, 22 Dec 1999 20:12:53 -0800 (PST) From: Matthew Dillon Message-Id: <199912230412.UAA15384@apollo.backplane.com> To: "B. Scott Michel" Cc: Jonathan Lemon , Brad Knowles , Joe Abley , Poul-Henning Kamp , Garrett Wollman , freebsd-current@freebsd.org Subject: Re: Odd TCP glitches in new currents References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :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