Skip site navigation (1)Skip section navigation (2)
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>