Hi, Dear all,
Summary time = problem solved :-)
The orignal problem was that one NFS server had very slow response
time with some machines. A primitive ftp test revealed that, for a
5Mbytes file, it took forever and eventually we got netin:Borken pine message.
We (hardwire) upgraded the wiring from a voice cable dated back to 70's
to a much more greener 10baseT level5 cable. It makes a big difference
after the re-wiring. The system works happily now.
Here are the suggestions I got from replies. I tried some of them, but
not all. Wait for your chance:
1. Use nfsstat command, high badcalls, retrans and timeout numbers hints
unreliable network connection.
2. Fiddle with NFS mount options: increasing timeo/retrans
reducing rsize/wsize, if nfsstat shows fishy statistics.
3. Increase number of nfsd/biod running on the server side.
4. Use etherman, nfstop(?), sniffers flood ping, etherfind, snoop, etc.. to help
isolate problems.
5. Check if the SQE switch on the transceiver that connected to a TP hub
is turned off (ususally should be off).
6. A prestoserve disk accelerator can cause simmilary problem; have the
latest software/hardware for it.
My thanks to:
sanford@lsil.com (Sanford Whitehouse)
kuhn@gkss.de (Hermann Kuhn)
Andrew J Cole <A.J.Cole@cbl.leeds.ac.uk>
"Richard Wong" <rnw@math.Princeton.EDU>
David Keegel <djk@cyber.com.au>
Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
bobr@houston.wireline.SLB.COM ( Bob Reardon )
"Brian T. Wightman" <wightman@sol.acs.uwosh.edu>
Xueshan Feng
-- Susan Feng (aka. Xueshan Feng) | Tel.: (510) 643 5048 Unix System Manager | Email: sf@ced.berkeley.edu College of Environmental Design | Fax: (510) 642 7560 UC Berkeley, CA 94705 | Voicemail: (510) 643 5048
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:15 CDT