Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!act.news.telstra.net!psgrain!news.uoregon.edu!news.dacom.co.kr!usenet.seri.re.kr!news.cais.net!news.jsums.edu!gatech!newsfeed.pitt.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.psc.edu!hoopoe.psc.edu!not-for-mail
From: peterb@hoopoe.psc.edu (Peter Berger)
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.386bsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.freebsd.misc
Subject: Re: Why to not buy Matrox Millennium
Date: 5 Apr 1996 07:27:39 -0500
Organization: Pittsburgh Supercomputing Center
Lines: 194
Message-ID: <4k33jr$khp@hoopoe.psc.edu>
References: <4jn4qp$6p@darkstar.my.lan> <4jve3t$cfe@hermes.synopsys.com> <4k0m0f$68j@hoopoe.psc.edu> <4k2i4g$n55@usenet.srv.cis.pitt.edu>
NNTP-Posting-Host: hoopoe.psc.edu
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20720 comp.unix.bsd.386bsd.misc:460 comp.unix.bsd.bsdi.misc:3005 comp.unix.bsd.netbsd.misc:2765 comp.unix.bsd.freebsd.misc:16677
In article <4k2i4g$n55@usenet.srv.cis.pitt.edu>,
Mark Hahn <hahn@neurocog.lrdc.pitt.edu> wrote:
>
>> These results were published at the January 1996 USENIX technical conference,
>> in a paper by Kevin Lai and Mary Baker from Stanford. I'm sure this
>> paper is available on the web -- I apologize for not having a URL, but
>> I'm looking at the hard copy now. The bottom line is that Linux CPU
>> performance is better than FreeBSD's (not surprising, since Linux
>> is so intel-specific) but it's networking performance is, to put it
>> most kindly, a joke.
[gratuitous insult deleted.]
Thanks for being more interested in getting into a fight than into
discovering the truth, Mark. I didn't insult you; and in my E-mail
to you I indicated that I use BOTH linux and the *BSD's, but I guess
that doesn't make as good propaganda, huh?
Here's a hint, Mark: a "bigot" is someone who bases their opinions
on unreasoned prejudices rather than on actual data. Given that, I'll
let the world at large decide which one of us is a bigot.
>1. Linux networking works very well. it has always been able to
> saturate the wire, at least 10 Mbps wires.
This statement is false, of course; and you give no references to
support it. (Gee, my 386 with a 3c501 running Linux can saturate an Ethernet?
Are you willing to put some money on that....:-)
In any event, "networking" consists of more than a
single-mode stream of one TCP connections, and there are serious flaws
wired in to Linux's CURRENT networking design which make it completely
unsuitable for serious networking use. This was as of the last time
I examined the source, and I welcome corrections or updates.
Examples include:
1) routing tables indexed by a linked list rather than radix tree, resulting
in O(n) time as routing table size increases rather than O(n log n). Here's
a hint, Mark: one of the most essential "commercial networking" tasks
there is today is routing. A BSD box is a reasonable (though not optimal)
choice for a router. A Linux box, because of the above problem among others,
is an unreasonable choice for a router. I am talking here about high speed
routers which carry large routing tables, of course.
2) Nonstandard design. No implementations of selective acknowledgement
available. Linux does not follow the reference implementation of TCP/IP:
there is a reason why when W. Richard Stevens wrote TCP/IP Illustrated: The
Implementation he used BSD unix to demonstrate "The implementation." Because
of this lack of rigor, Linux can't seriously be used by the academic community
for TCP research (is anyone out there doing real TCP research with Linux? I'd
like to know about it if so.) This in itself doesn't mean Linux's
TCP/IP implementation is "bad" or "inferior," it just means that it
is -different-, and hence less likely to quickly gain the benefits of new TCP
research, such as Forward Acknowledgement. Another example (correct me
if I am wrong): Linux only recently (e.g., post 1.2.x kernel) implemented
TCP sliding windows, which are essential to using long pipes with many
hops efficiently.
>2. Linux NFS also works well, though its default configuration
> (1k packets!) was braindead and performance limiting.
Indeed. I notice a lack of any specifics in your statement. I was
disappointed in the Lai/Baker paper for not using a FreeBSD NFS server
as well to measure the bottleneck on that end: I suspect the disparity
in their numbers would have gotten even larger in that case.
>3. Linux is not "intel-specific": ask Linus about his Alpha,
> or DaveM about his Sun.
Linux up until recently has been tailored for Intel boxes. When Linux
achieves performances comparable to OSF/1 on an Alpha, I will revise my
opinion. And please note that this includes networking -- some of us
use Alphas as routers.
>4. none of the preceeding facts are apropos the the Lai/Baker paper,
> which is interesting, but now mostly for merely historic reasons.
[interesting specifics which, IMHO, miss the whole point elided.]
>the bottom line is that the paper is an interesting snapshot of features
>and performance as of a year ago. it's not relevant today.
In the absence of contradictory experimental data, I would suggest that
it is foolish to simultaneously insult the work of researchers and
wave your hands at the same time.
There are fair critiques that can be made of the Lai/Baker paper; I
don't think you've made them here. I detail why below.
>it would be somewhat interesting to compare current Linux _distributions_
>with similar representatives from the *BSD world. I'm thinking of
>RedHat and/or LinuxFT versus the latest stable FreeBSD or even BSDI.
>I'm just guessing, but I expect that the major Linux distributions
>avoid the configuration blunders in the Lai/Baker paper.
This is a good point. Are you willing to do the work?
>incidentally, I am not a Linux bigot: I simply have no experience with
>FreeBSD and dislike all the silly Linux-fragging that community does.
>if someone wants to tell me how I can install FreeBSD on my machine
>(p5/133, ide, internet) in less than an hour, I'd love to try it.
Just grab the installation floppy from ftp.cdrom.com and dd it to a
disk (or rawrite it in MSDOS). Stick it in your computer. Follow
the friendly prompts. If you like, it will FTP the entire set of
software to your machine over the Internet as part of the installation
(takes about 24 hours at 14.4k...presumably much less if you're on
Ethernet!)
>> In all cases, the versions of the software tested was the latest version
>> of the software which was a "production release" at that time -- no beta
>> software was tested. This is the Right Thing to do.
>
>do you install patches on your commercial-OS boxes? naughty you!
>stability is God, or is that 'stasis'? you can dress up this attitude
>in terms of 'production quality', but it's the whole reason why SunOS 4.1.3
>is still in use...
Actually, the reason SunOS 4.1.3 is still in use is that lots of people
prefer the design and implmentation of BSD unixes to SysV implementations.
I have more to say about production quality below.
>> It is completely
>> improper for anyone to recommend the 1.3.x kernels for commercial use,
>> since the 1.3.x is a development tree, and is specifically promised
>> to NOT be stable.
>
>nonsense, and mindlessly conservative, too. the development tree is
>just that: where all current code goes. there are times when it's utterly
>bogus, and most of the time it's hugely superior. Linux (and Linus, I
>presume,) is driven by developer desire, which means that there's almost
>no incentive to keep patching a 'stable' release. this is a disadvantage
>to the mid-level user, someone who isn't capable of the modest effort it
>takes to track the 1.3 tree, but who is aware of the weaknesses of crusty
>old stuff like 1.2.
This "mindless conservatism" as you call it comes from Linus, not from
me. When 1.3 was rolled out, early in its youth, there were tons of
messages warning, "If you want a stable release DON'T RUN 1.3. Run
1.2." Lai and Baker took them at their word, as would most reasonable
people.
Now, I have no doubt that you are absolutely right that I could probably
take one of the 1.3 kernels ... say, 1.3.48? or 1.3.96? ... and run it
safely. Which one? Let's say I'm supposed to evaluate operating systems
to put on our Intel hardware. How do I limit the scope of the problem?
Well, let's see, there's FreeBSD release, FreeBSD current, ditto with
NetBSD, BSDi's release, Solaris, and oh, look, 200 different Linux kernels.
How very useful. If I choose any one of them I will lose functionality
contained in another, and may encounter serious bugs, or may not, depending
on the luck of the draw and whether I was able to find someone else to
make a good recommendation. As you said: there are times when it's
hugely bogus, and times when it's superior. Well, call me picky, but
risking running a "hugely bogus" operating system in a production environment
doesn't help the people I support get their work done. You call this a
"modest effort," but I would say that that label is only true for someone
who has already committed to Linux. For someone who is considering her
or his options or who has to support a heterogeneous environment, the effort
is far more than modest.
This is another one of my problems with your critique of the Lai/Baker
paper: they did what they were supposed to, that is, run the production
kernel. If you can critique them for this, than just stop quoting any
Linux benchmarks at all, ever: there will ALWAYS be another kernel or
another release that you didn't test ("Well, SURE, the Red Hat and Caldera
and Slackware releases worked fine, but how do you know that bug is fixed
in the TSX or Debian release, HUH?") "Well, that problem that made
TCP/IP stop working and panicked the kernel is fixed in the latest beta
release" does not cut it for people who actually have work to do.
Just so that I'm not misunderstood: the problem is NOT that there are bugs
in the development kernel -- there are supposed to be, and there are bugs
in FreeBSD's and NetBSD's development kernels as well -- but that people
are recommending that other who require a production quality OS RUN these
buggy development kernels. Then, when they go to comp.os.linux.* for
help, they'll be told, "thanks for the bug report, but hey, if you wanted
stability, you should be running 1.2.x...."
>for purely political reasons (this kind of comparison) I'd like to see
>major Linux releases a little more frequently.
Perhaps this is one solution. This presumes that a production quality
release can be pulled together, but if one can, I'll be all for it.
>regards, mark hahn.
>--
>operator may differ from spokesperson. hahn@neurocog.lrdc.pitt.edu
> http://neurocog.lrdc.pitt.edu/~hahn/
--
Pete Berger
Coordinator, Regional Information Infrastructure
Pittsburgh Supercomputing Center