From owner-freebsd-stable Fri Apr 6 2:55:18 2001 Delivered-To: freebsd-stable@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 009E137B43E for ; Fri, 6 Apr 2001 02:55:16 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 6 Apr 2001 10:55:15 +0100 (BST) To: Cejka Rudolf Cc: freebsd-stable@freebsd.org, iedowse@maths.tcd.ie Subject: Re: About NFS and NFSv3/UDP errors with iozone In-Reply-To: Your message of "Fri, 06 Apr 2001 09:22:43 +0200." <20010406092243.A47655@dcse.fee.vutbr.cz> Date: Fri, 06 Apr 2001 10:55:14 +0100 From: Ian Dowse Message-ID: <200104061055.aa15749@salmon.maths.tcd.ie> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20010406092243.A47655@dcse.fee.vutbr.cz>, Cejka Rudolf writes: > ># ./run.sh >NFS setattr failed for server kunhuta: error 5 (RPC: Timed out) >fdopen: Connection timed out > >Please, is it reproducible on the other sites? >Or is it a natural behavior because of UDP protocol use? If this is what I think it is, then you could work around it by either adding "-d,-t2" to the mount options, or don't use the "soft" option. Normally (without "-d") NFS maintains round-trip-time estimates for different types of operations. It uses these measured times to dynamically adjust the timeout for requests. However, because write operations have such a large variance in completion time, it can occasionally time out a request when the server is just very slow to respond. This might happen if a number of requests completed very quickly (say 1ms), and then due to disk activity on the server, one request takes much longer (say 1s). The "-d" (dumbtimer) option switches off the dynamic retransmit timeout algorithm. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message