Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.hawaii.edu!news.uoregon.edu!cs.uoregon.edu!sgigate.sgi.com!imci3!imci4!newsfeed.internetmci.com!gatech!news.Gsu.EDU!nntp.ipst.edu!gt-news!ccrf-news!ccrf-news!not-for-mail
From: jmills@ccrf-news.gtri.gatech.edu (John M. Mills)
Newsgroups: comp.os.linux.development.apps,comp.os.linux.development.system,comp.os.linux.x,comp.os.linux.hardware,comp.os.linux.setup,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: 4 Apr 1996 10:51:17 -0500
Organization: Georgia Tech Research Institute
Lines: 70
Message-ID: <4k0r5l$g2@siberia.gtri.gatech.edu>
References: <4jn4qp$6p@darkstar.my.lan> <stephenkDp7nHo.369@netcom.com> <4jrhth$66a@hoopoe.psc.edu> <4jve3t$cfe@hermes.synopsys.com> <4k0m0f$68j@hoopoe.psc.edu>
NNTP-Posting-Host: siberia.gtri.gatech.edu
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.apps:14126 comp.os.linux.development.system:20649 comp.os.linux.x:28523 comp.os.linux.hardware:35388 comp.os.linux.setup:48951 comp.unix.bsd.386bsd.misc:443 comp.unix.bsd.bsdi.misc:2979 comp.unix.bsd.netbsd.misc:2744 comp.unix.bsd.freebsd.misc:16617
In <4k0m0f$68j@hoopoe.psc.edu> peterb@hoopoe.psc.edu (Peter Berger) writes:
>In article <4jve3t$cfe@hermes.synopsys.com>,
>Joe Buck <jbuck@synopsys.com> wrote:
>>Stephen Knilans <stephenk@netcom.com> wrote:
>>>>Name ****ONE****! So far, I haven't heard ONE legitimate reason!
>>(why Linux isn't suitable for commercial use).
>>peterb@hoopoe.psc.edu (Peter Berger) writes:
>>>Here's one: 14% utilization of UDP bandwidth, best case.
[gratuitous insult elided]
[request for specifics elided]
>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
If anyone has a URL for this, it would be useful to post it.
I have a couple of other questions, in addition to whether these results
were obtained on platforms of comparable "general" performance: basically
to know whether the performance was attributable to the system architecture
(i.e., did the processor have to swap bytes and restructure the packets?),
or the os (were there other x86 comparisons than FreeBSD vs. Linux).
In particular, with currently reasonable [academic] prices on Solaris for
x86 processors, it would be very interesting to compare the Sun product
with Linux. Especially since the early tenor of this thread seemed to
suggest that Linux basic quality was at the "toy" level.
>performance is better than FreeBSD's (not surprising, since Linux
>is so intel-specific)
It would be interesting to know how (for example) the (OSF Posix.1)
Alpha port runs, as well. This is relatively recently released, so
I would say that more benchmarking might be worthwhile. It's also a
case where the Linux and commercial (DEC) versions could run head-to-
head.
> but it's networking performance is, to put it
>most kindly, a joke.
I'm hoping that more information will identify _why_ this results.
The original seemed to attribute it to the character of the Linux
development community -- I'm sure many of us could [pointlessly] reply
with a list of disappointing commercial products, many from highly
respected vendors.
>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. 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.
A definite "maybe" on this: It does give you a baseline comparison, but
unless "stable" implies specific configurations and more importantly
some expectation of external support, it may not make a difference to
a self-supporting user. You certainly need to clearly define the tested
configuration, of course. The question of "Why didn't you try *.*v*R* on
the 'Anthill' (TM) multiprocessor" can only be answered: "Here's the code
-- _you_ try it." I don't see how such a single experiment can be more
than a starting point.
Many of these points and others may be treated in the original article. I
apologize for posting from ignorance on this. I'm really trying to say
"one table is worth 1000 flames."
--
John M. Mills, Senior Research Engineer -- john.m.mills@gtri.gatech.edu
Georgia Tech Research Institute, Georgia Tech, Atlanta, GA 30332-0853
Phone contacts: 770.528.3258 (voice), 770.528.7083 (FAX)
"Lies, damned lies, statistics, and simulations."