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!vixen.cso.uiuc.edu!howland.reston.ans.net!news.nic.surfnet.nl!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: 12 Jan 1996 16:42:40 +0100 Organization: Sun Microsystems, Netherlands Lines: 218 Distribution: inet Message-ID: <4d5vhg$38p@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> NNTP-Posting-Host: mail.fwi.uva.nl Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:1930 comp.unix.bsd.bsdi.misc:2073 comp.unix.solaris:57108 comp.unix.aix:68617 Terry Lambert <terry@lambert.org> writes: >I could do the same going the other direction. I might even be >able to drag certain former high level Sun employees screaming >into the debate. 8-). I'd be interested in such a list.. When I was asked some time ago "If you like Solaris so much, you must know of some advantages SunOS has over Solaris". I drew blank. >The SunOS 4.x LWP mechanism is better than the threading >mechanism in SunOS 5.x because it optimizes the benefits >threads are intended to have over processes: minimization >of overhead associated with IPC and context switching. But it doesn't do preemptive thread scheduling, doesn't do poriorities well and blcoks in page faults and "fast" I/O. >Specifically, the n:m mapping of user space to kernel threads >in SunOS 5.x means that you *must* have a kernel thread for >each potential blocking operation initiated by a user thread. Incorrect. You need to have a kernel thread for each blocking operation, not for each *potential* blocking opeartion. If all threads are blocked, the OS gives you c change to start a new one. >The LWP scheduling mechanism (which I reimplemented in mid 1994 >in FreeBSD using the University of Washington papers) was a >superior mechanism, since it translated blocking operations >into non-blocking operations plus a context switch. How did you handle multiple threads on multiple processors? How did you handle page faults and disk/tape I/O? >The SunOS 4.x NFS is slower than the 5.x because the 4.x >implementation did not violate the reliability guarantees with >regard to not doing client or server caching without a commit >roll-forward facility (such as you get from PrestoServe or some >other NVRan facility, and such a facility would be equally >applicable to 4.x as well as 5.x). 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. >This leaves networking, which I think we can both agree is hurt >by the streams implementation replacing the monolithic TCP/IP >implementation of traditional BSD. The 3Mbit/S limit on the >network performance under SunOS 4.x was a limitation imposed >by the driver's misuse of the AMD Lance chipset buffers, not >an inherent "SunOS 4.x problem". 3MBit/ in SunOS 4? SunSO 4 can drive ethernet at full speed so that isn't true. (Ethernet is 10Mbit/second. Not to mention other types of networking (loopback ATM, FDDI), all of which are faster for bulk transfers than SunOS 4.x. Not to say that this couldn't have been improved in 4.x. >As to the VM mechanism, the SLAB allocator has some significant >drawbacks with regard to MP. As you point out, the implementation >is largely shared between 4.x and 5.x, so a claim of superiority >on that basis is broken. Both would, in the MP case, be better >off with a per processor preallocation page pool (like Sequent >uses). See: The Solaris 2.5 memory allocator uses a per-processor cache. >There are also significant problems with traversal of mmap'ed >files thrashing the buffer cache (the infamous SVR4 "linker >cause X to go all funny" problem). >The correct fix to the problem isn't to use alternate scheduling >classes (cv: UnixWare). It's to prevent the thrashing. You >could do that rather trivially by implementing per vnode working >set quotas that could be overridden with an madvise() call, or >you could have a slightly better fix with a lot more work by >imposing per process working set restrictions. Solaris 2.x isn't cast in stone. Many traditional Unix algorithms don't scale well or at all. As system grow bigger mor eof these problems come to light. And as time passes more reseach is done and better algorithms are implemented. There's still a lot to be learned from mainframes when it comes to large systems and to I/O. But the Unix crowd is learning. It's now possible in many Unixes not to cache the file just read. (when you read lts of files sequentially you don't want to cache them at all) >Bzzt. I "hang out" with kernel hackers who don't necessarily >modify their world views to conform to policy statements. You >can pass as many laws as you want, but PI will never be 3. 8-). The bulk of the problems you mention here exists in SunOS 4 and Solaris 2.x. But SunOS 4 will see no further changes, Solaris 2 will. >Yet you don't deny the back-port claim. 8-). Of course, we're speaking Solaris 2.1 days back then and there's a huge difference between 2.1 and 2.5. I've run them all in >One of the "offerings" it has is SVID non-compliance with the >getitimer(RT)/setitimer(RT)/gettimeofday(RT)/select(RT), which >taken together imply that the timers must have a resoloution >of the system clock frequency, as seperate from the system >clock update frequency. Don't worry, SVR4 has the same SVID >non-compliance. It's why the validation suite doesn't check >for it. XPG4 now takes precedence over SVID. (The default gettimeiofday has 2 args over the SVID verson of 1 arg.) >In order to get a high resoloution select(), where the timer >resolution matches that implied by its parameters in the man >page, you have to go to a select(2) rather than a select(3) >implementation -- meaning you have to use the 4.x compatability >libraries, or suffer with a 10ms timeout resoloution (the same >as poll(2), which select(3) is implemented on. There is only one select in Solaris 2.x: the libc select. That's the one that is called wherever you call select from. It bolted on top of poll(). Neither SunOS 4 select not Solaris 2 select honor timeouts smaller than 1/HZ. However, the older select() had a bug: the sleep time was rounded down, not up. >Can we say "double click" and "mpeg_play"? 8-). Not sure hwat you mean here. >I'll give you credit, since the select(2) *was* added in Solaris >2.3 compatability aBI for 4.x to allow binary compatability >with statically linked 4.x applications (a feature missing before). Not so, see above. >Most of the features (like loadable kernel modules) could be >shoe-horned in as loadable devices anyway, using the init/deinit >on a pseudo device to wedge in things not supported by the >loadable module interface in 4.x directly. The one thing people tend to forget when they talk about putting the Solaris 2.x stuff they like into the SunOS 4.x kernel is the simple thing that they may end up with similar trouble as the early Solaris 2 releases. (For MP machines you need to do kernel multitasking or you won't scale well as we saw in 4.x, add fine-grained locking and there's the slowdown and bugs you wanted to avoid). The Solaris 2.x developers have the hang of it now and Solaris 2.5 is much improved. >I don't see a single *big* feature, other than marketability on >government contracts because of the additional checkbox items >that don't affect real product functionality. That makes it >change for change sake, in my book. But the change is there. There's no going back. >That may be true of some people. On the other hand, there are >others (like me) who feel that the academic origin of the BSD >code as opposed to the SVR4 code means that it had a 2-4 year >develeopement horizon, whereas the SVR4 code was limited to 6 >month to 1 year cycles because of commercial performance review >scheduling caused peoples intellectual integrity to be compromised >when it came to making a choice between money and doing the right >thing the right way. The academic origin of the BSD code didn't mean making a choice between doing the right and teh wrong thing. BSD introduced a lot of APIs that *all* suck bigtime. (non extensible, ill-thoughtout). They did well inside the kernel, but IMHO they flunked " API design 101". >The end result is that we think BSD "hangs together" better than >SVR4. Some of us (me included) have tried to fix SVR4 at various >times in our careers. What do you think is so bad in SV? The APIs? The kernel? The programs/administrative code? And which parts of it? >What is Sun now? The big fish in the shrinking proprietary >hardware pond. A politically incorrect statement, I admit. Proprietary hardware? Sun will gladly sell you the board designs and specs of their latest hardware. You can license their hardware and their software. What amuses me most about this SunOS vs Solaris SV vs BSD debate is that people assume SunOS 4 == BSD. It was much better than any BSD OS of its eera. I mean, you could repartition your disks without having to recompile your kernel. Much of what people like about SunOS 4 was Sun value-add. Lots of that stillis in Solaris 2.x. The other thing people dislike about Solaris 2 is change. I found that in many things the change was for the better (init.d, jumpstart) Yet it's that change (what, no rc.local!) that upsets people most. 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.