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!news.ysu.edu!usenet.ins.cwru.edu!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: 20 Jan 1996 00:57:36 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 100
Distribution: inet
Message-ID: <4dpem0$csu@park.uvsc.edu>
References: <4cmopu$d35@vixen.cso.uiuc.edu> <4dbun0$j2f@park.uvsc.edu> <4de3ml$naq@engnews2.Eng.Sun.COM> <4dgpti$rnv@park.uvsc.edu> <4dnk2q$b72@engnews2.Eng.Sun.COM>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:2054 comp.unix.bsd.bsdi.misc:2212 comp.unix.solaris:57872 comp.unix.aix:69208
thurlow@peyto.eng.sun.com (Robert Thurlow) wrote:
]
] In article <4dgpti$rnv@park.uvsc.edu>,
] Terry Lambert <terry@lambert.org> wrote:
]
] >thurlow@peyto.eng.sun.com (Robert Thurlow) 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.
]
] I think it's time to do that, since to my knowledge, only SGI
] has ever shipped systems whose NFS servers had async writes
] enabled by default. Sun would be the last vendor to do it (and
] I don't consider that entirely a good thing, just a fact).
I have corrected this in another article; after checking, it was
the "fast server writes" option (which is on by default) and not
the "async NFS writes" (which requires a kernl patch and is off
by default) that I had to turn off for the 2.3 NFS server to
operate reliably. Again, thanks to Juergen Keil for setting my
recollection straight.
] >I'll assume that it's true, since my main exposure to SVR4 is
] >by way of USL, and I have intentionally avoided Solaris after
] >my investigation of it at the 2.3 level.
]
] If you won't look at releases after 2.3, shouldn't you be
] recusing yourself from discussions of the merits of Solaris?
Perhaps "intentionally avoided" is to strong. "Not purchased"
would be a better characterization.
It's not worth the money needed to reacquire Sun hardware and
a copy of Solaris that would be needed for me to perform such
testing.
] >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.
]
] Same results; see detail in my other article. The "further"
] part is neither mine to comment on nor relevant, because these
] are two commercial releases, not hacker projects.
I respond positively to your other article listing numbers; it
was probably unnecessary for you to respond both to the original
article and my followup to a followup of the original article
with the same information.
I will say that status as "commercial release" vs. "hacker project"
no way ennobles one code base over another.
Commercial support availability, which is only one of the
implications of your statement, is potentially an issue for
an ISP.
It's possible that a startup ISP, if they couldn't afford the
price tag for a commercial release, would start with one of
the free BSD distributions and move to a supported OS after
the first problem (hopefully after they were stable enough to
be able to amortize the commercial OS costs.
If a commercial OS were purchased up front, then the commercial
OS's all provide support, though BSDI's is often said to be
very high quality (this might be related to the newsgroups I
typically follow).
] >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).
]
] Then your knowledge of NFS implementation is lacking. There's
] still work to do on performance.
It is possible that I could not reliably use PC, AT&T, and SGI
clients vs. the 2.3 NFS server without turning off the "fast
NFS server writes" option because of a problem in the clients.
On the other hand, that's a 3:1 vote in favor of a protocol
violation by 2.3 with the option enabled.
As I make clear in my other post, the higher NFS speed for the
Solaris over the SunOS 4.1.3_U1 is not necessarily attributible
to this option. Neither is is necessarily the 4.1.3_U1 NFS
implementation itself. It could be the 4.1.3_U1 protocol
stacks or driver (my gut feeling is driver).
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.