Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!paladin.american.edu!europa.chnt.gtegsc.com!gatech!newsfeed.internetmci.com!swrinde!sdd.hp.com!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: 18 Jan 1996 04:55:15 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 113
Distribution: inet
Message-ID: <4dkjrj$27e@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> <4dif17$a7r@durban.vector.co.za>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:2025 comp.unix.bsd.bsdi.misc:2183 comp.unix.solaris:57599 comp.unix.aix:69014
gavin@durban.vector.co.za (Gavin Maltby) wrote:
]
] Terry Lambert (terry@lambert.org) wrote:
]
] : 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.
]
] Perhaps you assume too much and should really use the OS before
] shredding it.
I'm willing to give your statement the benefit of the doubt;
will you do the same for mine?
My participation in this thread has been limited to either
responding to specific points from the response to the
original posting advocating Solaris for an ISP software
platform, or to follow up responses to my refutation of
that post.
That, and the occasional side tangent for answering questions
asked or commentary made in the context of the thread.
[ ... ]
] : 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.
]
] Empircal proof is not hard to come up with. As a real NFS
] server to many clients on many subnets Solaris 2 copes
] admirably where SunOS 4 just murdered the CPU. Besides that
] (a benefit of streamlining and multithreading) one can also
] tune various parameters in Solaris 2 to really maximise
] performance, where these paramters were difficult or
] impossible to change with SunOS 4. 4.x had a lot of problems
] with the le driver, but they don't account for the difference
] in NFS performance.
OK. It's anecdotal, and I think the streamlining you claim,
if not the multithreading, could be retrofit into 4.x, but
we'll ignore that.
It's possible, given these points, that the claimed performance
benefit for NFS came from something other than playing fast
and loose with the protocol spec.
It has been my personal experience with Solaris up to 2.3
that in side-by-side use, I had less problems with a 4.1.3_U1
machine than with a Solaris 2.3 machine. Both servers were
running on SPARC ELC's with 600M disks and serving a UnixWare
2.x system for the purposes of kernel developement.
I experienced many more hangs on the drives imported from the
2.3 system.
The UnixWare 2.x system system was being used for kernel
developement, meaning it crashed frequently.
Since we have departed the "ISP Hardware thread" for the
"4.x vs. 5.x thread", utility as an NFS server for a frequently
crashing client is applicable as a gauge of relative merit.
] : 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).
]
] NFS read performance is excellent in 2.x, but write performance can only be
] enhanced by speeding async writes to the disk (prestoserve, ufs logging can
] help). But what many people refer to as "better NFS performance" means
] sustaining the maximum that SunOS 4 could give to 1 client to many clients
] before significant performance hits occur. By client caching are you referring
] to the cachefs filesystem in 2.x? That is one way to improve NFS
] speed (page from the local cache), but 2,x NFS *server* performance is still
] faster than that of 4.x
My personal use was not as a server for multiple machines.
However, I did notice that the 2.3 mountd experienced problems
on older SPARCStation hardware that had run without similar
problems under 4.1.3 with a load of 30 dataless or diskless 1,
1+, SLC, and ELC's.
It is possible that both these problems have since been corrected
in 2.5; unfortunately this is anecdotal on my part and I have
no way to test 2.5 on the same hardware.
I would prefer benchmarks of 4.x vs. 5.x on identical hardware
for irrefutable evidence.
However, this does not refute the entire list.
To get back to the title thread, I don't see how an ISP
without a large machine farm sould benefit from improved
NFS performance. Even with a large machine farm, it would
be hard to justify more than a small number of NFS mounts,
if only because of the VM problems NFS introduces on any
memory overcommit architecture (yes, *BSD* and AIX both
fall into this category as well).
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.