Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!nntp.coast.net!lll-winken.llnl.gov!osi-east2.es.net!oracle.pnl.gov!mica.inel.gov!cwis.isu.edu!nntp.et.byu.edu!news.byu.edu!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.netbsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.solaris,comp.unix.aix
Subject: Re: ISP hardware/software choices (performance comparison)
Date: 19 Jan 1996 22:18:17 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 81
Distribution: inet
Message-ID: <4dp5b9$8v8@park.uvsc.edu>
References: <4cmopu$d35@vixen.cso.uiuc.edu> <4d43bt$es8@park.uvsc.edu> <4d5vhg$38p@mail.fwi.uva.nl> <4dbun0$j2f@park.uvsc.edu> <4de3ml$naq@engnews2.Eng.Sun.COM> <4dgpti$rnv@park.uvsc.edu> <4dif2a$6ea@mail.fwi.uva.nl>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:2066 comp.unix.bsd.bsdi.misc:2223 comp.unix.solaris:57926 comp.unix.aix:69249
casper@fwi.uva.nl (Casper H.S. Dik) wrote:
]
] Terry Lambert <terry@lambert.org> writes:
]
] >If this is true (it is disabled on the machine I can get access
] >to, and I rememebr specifically disabling it -- it may have been
] >enables by one of three other people), then I will retract my
] >reliability claim made on the basis of assuming server cacheing.
]
] How did you disable it and how did you check that it is disabled
] on the machine you have access to?
I disabled it by changing a "yes" to a "no" in the /etc/rc file.
I know it is disabled because it says "no". The default with
no rc file hacks for it is "yes".
This is apparently the flag that enables the routine that
is responsible for old/new NFS write performance; I may be
able to dig up the information this Saturday via a long
distance phone call if I have to.
Thanks to Juergen Keil for sending me a private email message
with the real async write patch. It is not the patch to which
I was referring, which I incorrectly identified as the "async
write patch".
I would *never* enable the async writes in Solaris NFS. I
would always turn off the "NFS write speed enhancement"
because of interoperability problems with non-Solaris clients,
specifically Older SGI and AT&T machines.
] >Stipulating this, however, I once again request proof that the
] >5.x implementation is higher performance than the 4.x, and
] >further that any performance difference is not simply the result
] >of the 4.x driver's misue of the Lance buffers, as described in
] >the Solaris 1.x->2.x upgrade/release notes.
]
] LADDIS benchmark results? And please point me to the notes on
] the "3Mb/s le limit" you stae was in SunOS 4. (Since you can easily
] get tcp throughput will in excess of 3Mb/s on SunOS 4 w/ le, I
] seriously doubt that claim)
LADDIS results would definitely be acceptable -- it is a well
recognized benchmark.
I do not have the release notes for the original Solaris 2.x
at hand (I don't have a Sun, and the Sun's I had control over
ran 4.x, not 5.x).
Besides the release notes, there was a discussion of the problem
during the NetBSD SPARC port (which should be available through
their message archives) and again in several usenet discussions
(I will attempt to find them on tape, but it unlikely that I will
be successful).
You can take the information as anecdotal, unless someone who
participated in one of the discussions (I was only a spectator)
is willing to come forward.
] >I find anything other than a marginal performance claim to be
] >difficult to support without resorting to server caching or
] >some other "speedup" technique which requires violation of
] >the protocol spec (like the 4.x and 5.x client caching).
]
] LADDIS doesn't benefit from client side caching.
] (The LADDIS benchmark generates NFS requests itself, it
] doesn't use a OS client version)
That's a plus, since the claim that was made was for server
performance.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.