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.