:
: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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
