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.cis.okstate.edu!news.ksu.ksu.edu!news.physics.uiowa.edu!math.ohio-state.edu!howland.reston.ans.net!gatech!pirates!cssun.mathcs.emory.edu!nntp.msstate.edu!not-for-mail
From: fwp@Jester.CC.MsState.Edu (Frank Peters)
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: 17 Jan 1996 12:54:09 -0600
Organization: Mississippi State University
Lines: 83
Distribution: inet
Message-ID: <4djgkh$kgn@Jester.CC.MsState.Edu>
References: <4cmopu$d35@vixen.cso.uiuc.edu> <4dbun0$j2f@park.uvsc.edu> <4dg90i$6le@mail.fwi.uva.nl> <4dh42v$rnv@park.uvsc.edu>
NNTP-Posting-Host: jester.cc.msstate.edu
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:2014 comp.unix.bsd.bsdi.misc:2170 comp.unix.solaris:57549 comp.unix.aix:68972
According to Terry Lambert <terry@lambert.org>:
> 4.x ran on SPARC and 68k and x86.
> 5.x runs on SPARC and PPC and x86, not 68k, and I have yet to
> see the released version for the Motorolla Ultra 603/604 board
> because of the continued lack of OpenBoot support.
>
> So effectively, you have lost one platform and gained none.
This is pure sophistry.
Fact: 4.x dropped support for 68k and x86 some time ago. You won't find
support for either architecture in 4.1.3 or 4.1.4 (the last release
that supported the 68k was 4.1.1_U1, I'm not sure about the 386i).
Fact: A major reason given for dropping support for these architectures
was dropped from later 4.x releases was the difficulty of
maintaining the 4.x code base for them. 4.x source wasn't
written with the portability constraints needed to support
several architectures from the same code base. Maintaining
multiple architectures in a practical fashion would have required
a major rewrite of the 4.x code. There is every reason to expect
that such a rewrite would have engendered many of the same
performance problems and bugs that existed in earlier releases of
5.x.
Fact: Even when it did support intel, 4.x "ran on x86" only in the
sense that it ran on Sun's 386i platform. You couldn't by a PC
and run 4.x on it. 5.x does, however, support commodity PC
hardware. Claiming that 4.x x86 support and 5.x x86 support are
anywhere near equivalent is silly.
I can't speak to PPC support issues since I'm not familiar with Sun's
efforts in that area.
> ] >5) Compiles most net sources "out of the box" without
> ] > modification or use of a compatability environment.
> ]
> ] Is true for Solaris 2.x for most non-ancient net software.
> ] It's even more true in Solaris 2.5.
>
> Because of the compatability environment.
No. I have a wide variety of net source compiled under 5.x. None
required the compatibility environment (I know because the system
I compile most of the code on doesn't have the compatibility environment
installed).
> ] >8) NFS is reliable, does not violate protocol specification.
> ]
> ] Neither does Solaris 2.x NFS. Where did you get this idea?
>
> Someone said it was faster with no other justification. Plus
> I had to turn it off on a 2.3 box -- but I admit the possibility
> that someone else had turned it on. If that's the case, it's
> change for change's sake, and that's not good.
Not only isn't this turned on by default, it isn't even documented
in Sun's administration documentation. When I have seen the procedure
discussed (in net postings and the like) its never been recommended and
has been accompanied by appropriately dire warnings.
This makes me wonder how many of your other opinions are the result of
inheriting a misconfigured/mismanaged system and just assuming that any
problems were Sun's fault.
> Prestoserve relies on the ability to tell it to do async.
Like many of your other points, this is incorrect. Though usually
billed as an NFS accelerator, prestoserve doesn't really change the way
NFS works at all. What it does is to change the way disk IO works in a
way that makes it work better for NFS service.
What prestoserve does is to redirect disk IO for selected devices
through a battery backed memory buffer (NOTE: ALL IO for selected
devices, not just NFS IO). The battery means that the buffer retains
its data even if the system looses power. So writes can be
acknowledged when the data is written to the memory buffer instead of
waiting until it is written to disk without violating integrity
constraints.
Notice that in this scheme NFS is still doing the same sync IO. Its
just doing it at memory speeds instead of disk speeds.