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!zombie.ncsc.mil!news.mathworks.com!newsfeed.internetmci.com!howland.reston.ans.net!EU.net!sun4nl!fwi.uva.nl!not-for-mail From: casper@fwi.uva.nl (Casper H.S. Dik) 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: 16 Jan 1996 14:25:38 +0100 Organization: Sun Microsystems, Netherlands Lines: 171 Distribution: inet Message-ID: <4dg90i$6le@mail.fwi.uva.nl> References: <4cmopu$d35@vixen.cso.uiuc.edu> <4crnbe$8a@olympus.nwnet.net> <4cs2kn$kfg@cynic.portal.ca> <4cu7t0$mg5@engnews2.Eng.Sun.COM> <4cv8j1$59k@park.uvsc.edu> <4cvjpk$rpf@durban.vector.co.za> <4d43bt$es8@park.uvsc.edu> <4d5vhg$38p@mail.fwi.uva.nl> <4dbun0$j2f@park.uvsc.edu> NNTP-Posting-Host: mail.fwi.uva.nl Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:1990 comp.unix.bsd.bsdi.misc:2140 comp.unix.solaris:57393 comp.unix.aix:68815 Terry Lambert <terry@lambert.org> writes: >1) Smaller footprint. Oh, wishing for the days of V7. Smaller is not better. Bigger isn't necessarily better either, but. >2) More robust. Uptimes in months or years. YMMV. I've seen long uptimes with Solaris 2.x here too. (Though not years as we keep current :-) >3) Non-STREAMS TCP/IP Explain why this is an advantage. Usually this doesn't make much of a difference. Solaris 2.x TCP/IP has some more advanced features. The sockmod/libsocket dichotomy doesn't do the maintainability of the socket code much favoiurs though. >4) Available for Motorolla based hadware so a heterogeneous > environment can provide the user with a near-identical > interface acress platforms (Intel isn't an argument here; > remember the 386i?). Oh, so you can call running it on Sun proprietary 68K hardware an advantage, but running Solaris 2.x on x86 and PowerPC and SPARC doesn't count as running on multiple platforms (Ah, I get it: you now have a choice of multiple hardware vendors to run Solaris 2 on, so you're worse of) >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. >6) Large amount of research materials are directly > applicable (papers, code, etc.). If you're into OS research, use a research OS. >7) Interfaces for FS writers is usable without source > license. I didn't know that it was that easy under SunOS 4/difficult under SunOS 5. >8) NFS is reliable, does not violate protocol specification. Neither does Solaris 2.x NFS. Where did you get this idea? >9) System clock accurate to 4uS; useful for non-statistical > profiling. Solaris 2.x system clock accurate to 1us. Perhaps you can elaborate on this point. >10) Select timeout resoloution is sufficient for finite > state automaton based parallel service engines without > requiring buzz loops. The select timeout resolution in SunOS 4 was 1/HZ. There's one difference though: SunOS 5 select rounds down to no sleeping wherasa SunOS 4 select with a non-zero timeout will always sleep atleast 1/HZ (Sun bug 1159865) (SunOS 4 rounds the sleep time up to the nearest 1/HZ, Solaris 2.x rounds down to the nearest ms, calls poll which rounds up to the nearest 1/HZ) >] How did you handle page faults and disk/tape I/O? >You mean how did I establish a dedicated signal handling >thread, or are you talking about implementing Mach-style >non-resident pagers (why would I have to do that?). No, I wondered how you prevented *all* your LWPs from blocking when one of them incurred a pagefault. >] What do you mean by this? In Solaris 2.x as well >] as SunOS 4.x all server update operations are synchronous. >] Clients employ write behind in both OSes. >Server caching, which is not on by default for 5.x. You mean "async writes" as SGI does? I don't think Solaris 2.x has an option for that, I havent' found it. It's just synchronous writes to disk or "buy prestoserve". >It can't recieve at that speed because the Lance driver sucked. >This is discussed in the 5.x release notes for the 4.x->5.x >"upgrade". Hm, I distincly remeber running near wire speed TTCP between SunOS 4.x le boxes. You're not confused with the ie (Intel) ethernet chip as found in the older VME based servers? That one didn't do to well. >Well, except for read-ahead, which adds a copy but subtracts an >I/O latency. You could "page flip" instead. >But the point here should not be "why 5.x can be corrected" but >"why 4.x can't be corrected at the same time 5.x is corrected". What do you think SunOS 4.x would have looked liked after being corrected to include all the features people miss in SunOS 4? I'm pretty sure people would have complained it was buggy and slow. (Look at SunOS 3 vs SunOS 4 debates back then) >Your argument is that people prefer 5.x. Well, I'm people, and >I prefer 4.x. No it isn't. It's that we have 5.x now and that we should accept that as a fact of life. And that 4.x++ wouldn't be that different from what 5.x is now. And that adding SMP to 4.x wasn't all that easy. They basically gave up when doing 4.1.2 and punted to basically one single lock. How would 4.x with Sun SMP have worked. It's the high end machines tnd the concurrency hat gave the bulk of the trouble in the early Solaris releases. I don't belief that those problems could have been avoided just by building on a SunOS 4 code base. >There were no guarantess because of the process quantum >utilization potentially causing a program to utilize the >full quantum (10mS) in SunOS 4.x. But there was the >probability, since the timers were serviced at their call >resoloution to the best of the systems ability, that on >a system not loaded with full quanta-consuming processes, >you would get a better response time. >Average on a lightly loaded 4.x system is better than 200uS. On an unloaded system I still get 10000 us responses from a 1 us select call, if no selectable events occur. >The only method of assuring better than 100 events per second >on a system with a bad system timer architecture (like SVR4) >is to use idle loops for timing. gettimeofday() works fine if you want to have microsecond accuracy. Select doesn't have us accuracy in SunOS 4. Yourproblem still isn't clear to me. >How do staticlly linked binaries that call select that are >from 4.x run on 5.x? They call the select() in libc.so.1 (yes, I noticed the statically linked bit) >I think you'll find my name on the bug report. Id? >But API's are fluff. The interesting stuff is the engine, >and all the arguments in my "top ten list" at the top of >this article still apply despite the condition of the fluff. It's been a long way from the top of this article, but I think I only gave you 1 or 2 out of 10. Casper -- Casper Dik - Sun Microsystems - via my guest account at the University of Amsterdam. My work e-mail address is: Casper.Dik@Holland.Sun.COM Statements on Sun products included here are not gospel and may be fiction rather than truth.