Date: Mon, 15 Apr 1996 20:59:52 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: NFS timing (Was: Just how stable is current) Message-ID: <199604151859.UAA12685@uriah.heep.sax.de> In-Reply-To: <199604150856.SAA14153@orion.devetir.qld.gov.au> from "Stephen McKay" at Apr 15, 96 06:55:59 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Stephen McKay wrote: > 1) NFS problem: My January 9 kernel will work properly as a client with any > server using 8Kb max size UDP connections. More recent kernels won't. I > get severe performance degradation that I assume is from lots of retries and > timeouts, even though I can't find them in nfsstat. Many processes hang > for long periods in sbwait, nfsrcvlk and similar network states. > > Ok, overruns are a common problem with PC network cards, especially in slow > machines. However, setting the maximum size to 1Kb does not cure the > problem (or maybe moves the problem elsewhere). Switching to TCP transport > produced a total cure, but is not available on all servers. This seems to be identical with the observation that all recent SNAPs have increased timing problems (up to totally unusable) when installing over NFS. For me, it required me to revert to 1 KB blocksize (even though the NFS server is also only a lame 8-bit 3c503), and we've got at least one installation problem report where the installation totally starved at the first lengthy file, even _with_ the ``NFS slow'' option. I really wonder what might have caused this change. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604151859.UAA12685>