From: Dan Goetzman (dgoetzma@bmc.com)
Date: Thu Jan 15 2004 - 10:39:13 EST
I was not able to resolve this issue, but it appears we at least
understand the problem.
A recap...
NFS server = Tru64/TruCluster server(5.1A+pk5) using (2) ES40's, gigabit
attached.
NFS clients = various Tru64 5.1A and 5.1B on older alpha's, 100BT attached.
NFS slow on these clients, NFS server not responding and then NFS server
OK messages repeat in syslog.
The interesting part is that the Tru64 clients mount (via automounter)
using NFSV3, UDP. The server offers a NFS r/w buffer size of 49152 and
the Tru64 client decides "Sure, I can do that". Other clients seem to
trim back and use 32K (or less). Seems to work if the Tru64 client is
fast enough. The old and slow Tru64 alpha systems do not run well at
all. The server apparently is over running the client and IP packets are
dropped. The large r/w size creates a burst of many IP packets and the
client is overrun and packets dropped. NFS UDP starts it's timeout
retransmission algorithms and all slows way down (like stopped for a
short time). NFS UDP does not like networks that drop packets. A well
known issue.
The dropped packets can be confirmed on the client by running "netstat
-s" and observing the "fragments dropped after timeout" counter. Any
attempt to tune seems to not help. I was able to confirm that the
udp_sendspace and udp_recvspace do NOT have any effect on NFS on Tru64
(as stated in the tuning docs for Tru64).
A manual mount with the nfs options set to mount "tcp", OR the r/w size
set much lower (like 8192 or 1024 even) when using udp works OK. So,
what I really need to do if I want to use automounter (and we do) is
change the default mount options used by automounter JUST ON THE SLOW
clients. Apparently there is no way to do that.
I may consider putting a 100BT card in the server and have the slow
clients use that interface on the server so the pipe will be 100BT to
100BT instead of the 1000BT to 100BT. Best I can do I guess.
That is all. Thanks to all that responded and helped confirm and/or
provide new info on this.
Dan Goetzman
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:48 EDT