Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!decwrl!uunet!pcserver2!kdenning From: kdenning@pcserver2.naitc.com (Karl Denninger) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: PC-NFS performance Summary: Get a client NFS that is reasonable, and use a good server Message-ID: <1991Mar7.182104.12988@pcserver2.naitc.com> Date: 7 Mar 91 18:21:04 GMT References: <448@newmedia.UUCP> <1991Mar1.151130.6998@unipalm.uucp> Organization: AC Nielsen, Bannockburn IL USA Lines: 64 In article <1991Mar1.151130.6998@unipalm.uucp> ian@unipalm.uucp (Ian Phillipps) writes: >jim@newmedia.UUCP (Jim Beveridge) writes: > >>I am running PC-NFS v3.0.1 hooked up to a Sun 3/60 server. >>The problem is that the write performance is awful -- it does >>pretty well reading, ... > >>Is this just a problem with PC-NFS? Is there a parameter that >>I didn't tune? How can I adjust rsize and wsize? Yes, it's a problem with PC/NFS. It's not nearly as bad with B&W NFS... >The problem (flames coming in if I'm wrong, no doubt) is that NFS is a >synchronous protocol, so the write has to be complete before the NFS call is >finished. For a Unix client, this doesn't matter, since the kernel handles >the asynchonosity (is that the word?) itself. This much is true.... >BUT - DOS is also synchronous, so you have a wait on your hands. >As far as I know, the write size is fixed at 1K. Not true at all! B&W NFS can use up to 1/2 the card's buffer RAM as the "write size". This is usually 4k. 4k blocks are MUCH faster than 1K ones. For reads the difference is much less dramatic, but still visible. However, some systems that route packets (like Suns) can't always deal with 4k writes. Thus, if you have to go through a router, you might have to run a smaller size. But it IS tunable to any size you wish at the time of the disk mount. >Some other implementations of NFS client for DOS get round this problem by >de-synchronising themselves - the only one I know that does this is >Interdrive 1.1 from FTP. > >The other alternative is to add a Prestoserve board (from Legato >Systems) to your Sun, which is specifically aimed at this problem: it's >an intelligent disk cache which acknowledges the NFS write before the >info actually hits the disk, and retains security by holding the disk >info in non-volatile RAM. The other solution is to buy a reasonable server. Like the MIPS 3260 series. They're much faster at NFS serving than the typical Sparc systems, and don't have the bottlenecks in the NFS server code. The MIPS Magnums smoke Sparcstations as NFS servers all day long, and cost less too... With a reasonable server and client implementation you can beat LanMan performance. This is another one of those "no way can your PCNFS network be that fast" falsehoods. I do it here all day long. It's fast, solid, and tastes great. It's my job to make it all work. And it does. Very well, very fast, and very productive. I'd rather run this setup than anything based on Novell or 3COM software. It's easier to work with and MUCH more flexible. And they said "open networks" couldn't beat "closed proprietary ones"..... -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.