Not 5 years ago, it couldn't. Less than two years ago, SMP was
introduced in OSF/1 3.0 (we field-tested it) and we had kernel
panics on average three times a week for over 6 months. Things
have finally got a lot better with Digital UNIX 3.2C + extra
patches but we had it very bad for a long time. We're up to
vmcore.66 and that's after dropping the count by about 20 after
one re-installation. The journaling file system you mention,
AdvFS, is useless before 4.0 in many SMP environments since it's
not SMP-aware: everything is funnelled to the boot CPU. LVM/LSM
also had problems and were not as useful with UFS instead of AdvFS:
although you could dynamically expand the underlying "disk", UFS
couldn't itself be expanded.
The clustering stuff is neat: the underlying technology is a fast PCI
memory channel (~800Mbps or possibly bytes per sec: damn fast anyway)
between two machines (or with a hub if you want to scale up). The
necessary kernel support mirrors a few pages between the hosts to
keep state and runs IP across the memory channel. For clustering
disks there's a limited amount of sharing of real disks (in practice,
SCSI is pretty fragile about that sort of thing) but you mostly NFS
mount your disks across the memory channel (and looback mount your
own disks). There's enough kernel support to get fail over: when one
host goes down the other picks up the physical disk and the upper
layers see nothing because it's NFS mounted anyway.
There's sugar coating on top of it all and all the usual IP aliasing
tricks and glue to make it a product, but it's mostly just nice
hardware.
>As of this moment Linux can't do any of these. Sure,
>it will, eventually. But this is a catching up mode. When Linux
>catches up with DEC on these or other features, DEC will have
>something else up their sleeves. I hope I am wrong, but so
>far, my impression has been, that very little innovation comes from
>the Linux camp: all we do is trying to outperform others in
>things they had been able to do years before Linux' ( or even
>Linus' :-) ) conception.
What, you mean like fast IP aliases that Linux has had for a while
and that DEC have only just put into 4.0 (and are planning to supply
a patch for for 3.2x--it may be in 3.2G though)? Linux has more
flexible routing tables than Digital UNIX. Linux has a greater number
of dynamically loadable kernel modules than Digital UNIX and better
support for run-time configuration of them. Digital UNIX has
"sysconfig" hooks for run-time kernel subsystem configuration but you
still have to use sysconfigtab and reboot for most configuration
parameters. The quirks of Mach memory management and SMP support are
causing problems these days. DEC had to completely rewrite the SMP
stuff in OSF/1 and overhaul the memory subsystem which is a weird
hybrid of BSD and Mach. In doing so, they've done an extremely good
job and they've been very innovative. But Linux has also had its
memory management overhauled and it too has been equally good and
innovative. Score draw. Based on what I hear about Linux SMP, Digital
UNIX is still currently ahead there, especially for more than a few
CPUs. The shake-out for serious Linux SMP is on its way and it'll be
interesting to see how it goes.
> And they honestly don't care. Who
>cares that OSF's kernel is 8 MB if AlphaStation comes with
>64 MB minimum, and memory prices keep going down? If you
>were Digital, wouldn't you rather concentrate on the features your
>customers demand, than optimizing every line of code in the
>kernel?
They *have* been optimising the kernel for 4.0 though. They've put a
lot of work into it: lots of memory subsystem changes: page table
granularity hints, making more of the SMP locks more fine-grained,
improving shared memory (because it gets hit a lot by databases).
> > > but let's be honest - there is no way that a group of people, most
> > > of who hold daytime jobs, can compete with the multibillion
> > > corporations, which employ some of the best minds on this planet.
> >
> > I beg to differ. And every benchmark we have floating around says just who
> > is winning.
>
>See above. In addition to that, let me add, that user's perspective
>of what OS is, is quite different from yours, Linux major contributor.
>As a user, I don't run kernel tcp/ip benchmarks, I run ftp instead.
>And what I see is that ftping from Solaris 2.4/Sparc2 to AlphaStation
>on a different subnet delivers 660KB/s on average. The Linux box,
>which hardware wise should beat the crap out of an ancient Sparc
>delivers 250 KB/s.
What kernel version and what ethernet card? You should be seeing at
least 750-850Kb/sec with an equivalent ethernet card/CPU. I run our
web server with Linux 2.0 and NFS export the filestore to the
general purpose 2100 Alphaservers from which our users get at their
web pages. The web server is a Pentium 133MHz running Linux 2.0 with
a 3com 3c590 PCI ethernet card and I get 500Kb/sec with NFS. That's
not even with the latest 3c590 driver which should be even faster,
I believe. If you're getting 250Kb/sec with ftp then you're either
not runing Linux 2.0 or you've got a much worse ethernet card which
you shouldn't be comparing with the (presumably) reasonable one that
Sun installed in their box.
[...]
>to writing it as a means of self expression. And this suggests the way
>how to really improve Linux' chances on BIG success - make it EASY
>for the commercial entities to write for Linux. It means supporting
>Spec 1170, instead of POSIX.
Linux *is* being put through the relevant branding process. Pasting
from the press release
http://caldera.com:80/whatsnew/open_linux.html
it's going to be POSIX.1 (FIPS 151-2) in Q3 1996; XPG4 Base 95 (POSIX.2,
FIPS 186) by Q4 1996; and X/Open brand for UNIX 95 based on the Single
UNIX Specification (formerly known as SPEC 1170) during 1997.
The resulting branded Linux is going to be freely available.
[...]
>I read your answer to Alexey regarding STREAMS. I am sure, you
>are right that it's slower than sockets, but it does not matter.
>If someone recompiles or starts developing an application for
>Linux because of this feature, it will benefit Linux much more
>than a better benchmarks with no applications to use.
For *application* level STREAMS, most people mean TLI/XTI and it's
been said numerous times that library support for those (and even
binary compatibility support for things like iBCS) are either
available now or are going to be available. The fact that the
underlying kernel implementation is a socket API doesn't matter to
the application or the user (except it's faster ;-). Even Digital
UNIX implements some of the standard STREAMS modules with empty stubs.
>Let me sum things up: Linux has not conquered the world yet,
>but keep up a great job, guys.
>
>Alex Krimkevich.
>
>P.S. I just wanted to re-instill the sense of reality on this
>mailing list :-)
I wanted to add a few facts of my own. I really like both Digital UNIX
and Linux so, with any luck, some of this extra information may help
some people make their own informed choices.
--Malcolm
-- Malcolm Beattie <mbeattie@sable.ox.ac.uk> Oxford University Computing Services "Widget. It's got a widget. A lovely widget. A widget it has got." --Jack Dee