jim@newmedia.UUCP (Jim Beveridge) (02/27/91)
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, but trying to do something like a compile over the net is pretty much hopeless. Checking NFSSTAT shows that there are no problems with retries or timeouts. I do, however, hear the hard disk thrashing away quite a bit on each write. Much more so than if I were trying to do an NFS write from another Sun. Is this just a problem with PC-NFS? Is there a parameter that I didn't tune? How can I adjust rsize and wsize? Thanks, Jim
ian@unipalm.uucp (Ian Phillipps) (03/01/91)
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? 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. 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. 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.
kdenning@pcserver2.naitc.com (Karl Denninger) (03/08/91)
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.
robin@gradient.gradient.com (Dr R.P. Alston) (04/18/91)
We have PC-NFS (FTP software) on a 25Mhz 386 and I was wondering if
anyone has any advice about why its performance is so bad. It reaches
a point that we simply can't use NFS mounted directories for normal
work, just for occasional backups when we have a free hour or so. I
appreciate that this is hardly a quantitative measure of performance
but it really can't be as its supposed to be. Is there something
simple we probably missed or is this a known issue. Are there other
PC-NFS suppliers that people think give better performance. Its
definitely not the server. This is a 25Mhz 386 running SVR4 and we get
fine results to and from Suns, Intergraphs, and even other 386 boxes running
SCO Open Desktop .
I appologize in advance if I am raising a much discussed issue, if
thats so could someone mail a summary?
Please, this is not intended as an indictment of FTP software, we are
very pleased with the rest of their product.
Oh yes, please e-mail since I'm afraid we don't get this newsgroup.
Hardware 25Mhz 386 with 4Mb, NI5210 8kb RAM, 2x28ms 65Mb RLL drives DTC
controller.
The poor performance has been shown against Interdrive 1.1 and PC/TCP
2.05, and also we had similar results using the previous
version we had (PC/TCP 2.04 and Interdrive 1.02).
robin
Dr Robin P. Alston Gradient Technologies Inc.,
Principal Member, Technical Staff 577 Main St., Suite #4,
(508)-562-2882 HUDSON MA 01749
robin@gradient.com FAX: (508)-562-3549
== Be a lert, we have enough loof's already. ==