From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: can't get request slot, write timeout Date: 12 Aug 2002 20:47:52 +0200 Sender: nfs-admin@lists.sourceforge.net Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kenneth Howlett , nfs@lists.sourceforge.net Return-path: Received: from pat.uio.no ([129.240.130.16]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17eKEQ-0002CG-00 for ; Mon, 12 Aug 2002 11:47:58 -0700 To: Bogdan Costescu In-Reply-To: Errors-To: nfs-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Unsubscribe: , List-Archive: >>>>> " " == Bogdan Costescu writes: >> In the FAQ it says that tcp is faster than udp on congested >> networks. I think the same effect could be achieved by using >> udp with a small rsize/wsize. > That's debatable. TCP is supposed to handle these cases well > 'cause that's what it was designed for. The NFS client over UDP > just recently got better behaviour through Trond's efforts, but > having it perform just as over TCP would probably mean > re-implementing TCP within NFS. Eh, now Trond can shoot me :-) No, I agree 100% with what Bogdan said above. I wasn't aware that you'd seen better behaviour with the last set of patches. Feedback is always welcome - particularly now when I'm trying to work out exactly what we should aim to get into kernel 2.4.20! The most likely explanation for the improved behaviour would be that those patches implement most of the known TCP performance tricks for congested networks. The only TCP trick we cannot implement is that of sending messages of length > 1.5k without using fragmentation. That again means that if 1 fragment is lost, we have to resend 32k (or 8k or whatever the r/wsize is set to) rather than only the 1.5k that was actually missing... The above is why the NFSv4 protocol explicitly specifies that NFS over TCP *must* be supported, whereas NFS over UDP will only be optional (In practice most implementations are likely to support both). Cheers, Trond ------------------------------------------------------- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs