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!lazrus.cca.rockwell.com!cacd.rockwell.com!news-feed-1.peachnet.edu!usenet.eel.ufl.edu!newsfeed.internetmci.com!in2.uu.net!usc!news.service.uci.edu!usenet From: Dan Stromberg <strombrg@hydra.acs.uci.edu> 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: Wed, 17 Jan 1996 17:10:22 -0800 Organization: University of California, Irvine Lines: 160 Distribution: inet Message-ID: <30FD9DFE.20E8@hydra.acs.uci.edu> References: <4cmopu$d35@vixen.cso.uiuc.edu> <4cu7t0$mg5@engnews2.Eng.Sun.COM> <4cv8j1$59k@park.uvsc.edu> <4d37d4$j0l@gremlin.backfire.mn.org> <DL29Az.Ax2@ftel.co.uk> <bryDL3r9p.2oq@netcom.com> <4dgrjm$rnv@park.uvsc.edu> NNTP-Posting-Host: bingy.acs.uci.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0b4 (X11; I; SunOS 5.5 sun4m) Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:2017 comp.unix.bsd.bsdi.misc:2175 comp.unix.solaris:57566 comp.unix.aix:68986 You're still whining. Terry Lambert wrote: > > bry@netcom.com (Bryan Althaus) wrote: > ] The day I hear from someone who uses SunOS 4.1.3 and Solaris 2.5 on > ] a regular basis and knows both OS's well and concludes that SunOS > ] is better, is the day I give up UNIX and move to the NT camp. > > I guess you will have to wait for 2.5 to have been out for > some time before you will listen to any argument whatsoever. Whatever for? > Of course this is not a fair comparison, since we should compare > 4.1.3 with 2.x, where x is the level of release at the time that > 4.1.3 developement was halted. Bzzt. Doesn't work that way. If you want to be arbitrary about it, I think we should compare Solaris 2.5 against SunOS in 1945. > I say this because the developement fast that point could have > easily bein on either code base, and you are comparing unfairly > otherwise. Wrongo. Solaris is what's here and now - and you can't make a cogent case that System V wasn't the right way to go. I believe that's more than enough. > ] The arguement I loved was the comparison of SunOS 4.1.x threads to > ] Solaris 2.x. SunOS 4.1.x threads are a joke and Sun years ago told > ] developers that they would no longer be supported and told our > ] company not to use them. A few programmers wanted to use them and > ] you can guess when deadline time came where all the problems were. > > I see you have implicitly backed off from claim that LWP and > pthreads are the same thing. ..and it has absolutely nothing to do with the technical merit of operating systems, if he did. > Yes, people who use a facility that will be unsupported soon > are fools. Before you apply this to a 4.x to 5.x argument, let > me point out that buying fresh bread from a bad recipe will > result in your sandwich tasting worse than if you had used > day-old bread instead. So? Staying with 4.1.x is a bad business decision - not to mention, contrary to the interests of furthering the best *ix's out there. > That you believe that LWP is a joke (it is no more so than the > idea that you can add more processors and multiply performance > on all problems regardless of their geometry) is irrelevant to > whether the 5.x/SVR4 threading mechanism is a joke. Uh huh.... > Have you ever built and compared a threaded and non-threaded > version of an application? For instance, have you ever used > "team" or "ddd" for I/O interleaving on a device? (as an > aside, "team" fails on an MP Solaris box because of process > scheduling synchronization guarantees failing in the pipe > facility; "ddd", which uses shared memory, does not). Are you bragging, or talking OS'? Is your Great Technical Strength supposed to somehow make Solaris look worse? > I have. I worked on the process architecture for the 4.x > NWU (NetWare for UNIX) product. It was *me* who implemented > interprocess decriptor table sharing system calls on AIX, > Solaris, SunOS, and UnixWare. It was *me* who implemented > the NWFS attributed file system. It was *me* who suggested > hot engine scheduling. Um. I guess I won't repeat myself quite this soon. > Because of the lack of process quantum guarantees and the > base code set being ill-adapted to a shared context model > because of a large amount of global data, sharing of context > on the work-to-do model via the SVR4 thread model was not an > option. Gee, isn't that a shame? > Nor was it a win over sharing global context in a shared memory > segment and sharing an open file table between the various > engines. You're tempting me to repeat myself again. > For one thing, if you use the idiotic SVR4 model, you must > preallocate the stack at thread creation time. So once that's done.. who cares? > For another thing, using the SVR4 model precludes the ability > to attach a management utility to the context and manipulate > it. If it's a shared memeory segment and descriptor table, > I can attach and detach the thing at will. If you're manipulating beyond what an inspecting-debugger would do, I'd say you're trying to take this too far. If you're saying debuggers for threaded apps aren't feasible on Solaris 2.5, I'm not sure I buy it. :) > It's IOTTMCO that n:m mapping for n != m for kernel vs. user > space threads means that some work-to-do engines (such a > model operates on engine anonymity) will suffer starvation > for process quantum. > > Obviously, this is only true if the engines perform blocking > operations. Like I/O to talk to clients. Or file system I/O. > Like NetWare, Oracle, Sybase, Informix, etc., etc.. Um. Asynch I/O? Um. Synch I/O emulated in terms of Async I/O? > ] When we ported to Solaris 2.4 and rewrote using real threads, > ] the problems all went away. Wonder why? > > Second system effect? Assumption that signals are events > instead of persistant conditions? Hm. So if there's any kind of indication that Solaris 2.x might be better, we start grasping at straws like this? Terry, you're supposed to be a bright boy. Show us how bright you are. (It'll have no bearing on the merits of Solaris, however. The fact that you can sit around and (weakly - tho in terms that confuse many people) poke holes in Solaris, is really of little consequence. The fact is, Solaris stacks up quite well against other unix variants - it's a very good one) > If you were truly clever, you would have implemented using > async I/O an completion routines. The aioread, aiowrite, > aiowait, and aiocancel facilities exist on both 4.x and 5.x > and on most other UNIX platforms as well. This would have > prevented you from orphaning a portion of your market. But didn't I just read... Oh never mind. > You wouldn't get to claim "nifty threads in this product!", > but it is a very rare occurance where a problem can not be > solved as well (or better) using a different technique. True. So let's get to the point, here, Terry. Why have you chosen to single out Solaris for your clearly-biased attacks?