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!usc!sdd.hp.com!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
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: 11 Jan 1996 22:35:41 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 225
Distribution: inet
Message-ID: <4d43bt$es8@park.uvsc.edu>
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>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:1912 comp.unix.bsd.bsdi.misc:2060 comp.unix.solaris:57041 comp.unix.aix:68558
gavin@durban.vector.co.za (Gavin Maltby) wrote:
]
] Terry Lambert (terry@lambert.org) wrote:
]
] : Personally, I intentionally associate because I don't think
] : that SunOS 5.x is worthy of the name SunOS.
]
] Nonsense!
No, it's true: that's what I think! 8-).
] : It is generally inferior in almost all respects (save MP).
]
] Further crud. I could fill a few pages of benefits over SunOS 4.
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 could argue thread scheduling, NFS, and VM with you until
] : I am blue in the face. 8-).
]
] It is easily agreed that SunOS 5 is the hands-down winner over SunOS 4
] in the departments you mention. Do you think otherwise? SunOS 4 has
] no real multithreading to speak of, it's NFS is a *lot* slower and
] is not multithreaded, and it's VM alogorithms are practically a subset
] of SunOS 5 (which just continues to refine those algorithms).
I think otherwise.
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.
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.
The result is that the threaded process is n threads mapped
onto m process quantums, and the process quanta are not fully
consumed.
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.
The ideal threading mode would be a hybrid of the two, but given
only a choice between them, I choose LWP. I can accomplish n:m
mapping context sharing for n == m (a requirement for work-to-do
model servers) *without* resorting to the complication of having
a stack that I can't automatically grow per thread.
You could argue that the non-LWP model is better scalable to MP,
but then I already ceded you MP. 8-).
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).
I agree that kernel multithreading is a win, so that file system
multithreading can be used to overlap isosynchronous metadata
operations for multiple outstanding operations with non-overlapping
locality of reference. In fact, in UnixWare, we measured the
UP performance increase at 160%, without additional changes.
It turns out that there is no topological distinction between
this type of mutlithreading and interleaved I/O as a result of
"Delayed Ordered Writes". This is proven out by the similar
gains, *without* multithreading, of the VIVAFS (University of
Kentucky).
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".
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:
UNIX Internals: The New Frontiers
Uresh Vahalia
Prentice Hall/Simon & Schuster
ISBN: 0-13-101908-2
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.
] : Almost everyone (except SunSoft) pretty much feels the same way,
] : it seems.
]
] Perhaps everyone *you* speak to, and that sounds like a decidely
] inexperienced and unknowledgable crowd.
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-).
] : Sun had to back-port 4.1.3 to the new hardware because some
] : of the Japanese OEM's (Hitachi, Tatung, from memory) threatened
] : to do their own BSD port because they hated Solaris so much.
]
] Featurewise, Solaris has many times more to offer an application.
Yet you don't deny the back-port claim. 8-).
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.
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.
Can we say "double click" and "mpeg_play"? 8-).
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).
] No developer looks at Solaris 2 and say "I am glad none of those
] features are in SunOS 4".
Well, maybe they look at streams and the look at process group
signal notification that way; there are other more esoteric
"features" than these.
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.
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.
] OK so having to use the SVID etc in development might not
] be what everyone would love, but I suspect that a lot of
] people like the BSD enviroment just because that is what
] they *know* and they refuse to adapt and learn the intracies
] of the new interface.
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 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.
] : Sun tries to hide the fact that there's a difference using
] : labelling, but we all know the difference between BSD and SVR4,
] : and we prefer BSD.
]
] Solaris = SVR4 + a lot of features! What you are really bitter
] about is that BSD style UNIX did not win out or reach critical
] mass over SVR4.
Do you really want to get into a comparative analysis of what
constitutes "critical mass"?
The end result of such a discussion is the question "why isn't NT
the default OS for Sun hardware?".
] That's something you just have to deal with---it happened and
] isn't about to unravel. I am sure that there are those at
] SunSoft who preferred the BSD way, but there was just no way
] to stay with it. Sun would be a small niche-market workstation
] player if they had not overhauled SunOS 4 to SunOS 5/Solaris 2.
What is Sun now? The big fish in the shrinking proprietary
hardware pond. A politically incorrect statement, I admit.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.