Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!
news.service.uci.edu!aris.ss.uci.edu!jstern
From: jst...@aris.ss.uci.edu (Jeff Stern)
Subject: FYI.. benchmarks on linux and 386bsd
Nntp-Posting-Host: aris.ss.uci.edu
Message-ID: <2CB12A8D.17397@news.service.uci.edu>
Summary: Linux slower than 386bsd?
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Organization: University of California, Irvine
Keywords: benchmarks speed downers uppers and other dirty laundry
Lines: 86
Date: 5 Oct 93 08:04:29 GMT
I recently switched from 386bsd to linux, and happened to find some
benchmarks I had archived from when the same machine was running
386bsd, and thought I'd run them again under linux. i'm not going
to state which system i like better, because frankly i like them
both, and also both have their loveable quirks, too :)
anyway, since there seemed to be *SO* much 'authoritative information'
going around about both systems (usually from people who have tried
one but not the other) i thought I'd offer up the output in the
effort to produce some actual 'data' to consider.
These are two different dhrystone benchmarks, and a dhampstone
benchmark which I compiled both under gcc (without optimization) on
each system. To be fair, I can't remember which gcc I was running on
the 386bsd system, the one on linux is 2.4.5. The version of bsd I
had was 0.1, of course, with a few patches. Linux here is SLS
0.99.12/1.03. My box is a 386-33 Micronics with 8MB ram and 64K
cache, no wait states, and a co-processor (for what it's worth).
Also, for what it's worth, each compile had different problems which I
pragmatically hacked, having to do with conflicts with the libraries
on previous declarations. i can explain each of these if anyone wanted
to get into it..
anyway, here they are. Roughly, the linux system seemed to produce
about 3-4,000 dhrystones more than the 386bsd system. i would be
interested in theories on why this might be the case, and also to know
if someone has done a more careful port and measurement than i, and
also if disk speed or tcp/ip access can be measured, either.
AS 386BSD:
==========
OUTPUT OF DHRY:
Microseconds for one run through Dhrystone: 115.0
Dhrystones per Second: 8695.7
OUTPUT OF DHAMP:
Start...
cresult = 9000
iresult = 32041
uresult = 46368
lresult = 81000000
square = 0
dresult = 9000.000000
dmath = 9000.000000
copy = 1000
...End
OUTPUT OF DHRYSTON:
Dhrystone time for 50000 passes = 4
This machine benchmarks at 10714 dhrystones/second
==========
AS LINUX:
=========
OUTPUT OF DHRY:
Microseconds for one run through Dhrystone: 191.7
Dhrystones per Second: 5217.4
OUTPUT OF DHAMP:
Start...
cresult = 9000
iresult = 32041
uresult = 46368
lresult = 81000000
square = 0
dresult = 9000.000000
dmath = 9000.000000
copy = 1000
...End
OUTPUT OF DHRYSTON:
Dhrystone time for 50000 passes = 8
This machine benchmarks at 5917 dhrystones/second
=========
Path: gmd.de!newsserver.jvnc.net!yale.edu!xlink.net!
howland.reston.ans.net!usc!news.service.uci.edu!aris.ss.uci.edu!jstern
From: jst...@aris.ss.uci.edu (Jeff Stern)
Subject: Re: FYI.. benchmarks on linux and 386bsd
Nntp-Posting-Host: aris.ss.uci.edu
Message-ID: <2CB12C2F.23255@news.service.uci.edu>
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Organization: University of California, Irvine
Keywords: benchmarks speed downers uppers and other dirty laundry
Lines: 3
Date: 5 Oct 93 08:11:27 GMT
References: <2CB12A8D.17397@news.service.uci.edu>
Sorry, typo in last post.. linux produced 3-4,000 dhrystones/second
LESS than bsd. apologies.. -j
From: jfc@athena.mit.edu (John F Carr)
Crossposted-To: comp.os.386bsd.misc
Subject: Re: FYI.. benchmarks on linux and 386bsd
Date: 5 Oct 1993 11:33:06 GMT
30% is a large enough difference that it might be caused by incorrect
definition of the clock tick rate (depending on how the program measures
time). A pure CPU benchmark shouldn't change that much (unless the
cache is disabled when running Linux?).
--
John Carr (jfc@athena.mit.edu)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!pipex!
uunet!brunix!cs.brown.edu!Mark_Weaver
From: Mark_Wea...@brown.edu
Subject: Re: FYI.. benchmarks on linux and 386bsd
In-Reply-To: jstern@aris.ss.uci.edu's message of 5 Oct 93 08:04:29 GMT
Message-ID: <MARK_WEAVER.93Oct5175919@excelsior.cis.brown.edu>
Sender: n...@cs.brown.edu
Organization: Brown University Department of Computer Science
References: <2CB12A8D.17397@news.service.uci.edu>
Date: Tue, 5 Oct 1993 21:59:19 GMT
Lines: 23
In article <2CB12A8D.17...@news.service.uci.edu> jst...@aris.ss.uci.edu
(Jeff Stern) writes:
> These are two different dhrystone benchmarks, and a dhampstone
> benchmark which I compiled both under gcc (without optimization) on
> each system. To be fair, I can't remember which gcc I was running on
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the 386bsd system, the one on linux is 2.4.5. The version of bsd I
> had was 0.1, of course, with a few patches. Linux here is SLS
> 0.99.12/1.03. My box is a 386-33 Micronics with 8MB ram and 64K
> cache, no wait states, and a co-processor (for what it's worth).
> Also, for what it's worth, each compile had different problems which I
> pragmatically hacked, having to do with conflicts with the libraries
> on previous declarations. i can explain each of these if anyone wanted
> to get into it..
You you were running gcc version 1 (the default that comes with
386bsd 0.1) then that explains it. gcc2 has a significantly better
optimizer that could easily explain this kind of speed difference.
Mark
--
--------------------------------------------------------------------
Email: Mark_Wea...@brown.edu | Brown University
PGP Key: finger m...@cs.brown.edu | Dept of Computer Science
Path: gmd.de!xlink.net!howland.reston.ans.net!agate!agate.berkeley.edu!cgd
From: c...@eden.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Date: 5 Oct 93 17:46:50
Organization: Kernel Hackers 'r' Us
Lines: 15
Message-ID: <CGD.93Oct5174650@eden.CS.Berkeley.EDU>
References: <2CB12A8D.17397@news.service.uci.edu>
<MARK_WEAVER.93Oct5175919@excelsior.cis.brown.edu>
NNTP-Posting-Host: eden.cs.berkeley.edu
In-reply-to: Mark_Weaver@brown.edu's message of Tue, 5 Oct 1993 21:59:19 GMT
In article <MARK_WEAVER.93Oct5175...@excelsior.cis.brown.edu>
Mark_Wea...@brown.edu writes:
>You you were running gcc version 1 (the default that comes with
>386bsd 0.1) then that explains it. gcc2 has a significantly better
>optimizer that could easily explain this kind of speed difference.
geez, considering that 386bsd beat linux by a large percentage
with a *poorer* optimizer, i'm not sure i want to think about
with an equivalent optimizer... *chuckle*
chris
--
chris g. demetriou c...@cs.berkeley.edu
smarter than your average clam.
Path: gmd.de!xlink.net!howland.reston.ans.net!usenet.ins.cwru.edu!
cleveland.Freenet.Edu!bf703
From: bf...@cleveland.Freenet.Edu (Patrick J. Volkerding)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Date: 6 Oct 1993 06:05:38 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Lines: 23
Message-ID: <28tn7i$fl8@usenet.INS.CWRU.Edu>
References: <2CB12A8D.17397@news.service.uci.edu>
<CGD.93Oct5174650@eden.CS.Berkeley.EDU>
Reply-To: bf...@cleveland.Freenet.Edu (Patrick J. Volkerding)
NNTP-Posting-Host: hela.ins.cwru.edu
In a previous article, c...@eden.CS.Berkeley.EDU (Chris G. Demetriou) says:
>In article <MARK_WEAVER.93Oct5175...@excelsior.cis.brown.edu>
Mark_Wea...@brown.edu writes:
>>You you were running gcc version 1 (the default that comes with
>>386bsd 0.1) then that explains it. gcc2 has a significantly better
>>optimizer that could easily explain this kind of speed difference.
>
>geez, considering that 386bsd beat linux by a large percentage
>with a *poorer* optimizer, i'm not sure i want to think about
>with an equivalent optimizer... *chuckle*
>
>
386bsd doesn't have shared libraries, does it? If it does, I don't think
they're in common use. It might be more fair to make sure the Linux
binary is statically linked as well.
--
Patrick Volkerding
volke...@mhd1.moorhead.msus.edu
bf...@cleveland.freenet.edu
Path: gmd.de!xlink.net!howland.reston.ans.net!sol.ctr.columbia.edu!
news.kei.com!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!mycroft
From: mycr...@duality.gnu.ai.mit.edu (Charles Hannum)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Date: 06 Oct 1993 09:49:59 GMT
Organization: MIT Artificial Intelligence Lab
Lines: 22
Message-ID: <MYCROFT.93Oct6054959@duality.gnu.ai.mit.edu>
References: <2CB12A8D.17397@news.service.uci.edu>
NNTP-Posting-Host: duality.gnu.ai.mit.edu
In-reply-to: jstern@aris.ss.uci.edu's message of 5 Oct 93 08:04:29 GMT
In article <2CB12A8D.17...@news.service.uci.edu>
jst...@aris.ss.uci.edu (Jeff Stern) writes:
if someone has done a more careful port and measurement than i, and
also if disk speed or tcp/ip access can be measured, either.
Two things to say about this before I see any benchmark figures:
1) When diddling lots of small files or other operations on file
system metastructure, one must consider that Linux uses write-behind
for this and therefore risks serious file system corruption should the
machine crash. (Back when Linux crashed a couple of times per day for
me, I had no end of file system corruption which caused me to have to
reinstall. I assume it does not crash that often now, but this is
still a serious bug.) This also makes Linux's file systems faster.
2) I have no idea how TCP/IP performance will measure, but last I knew
Linux could not fragment packets, forcing small NFS packet sizes (and
thus *extremely* poor NFS write performance) and making it unusable as
a gateway.
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!pipex!uunet!
psinntp!dsh!gary
From: g...@dragon.dsh.org (Gary D. Duzan)
Subject: Re: FYI.. benchmarks on linux and 386bsd
Organization: Delaware State Hospital
References: <2CB12A8D.17397@news.service.uci.edu>
<CGD.93Oct5174650@eden.CS.Berkeley.EDU> <28tn7i$fl8@usenet.INS.CWRU.Edu>
Message-ID: <CEH3Dp.A7I@dragon.dsh.org>
Date: Wed, 6 Oct 1993 11:17:47 GMT
Lines: 14
In article <28tn7i$...@usenet.INS.CWRU.Edu> bf...@cleveland.Freenet.Edu
(Patrick J. Volkerding) writes:
=>
=>386bsd doesn't have shared libraries, does it? If it does, I don't think
=>they're in common use. It might be more fair to make sure the Linux
=>binary is statically linked as well.
=>
No, it is fair to compare them in the most common configuration
for each. Same goes for any disk space comparison.
Gary D. Duzan
Humble Practitioner of the Computer Arts
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!xlink.net!math.fu-berlin.de!tpki.toppoint.de!
finbol.toppoint.de!jschief
From: jsch...@finbol.toppoint.de
Subject: Re: FYI.. benchmarks on linux and 386bsd
References: <2CB12A8D.17397@news.service.uci.edu>
<CGD.93Oct5174650@eden.CS.Berkeley.EDU> <28tn7i$fl8@usenet.INS.CWRU.Edu>
<CEH3Dp.A7I@dragon.dsh.org>
Organization: myself & finsystems, a private site
Date: Wed, 6 Oct 1993 18:43:25 GMT
Message-ID: <1993Oct6.184325.11583@finbol.toppoint.de>
Lines: 39
g...@dragon.dsh.org (Gary D. Duzan) writes:
>In article <28tn7i$...@usenet.INS.CWRU.Edu> bf...@cleveland.Freenet.Edu
(Patrick J. Volkerding) writes:
>=>
>=>386bsd doesn't have shared libraries, does it? If it does, I don't think
>=>they're in common use. It might be more fair to make sure the Linux
> No, it is fair to compare them in the most common configuration
>for each. Same goes for any disk space comparison.
I can't find the testresult in my benchmark.:
My benchmachine: 486/33 MHz, Eisa, 16MB DRam
BSD0.9 : setup as latest distribution
max. 188 context switches / sek.
can't get CPU idle state less then 89%
this machine don't use free menory for buffering
Reason for this:
The machine works as NFS-Server
has one HD 1GB with 1742B controller, kernel, news, ...all on one HD
and we have to use NE2000 drivers witch don't use the interrupt
(they use polling !!!!)
because no other of our ISA-ethernet-card (WD, SMC, 3COM)
works on our Eisa-motherboard.
The most time this machine is loading executables, and data
because there is no cache, no shared libraries, no ?...
Result: The BSD0.9 is 4 times slower than my private setup with Linux.
This system might be fast, but we have no advantage,
we can only use 12% of CPU performance, and 70% of memory.
Next to do: Replace this BSD and this CPU-Platform.
Joerg
--
+++++++++++++++++++++++++++++++++++++++++++++++++++
Joerg Schlaeger jsch...@finbol.toppoint.de
24113 Kiel Tel.: ++49 431 682210 (voice)
---------------------------------------------------
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!rrz.uni-koeln.de!news.dfn.de!darwin.sura.net!
howland.reston.ans.net!pipex!uknet!cf-cm!cybaswan!iiitac
From: iii...@swan.pyr (Alan Cox)
Subject: Re: FYI.. benchmarks on linux and 386bsd
Message-ID: <1993Oct6.141627.18450@swan.pyr>
Keywords: benchmarks speed downers uppers and other dirty laundry
Organization: Swansea University College
References: <2CB12A8D.17397@news.service.uci.edu>
Date: Wed, 6 Oct 1993 14:16:27 GMT
Lines: 6
I find this hard to believe. Subjectively on a 4Mb machine I found Linux
faster however straight CPU benchmarks were within 5% for 386BSD, Linux,
SCO, Interactive 3.2 when using the same compiler.
ALan
Path: gmd.de!xlink.net!howland.reston.ans.net!sol.ctr.columbia.edu!
caen!usenet.coe.montana.edu!grapevine.lcs.mit.edu!CATFISH.LCS.MIT.EDU!metcalf
From: metc...@CATFISH.LCS.MIT.EDU (Chris Metcalf)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Date: 7 Oct 1993 13:34:48 GMT
Organization: MIT Laboratory for Computer Science
Lines: 15
Message-ID: <2915to$crd@GRAPEVINE.LCS.MIT.EDU>
References: <2CB12A8D.17397@news.service.uci.edu>
<28umsn$n4d@GRAPEVINE.LCS.MIT.EDU> <CGD.93Oct6131315@eden.cs.berkeley.edu>
NNTP-Posting-Host: catfish.lcs.mit.edu
In article <CGD.93Oct6131...@eden.cs.berkeley.edu>, Chris Demetriou wrote:
>but for {386,Free,Net}BSD, you're definitely wrong, hz is 100,
Unfortunately, dhry typically doesn't find the system-specific value of
HZ, and it will default to 60 in this case. This would have happened under
Linux (which defines only CLK_TCK, not HZ, in its include files); perhaps
*BSD defines HZ, or perhaps dhry had been built with -DHZ=100 under *BSD.
This is still the only way to explain the original discrepancy in timings.
A quick check of MIPS Ultrix 4.3, SunOS 4.1.3, NextStep 2.1 and Vax BSD 4.3
reveals that all of them use HZ=60 when returning a value via times(),
by the way; my guess at HZ in BSD was based on Vax BSD.
--
Chris Metcalf, MIT Laboratory for Computer Science
metc...@cag.lcs.mit.edu // +1 (617) 253-7766
Path: gmd.de!rrz.uni-koeln.de!unidui!math.fu-berlin.de!zib-berlin.de!
news.dfn.de!scsing.switch.ch!sun.rediris.es!polar.etsiig.uniovi.es!miguel
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Message-ID: <1993Oct7.191209.773@polar.etsiig.uniovi.es>
From: mig...@pinon.ccu.uniovi.es (Miguel Alvarez Blanco)
Date: 7 Oct 93 19:12:09 +0100
Followup-To: comp.os.386bsd.misc,comp.os.linux
References: <2915to$crd@GRAPEVINE.LCS.MIT.EDU>
Organization: Universidad de Oviedo
Nntp-Posting-Host: pinon.ccu.uniovi.es
X-Newsreader: TIN [version 1.1 PL9]
Lines: 23
Chris Metcalf (metc...@CATFISH.LCS.MIT.EDU) wrote:
: Linux (which defines only CLK_TCK, not HZ, in its include files)
Look at /usr/include/sys/<I don't remember>.h, it has both of them defined!
(at least in my Slackware distribution).
: A quick check of MIPS Ultrix 4.3, SunOS 4.1.3, NextStep 2.1 and Vax BSD 4.3
: reveals that all of them use HZ=60 when returning a value via times(),
: by the way; my guess at HZ in BSD was based on Vax BSD.
BTW, our old Convex has the HZ set to 60, too.
Oh, and another thing. Do you remember five months ago, a student's question
here in Spain as to what has one to do when nobody gives him money to buy
a C-90? I've found it, my 486DX2-66 PC with Linux has beaten (running our
application in quantum chemistry) things like that Convex 120, this HP-9000,
all of our VaxStations, some Sparcs (I don't remember the model), and watch
this! even the Cray YMP at CIEMAT in Madrid ! and I bought it for something
like 2000$
Miguel Alvarez Blanco "All that is gold does not glitter,
mig...@hobbit.quimica.uniovi.es not all those who wander are lost."
mig...@pinon.ccu.uniovi.es Bilbo Baggins.
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!pipex!uunet!
destroyer!nntp.cs.ubc.ca!uw-beaver!cmaeda
From: cma...@cs.washington.edu (Chris Maeda)
Subject: NetBSD TCP/IP network benchmarks
Message-ID: <1993Oct8.085554.9345@beaver.cs.washington.edu>
Sender: n...@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: <2CB12A8D.17397@news.service.uci.edu>
<MYCROFT.93Oct6054959@duality.gnu.ai.mit.edu>
Date: Fri, 8 Oct 93 08:55:54 GMT
Lines: 60
In article <2CB12A8D.17...@news.service.uci.edu>
jst...@aris.ss.uci.edu (Jeff Stern) writes:
>
> if someone has done a more careful port and measurement than i, and
> also if disk speed or tcp/ip access can be measured, either.
>
I've done some network throughput and latency benchmarks of NetBSD 0.8.
I don't have a box running linux, so I don't know how fast it is.
Measurements were done using 2 33 mhz 486dx boxes with 16 MB RAM and
3c503 ethernet cards. The machines were run in single user mode on a
private ethernet. The systems measured are NetBSD 0.8, Mach 2.5, a
vanilla Mach 3.0 system using the TCP/IP code in the UX unix server, a
vanilla Mach 3.0 system using the BSDSS unix server, and a Mach 3.0
system using the library-based TCP/IP implementation.*
TCP throughput was measured using ttcp (anon ftp from sgi.com in
sgi/src/ttcp) which is a 16MB one-way memory-to-memory transfer.
system codebase kbytes/s
NetBSD 0.8 BNR2 320
Mach 2.5 4.3BSD 457
Mach 3.0(UX server) 4.3BSD 415
Mach 3.0(BSDSS server) BNR2 382
Mach 3.0(library) BNR2 469
UDP latency was measured using a ping-pong test: a client bounced
packets off a server 10000 times and divided the total elapsed time by
10000. This set of benchmarks is available through anon ftp from
mach.cs.cmu.edu in src/net-latency-tools.tar.Z.
UDP round trip latency (in milliseconds)
system message size (bytes)
1 100 512 1024 1472
-------------------------------------------------------------
NetBSD 0.8 2.63 3.49 6.04 9.54 12.50
Mach 2.5 1.83 2.44 5.19 8.51 11.41
Mach 3.0(UX) 3.96 4.67 7.86 11.65 15.00
Mach 3.0(BSDSS) 4.64 5.37 8.95 13.23 16.84
Mach 3.0(library) 2.12 2.68 5.41 8.74 11.66
So NetBSD's networking performance is pretty dismal compared to Mach.
I don't know why but I imagine it has something to do with device
drivers and low level code that does context switching and stuff
because the actual network protocol code is very similar in all cases.
To be fair, no one has ever tried to tune up NetBSD.
[More details on these benchmarks and the library-based TCP/IP
implementation are in doc/published/user.level.protocols.ps on
mach.cs.cmu.edu.]
Cheers,
Chris
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!xlink.net!howland.reston.ans.net!wupost!cs.utexas.edu!
asuvax!chnews!ornews.intel.com!percy!agora!davidg
From: dav...@agora.rain.com (David Greenman)
Subject: Re: NetBSD TCP/IP network benchmarks
Message-ID: <CEnnD9.H8w@agora.rain.com>
Organization: Open Communications Forum
Date: Sun, 10 Oct 1993 00:15:07 GMT
Lines: 48
>UDP round trip latency (in milliseconds)
>
>system message size (bytes)
> 1 100 512 1024 1472
>-------------------------------------------------------------
>NetBSD 0.8 2.63 3.49 6.04 9.54 12.50
>Mach 2.5 1.83 2.44 5.19 8.51 11.41
>Mach 3.0(UX) 3.96 4.67 7.86 11.65 15.00
>Mach 3.0(BSDSS) 4.64 5.37 8.95 13.23 16.84
>Mach 3.0(library) 2.12 2.68 5.41 8.74 11.66
I just grabbed your latency benchmark program. Here is the
result (again: client=486DX2/66 w/8013, server=486DX/33 w/8013):
FreeBSD-1.0E 1.0011 1.356 2.7415 4.4723 5.9395
...and I just read your message about your board being an 8bit 3c503.
First, I'm sure you agree that the 1 byte ping test above isn't going
to be effected be the type of card that is being used, and in this case
the software is identical (the 'ed' driver supports the 80x3, 8/16bit
3c503, NE1000 and NE2000).
Now, let me say that attempting to test network performance by using
an 8bit ethernet card is rediculous. You're testing the speed that you
can write the shared memory on the board - not the networking code. A
test with the client/server being localhost would be more telling:
(486DX2/66):
ttcp-t: buflen=8192, nbuf=2048, align=16384/+0, port=5001 tcp -> localhost
ttcp-t: 16777216 bytes in 4.78 real seconds = 3430.10 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 2.39, calls/sec = 428.76
ttcp-t: 0.0user 2.7sys 0:04real 57% 0i+0d 0maxrss 0+0pf 540+1488csw
(486DX/33):
ttcp-t: buflen=8192, nbuf=2048, align=16384/+0, port=5001 tcp -> localhost
ttcp-t: 16777216 bytes in 6.05 real seconds = 2709.06 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 3.02, calls/sec = 338.63
ttcp-t: 0.0user 2.7sys 0:06real 45% 0i+0d 0maxrss 0+0pf 1184+835csw
The main reason that these figures for the two machines are so close is
that what is really being tested is the speed of main memory.
Now I could test the 8bit 3c503, but I'd have to rip my machine apart to
do it...and unless you think this is *really* important, I'm not going to
bother. I have measured it in the past, and it's performance is about 550k
per second.
-DG
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!newsserver.jvnc.net!yale.edu!yale!gumby!destroyer!
nntp.cs.ubc.ca!uw-beaver!cmaeda
From: cma...@cs.washington.edu (Chris Maeda)
Subject: Re: NetBSD TCP/IP network benchmarks
Message-ID: <1993Oct11.091056.7938@beaver.cs.washington.edu>
Sender: n...@beaver.cs.washington.edu (USENET News System)
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: <CEnnD9.H8w@agora.rain.com>
Date: Mon, 11 Oct 93 09:10:56 GMT
Lines: 12
In article <CEnnD9....@agora.rain.com> dav...@agora.rain.com (David Greenman)
writes:
>
> Now, let me say that attempting to test network performance by using
>an 8bit ethernet card is rediculous. You're testing the speed that you
>can write the shared memory on the board - not the networking code.
No, you're testing them all. I was interested in comparing the
performance differences due to operating system structure. The five
different configurations I measured had identical hardware, widely
varying software OS structure, and widely varying performance.
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!xlink.net!howland.reston.ans.net!math.ohio-state.edu!
cs.utexas.edu!convex!constellation!rex!ben
From: b...@rex.uokhsc.edu (Benjamin Z. Goldsteen)
Subject: Re: FYI.. benchmarks on linux and 386bsd
Message-ID: <CEMA3n.DuE@rex.uokhsc.edu>
Date: Sat, 9 Oct 1993 06:30:58 GMT
Reply-To: benjamin-goldst...@uokhsc.edu
References: <2915to$crd@GRAPEVINE.LCS.MIT.EDU>
<1993Oct7.191209.773@polar.etsiig.uniovi.es>
Organization: Health Sciences Center, University of Oklahoma
Lines: 52
mig...@pinon.ccu.uniovi.es (Miguel Alvarez Blanco) writes:
>Chris Metcalf (metc...@CATFISH.LCS.MIT.EDU) wrote:
>: Linux (which defines only CLK_TCK, not HZ, in its include files)
>Look at /usr/include/sys/<I don't remember>.h, it has both of them defined!
>(at least in my Slackware distribution).
>: A quick check of MIPS Ultrix 4.3, SunOS 4.1.3, NextStep 2.1 and Vax BSD 4.3
>: reveals that all of them use HZ=60 when returning a value via times(),
>: by the way; my guess at HZ in BSD was based on Vax BSD.
>BTW, our old Convex has the HZ set to 60, too.
>Oh, and another thing. Do you remember five months ago, a student's question
>here in Spain as to what has one to do when nobody gives him money to buy
>a C-90? I've found it, my 486DX2-66 PC with Linux has beaten (running our
>application in quantum chemistry) things like that Convex 120, this HP-9000,
>all of our VaxStations, some Sparcs (I don't remember the model), and watch
>this! even the Cray YMP at CIEMAT in Madrid ! and I bought it for something
>like 2000$
Lets see...a Convex 120 is a minisuper from like 1982... I think
it LINPACK's at 5 MFLOPS (and that is for vector code). I am not too
familiar with VAXstations, but I think they are <1 MFLOPS machines...
I think I have seen numbers that show a 486DX2 fairly close to some
modern SPARC's, so I am sure it can beat SPARC SLC, IPC, etc.
The only thing I know the Cray Y-MP being slow at is character
handling in C. If the code is Fortranish/floating-point intensive,
than this package needs some work... The Cray Y-MP is about 40-50
times faster (per Y-MP processor) than a 486DX2-66 running code
optimized for each. On the other hand, if this is a Cray M90 and this
code does not vectorize the results are plausible. The Cray M90 uses
70ns DRAM and (like all Cray supercomputers) has no cache.
If you need some benchmarks comparing processors there are variety
posted periodically to comp.benchmarks. If, however, we want to
compare and tune 386BSD's and Linux themselves we will have to come up
with some real tests. AIM has a set of benchmarks for this, but we
would have to pay to have them tested (that is where they make the
money -- testing).
Until we get a set of good, system-level benchmarks we can test a
few subsystems like I/O. Has anyone run Bonnie on a 386BSD and all the
various Linux filesytems under the exact same conditions (same
computer, same devices installed, same destination drive, same
cylinders, etc)? I would be interested in some numbers for IDE, VLB
IDE, SCSI, and VLB SCSI on the same computer and EISA SCSI on a similar
computer for each OS (who has that much free time and spare hardware?)
--
Benjamin Z. Goldsteen
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!pipex!uknet!
yorkohm!minster!al-b
From: a...@minster.york.ac.uk
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Message-ID: <750282279.25432@minster.york.ac.uk>
Date: 10 Oct 1993 19:44:40 GMT
References: <28tn7i$fl8@usenet.INS.CWRU.Edu> <CEH3Dp.A7I@dragon.dsh.org>
<1993Oct6.184325.11583@finbol.toppoint.de>
Organization: Department of Computer Science, University of York, England
Lines: 43
In article <1993Oct6.184325.11...@finbol.toppoint.de> jsch...@finbol.toppoint.de
writes:
[quoted articles deleted]
>
>Result: The BSD0.9 is 4 times slower than my private setup with Linux.
> This system might be fast, but we have no advantage,
> we can only use 12% of CPU performance, and 70% of memory.
>
>+++++++++++++++++++++++++++++++++++++++++++++++++++
>Joerg Schlaeger jsch...@finbol.toppoint.de
>24113 Kiel Tel.: ++49 431 682210 (voice)
>---------------------------------------------------
Time for me to join in :-)
I have a 486DX/2-66 with 16 MB RAM, Adaptec 1542C with two 250MB drives. I started
of with Linux, because I had read about it in a German magazine. Then I decided to
try 386BSD (I "emptied" a 50MB partition on the first disk).
The Tiny Bootdisk worked fine, but it always crashed when trying to access the HDD.
I have finally got the 386BSD binary distribution working, but I would not want to
run any benchmarks with it... Why not?
386BSD will only boot off the harddisk if the internal cache is disabled AND the
external cache is disabled AND the turbo button is disabled.
Linux runs at the full 66 MHz and is plenty fast for me, so I will probably get
rid of 386BSD soon. Five minutes to boot from a SCSI disk just isn't on! Linux
does it in under one minute (with all sorts of goodies in /etc/rc).
(These times are roughly from the end of the selftest)
Andrew.
+---------------------------------------------------------------------------+
| Andrew Lynch, Dept. of Computer Science, | Run, run, as fast as you can |
| University of York, York, YO1 5DD, England | you can't catch me, I'm the |
| E-mail: a...@minster.york.ac.uk (INTERNET) | ginger beard man! |
| a...@tower.york.ac.uk | |
| A...@UK.AC.YORK (JANET) | .sig by Anna Gramme |
+---------------------------------------------------------------------------+
Path: gmd.de!xlink.net!howland.reston.ans.net!agate!overload.lbl.gov!
dog.ee.lbl.gov!horse.ee.lbl.gov!torek
From: to...@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: NetBSD TCP/IP network benchmarks
Date: 11 Oct 1993 10:05:27 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
Lines: 43
Message-ID: <34594@dog.ee.lbl.gov>
References: <CEnnD9.H8w@agora.rain.com>
<1993Oct11.091056.7938@beaver.cs.washington.edu>
NNTP-Posting-Host: 128.3.112.15
In article <CEnnD9....@agora.rain.com> dav...@agora.rain.com
(David Greenman) notes that
>>... You're testing the speed that you can write the shared memory on
>>the board - not the networking code.
In article <1993Oct11.091056.7...@beaver.cs.washington.edu>
cma...@cs.washington.edu (Chris Maeda) writes:
>No, you're testing them all. I was interested in comparing the
>performance differences due to operating system structure. The five
>different configurations I measured had identical hardware, widely
>varying software OS structure, and widely varying performance.
Actually, you are both right.
Testing two (or more) different OSes for the same task on the same
hardware *does* test all the aspects of the software; but the nature
of the test affects *which* aspects figure the most strongly.
As it happens, Ethernet performance is, on reasonably fast CPUs with
anywhere near reasonably efficient networking code, a strong test of
the speed at which memory is copied and the number of copies
performed. It is also a strong test of the care taken with the
particular Ethernet device driver involved. Both of these factors show
up in the results, but in different ways.
As most modern machines can easily copy at greater-than-Ethernet
speeds, the actual throughput on such a test typically depends mainly
on the efficiency of the Ethernet driver. Excessive memory-to-memory
copies show up only as increased CPU load. That is, one system may
move 1.1 MB/s at 20% CPU load, while another may move the same 1.1 MB/s
at 80% CPU load, with the difference being due to the network system.
Contrariwise, one system might efficiently move 0.55 MB/s at 10% load
while another moves 1.1 MB/s but takes 90% of the CPU to do so.
(Note that I am not speaking specifically of any particular system, nor
even of PCs; this is a general `beware of what you are testing' sort
of comment. I made up the various percentages above, for purposes of
illustration only. Your mileage will vary. Void where prohibited.
Taxes are the sole responsibility of recipient. Warranty does not
cover deliberate misuse or acts of Goddess.)
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA Domain: to...@ee.lbl.gov
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!
europa.eng.gtefsd.com!uunet!sunic!isgate!veda.is!adam
From: a...@veda.is (Adam David)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Message-ID: <CEq8q0.M3A@veda.is>
Date: 11 Oct 93 09:51:21 GMT
References: <28tn7i$fl8@usenet.INS.CWRU.Edu> <CEH3Dp.A7I@dragon.dsh.org>
<1993Oct6.184325.11583@finbol.toppoint.de> <750282279.25432@minster.york.ac.uk>
Organization: Veda Systems, Iceland
Lines: 19
a...@minster.york.ac.uk writes:
>386BSD will only boot off the harddisk if the internal cache is disabled AND the
>external cache is disabled AND the turbo button is disabled.
To be quite frank, your motherboard is garbage. It would be possible for 386bsd
to jump through hoops (and take a performance hit) to run on it, just like I
presume Linux does, but you would be better off with a motherboard that has
working cache hardware. Sometime later, it is likely that the current versions
of *BSD will support broken hardware, but not yet.
In the meantime, make sure motherboards do caching correctly and make sure
IDE cards handle things correctly. Otherwise you will see nothing but grief.
I have been through both of these pitfalls and now have a stable *BSD system
that is running on _working_ hardware. The bad hardware cannot be returned
to the store, but someone will want to run DOS on it.
--
a...@veda.is
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!uknet!cf-cm!cybaswan!iiitac
From: iii...@swan.pyr (Alan Cox)
Subject: Re: FYI.. benchmarks on linux and 386bsd
Message-ID: <1993Oct11.123706.23431@swan.pyr>
Organization: Swansea University College
References: <1993Oct6.184325.11583@finbol.toppoint.de>
<750282279.25432@minster.york.ac.uk> <CEq8q0.M3A@veda.is>
Date: Mon, 11 Oct 1993 12:37:06 GMT
Lines: 26
In article <CEq8q0....@veda.is> a...@veda.is (Adam David) writes:
>a...@minster.york.ac.uk writes:
>
>>386BSD will only boot off the harddisk if the internal cache is disabled AND the
>>external cache is disabled AND the turbo button is disabled.
>
>To be quite frank, your motherboard is garbage. It would be possible for 386bsd
>to jump through hoops (and take a performance hit) to run on it, just like I
>presume Linux does, but you would be better off with a motherboard that has
>working cache hardware. Sometime later, it is likely that the current versions
>of *BSD will support broken hardware, but not yet.
Linux doesn't jump through any hoops. I guess BSD doesn't jump through the
proper ones. With respect to this I'd suggest the original author tries the
current NETBSD. The old 386BSD had so many bugs with device drivers and general
memory handling that have been fixed that NetBSD may well work. On the other
hand I'll stick to Linux.
>In the meantime, make sure motherboards do caching correctly and make sure
>IDE cards handle things correctly. Otherwise you will see nothing but grief.
>I have been through both of these pitfalls and now have a stable *BSD system
>that is running on _working_ hardware. The bad hardware cannot be returned
>to the store, but someone will want to run DOS on it.
Good advice for all barring IDE cards don't cause any cache problems because
neither Linux nor BSD use IDE DMA mode, and since IDE drives that support it
are as common as a live dodo.
Alan [iii...@pyr.swan.ac.uk]
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!uknet!cf-cm!
cybaswan!iiitac
From: iii...@swan.pyr (Alan Cox)
Subject: Re: NetBSD TCP/IP network benchmarks
Message-ID: <1993Oct11.124338.23859@swan.pyr>
Organization: Swansea University College
References: <CEnnD9.H8w@agora.rain.com>
<1993Oct11.091056.7938@beaver.cs.washington.edu> <34594@dog.ee.lbl.gov>
Date: Mon, 11 Oct 1993 12:43:38 GMT
Lines: 21
In article <34...@dog.ee.lbl.gov> to...@horse.ee.lbl.gov (Chris Torek) writes:
>
>Testing two (or more) different OSes for the same task on the same
>hardware *does* test all the aspects of the software; but the nature
>of the test affects *which* aspects figure the most strongly.
I dispute it checks all aspects. What bearing does disk speed have when
the disks are not even being used ? General point taken however.
>
>As most modern machines can easily copy at greater-than-Ethernet
>speeds, the actual throughput on such a test typically depends mainly
>on the efficiency of the Ethernet driver. Excessive memory-to-memory..
On a PC this is more true than usual because of the 8MHz backplane bus,
the problems with DMA behaviour and an awful lot of other related design
cockups. An 8bit ethernet card almost haves performance over a 16bit one, which
is a pretty good pointer to where the hit is both with Linux and with BSD.
>cover deliberate misuse or acts of Goddess.)
^-- Hail Eris!
>In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
>Berkeley, CA Domain: to...@ee.lbl.gov
Alan
iii...@pyr.swan.ac.uk
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!
europa.eng.gtefsd.com!uunet!elroy.jpl.nasa.gov!decwrl!pacbell.com!
amdahl!hip-hop!Belvedere!root
From: root@Belvedere%hip-hop.suvl.ca.us (David E. Fox)
Subject: Re: FYI.. benchmarks on linux and 386bsd
Followup-To: comp.os.386bsd.misc,comp.os.linux
References: <CEMA3n.DuE@rex.uokhsc.edu>
Organization: Dave's really K-Rad Linux Box
Date: Sat, 9 Oct 1993 19:13:35 GMT
X-Newsreader: TIN [version 1.1 PL8]
Message-ID: <1993Oct9.191335.3202@Belvedere%hip-hop.suvl.ca.us>
Lines: 27
Benjamin Z. Goldsteen (b...@rex.uokhsc.edu) wrote:
[ quite a bit deleted ]
: money -- testing).
: Until we get a set of good, system-level benchmarks we can test a
: few subsystems like I/O. Has anyone run Bonnie on a 386BSD and all the
: various Linux filesytems under the exact same conditions (same
What's wrong with the Byte Unix benchmark suite?
One thing I'd like to point out that in my particular experience,
floating-point sans coprocessor on 386BSD was miserably slow in
comparison to Linux. I tried a whetstone benchmark and it took over
8 minutes of wall-clock time to complete. With a coprocessor, it
took well under 1/10th of a second (rough guess). Linux doesn't show
that wide of a difference with/without a coprocessor.
I've a 386SX/16 :( with a Cyrix 83S87 :).
: Benjamin Z. Goldsteen
--
David Fox root@Belvedere%hip-hop.suvl.ca.us
5479 Castle Manor Drive
San Jose, CA 95129 Thanks for letting me change
408/253-7992 magnetic patterns on your hard disk.
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!uknet!cf-cm!
cybaswan!iiitac
From: iii...@swan.pyr (Alan Cox)
Subject: Re: FYI.. benchmarks on linux and 386bsd
Message-ID: <1993Oct13.132032.22762@swan.pyr>
Organization: Swansea University College
References: <CEMA3n.DuE@rex.uokhsc.edu>
<1993Oct9.191335.3202@Belvedere%hip-hop.suvl.ca.us>
Date: Wed, 13 Oct 1993 13:20:32 GMT
Lines: 19
In article <1993Oct9.191335.3202@Belvedere%hip-hop.suvl.ca.us>
root@Belvedere%hip-hop.suvl.ca.us (David E. Fox) writes:
>What's wrong with the Byte Unix benchmark suite?
Lots. I even mailed byte a list of comments they didnt even bother acknowledging
For example Linux is 12 times faster than SCO on the multiple shells test. When
you put the gnu sort and other utils onto SCO then Linux is 1.3 times faster.
Linux also does ridiculously well in the pipe test (faster than a big HP -
nice pipe code Linus). The result of this is the benchmark is totally
thrown when comparing Linux to att/v7 based systems. In fact it claimed my
386DX40 was almost comparable to a compaq 486/33 with coprocessor running
SCO. Now Linux is good yes but that bench mark is pure bull.
>
>One thing I'd like to point out that in my particular experience,
>floating-point sans coprocessor on 386BSD was miserably slow in
>comparison to Linux. I tried a whetstone benchmark and it took over
This is odd. They use the same coprocessor emulator.
Alan
iii...@pyr.swan.ac.uk
Path: gmd.de!xlink.net!math.fu-berlin.de!news.tu-chemnitz.de!
hrz.tu-chemnitz.de!jpo
From: j...@kappa.informatik.tu-chemnitz.de (Joerg Pommnitz)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Date: 14 Oct 1993 10:28:47 +0100
Organization: University of Technology Chemnitz, FRG
Lines: 16
Message-ID: <jpo.750590731@hrz.tu-chemnitz.de>
References: <CEMA3n.DuE@rex.uokhsc.edu>
<1993Oct9.191335.3202@Belvedere%hip-hop.suvl.ca.us> <1993Oct13.132032.22762@swan.pyr>
NNTP-Posting-Host: kappa.informatik.tu-chemnitz.de
iii...@swan.pyr (Alan Cox) writes:
>>One thing I'd like to point out that in my particular experience,
>>floating-point sans coprocessor on 386BSD was miserably slow in
>>comparison to Linux. I tried a whetstone benchmark and it took over
>This is odd. They use the same coprocessor emulator.
^^^^^^^^^^^^^^^^^^^^^^^^^
>Alan
>iii...@pyr.swan.ac.uk
No, they don't.
Bill Metzenhen (sp ?) has donated his FPUEmu to Linux. This code is much
better than the original emulator from Linus.
Joerg
Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!sunic!
news.funet.fi!klaava!klaava!not-for-mail
From: torva...@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Date: 14 Oct 1993 11:58:22 +0200
Organization: University of Helsinki
Lines: 33
Message-ID: <29j7ru$bfs@klaava.Helsinki.FI>
References: <CEMA3n.DuE@rex.uokhsc.edu>
<1993Oct9.191335.3202@Belvedere%hip-hop.suvl.ca.us>
<1993Oct13.132032.22762@swan.pyr> <jpo.750590731@hrz.tu-chemnitz.de>
NNTP-Posting-Host: klaava.helsinki.fi
In article <jpo.750590...@hrz.tu-chemnitz.de>,
Joerg Pommnitz <j...@kappa.informatik.tu-chemnitz.de> wrote:
>iii...@swan.pyr (Alan Cox) writes:
>
>>>One thing I'd like to point out that in my particular experience,
>>>floating-point sans coprocessor on 386BSD was miserably slow in
>>>comparison to Linux. I tried a whetstone benchmark and it took over
>>This is odd. They use the same coprocessor emulator.
>
>No, they don't.
>
>Bill Metzenhen (sp ?) has donated his FPUEmu to Linux. This code is much
>better than the original emulator from Linus.
Amen to that one, brother. The original linux math emulation was
written by me as a stopgap measure to get gcc working without any diffs
om machines without co-processors so that somebody else could handle the
gcc port (and somebody else did: hlu/hjl has done an admirable job, and
I've been able to ignore compiler/library issues ever since).
The current one is a totally rewritten emulator by Bill Metzenthen, and
is much faster as well as being *much* closer to the real thing. I
dumped my original emulator the day I got Bill's - I'm not so proud that
I don't know a good thing when I see it (and it has only gotten better).
I assume the 386BSD crowd are still using my original emulator due to
copyright reasons (I waived the GPL for that one, and made it "freely
available for the 386bsd project" or whatever). It's much slower, and
doesn't emulate all the instructions unless somebody else has worked
hard on it. And even the instructions it does emulate it doesn't do
completely: the math never checks for overflows or NaN's etc.
Linus
Path: gmd.de!xlink.net!howland.reston.ans.net!math.ohio-state.edu!
caen!batcomputer!munnari.oz.au!metro!sequoia!ultima!kralizec.zeta.org.au!not-for-mail
From: b...@kralizec.zeta.org.au (Bruce Evans)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Date: 15 Oct 1993 09:02:07 +1000
Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32bis
Lines: 14
Message-ID: <29klpf$8ae@kralizec.zeta.org.au>
References: <2CB12A8D.17397@news.service.uci.edu>
<MYCROFT.93Oct6054959@duality.gnu.ai.mit.edu>
NNTP-Posting-Host: kralizec.zeta.org.au
In <MYCROFT.93Oct6054...@duality.gnu.ai.mit.edu>
mycr...@duality.gnu.ai.mit.edu (Charles Hannum) writes:
>1) When diddling lots of small files or other operations on file
>system metastructure, one must consider that Linux uses write-behind
>for this and therefore risks serious file system corruption should the
>machine crash. (Back when Linux crashed a couple of times per day for
>me, I had no end of file system corruption which caused me to have to
>reinstall. I assume it does not crash that often now, but this is
>still a serious bug.) This also makes Linux's file systems faster.
A measly 10 to 20 times faster. This is one thing makes Linux "feel"
much faster (up to 10 to 20 times :-) than 386BSD.
--
Bruce Evans b...@kralizec.zeta.org.au
Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!sunic!news.funet.fi!
funic!sauna.cs.hut.fi!cs.hut.fi!hsu
From: h...@cs.hut.fi (Heikki Suonsivu)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: FYI.. benchmarks on linux and 386bsd
Date: 15 Oct 1993 18:08:53 GMT
Organization: Helsinki University of Technology, Finland
Lines: 24
Distribution: inet
Message-ID: <HSU.93Oct15200852@laphroaig.cs.hut.fi>
References: <2CB12A8D.17397@news.service.uci.edu>
<MYCROFT.93Oct6054959@duality.gnu.ai.mit.edu>
<29klpf$8ae@kralizec.zeta.org.au>
NNTP-Posting-Host: laphroaig.cs.hut.fi
In-reply-to: bde@kralizec.zeta.org.au's message of 15 Oct 1993 09:02:07 +1000
In article <29klpf$...@kralizec.zeta.org.au> b...@kralizec.zeta.org.au
(Bruce Evans) writes:
>for this and therefore risks serious file system corruption should the
...
A measly 10 to 20 times faster. This is one thing makes Linux "feel"
Personally, I would prefer that there would be per-filesystem option to set
whether you wish file system structure updates done synchronously.
Normally one wants the system be reasonably stable, but when doing large
copies of directory trees (like moving contents of one filesystem to
another) it would be nice to avoid extra cost of doing synchronous IO.
What would be even better would be a shadow paging filesystem. This would
avoid need for fsck, avoid synchronous writes (unless explicitly
requested), you could add filesystem transactions and live backups are
safer (you can take a snapshot with little cost). Properly designed this
would probably allow some performance gain, as allocation can be done
freely, write to the track the head happens to be on, if suitable space is
available.
-
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
h...@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN
/G=Heikki/S=Suonsivu/O=hut/OU=cs/PRMD=Inet/ADMD=Fumail/C=FI
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!agate!
library.ucla.edu!news.mic.ucla.edu!unixg.ubc.ca!acs.ucalgary.ca!
cpsc.ucalgary.ca!xenlink!fsa.ca!deraadt
From: dera...@fsa.ca (Theo de Raadt)
Subject: Re: FYI.. benchmarks on linux and 386bsd
In-Reply-To: hsu@cs.hut.fi's message of 15 Oct 1993 18: 08:53 GMT
Message-ID: <DERAADT.93Oct15124106@newt.fsa.ca>
Sender: n...@fsa.ca
Nntp-Posting-Host: newt.fsa.ca
Organization: little lizard city
References: <2CB12A8D.17397@news.service.uci.edu>
<MYCROFT.93Oct6054959@duality.gnu.ai.mit.edu>
<29klpf$8ae@kralizec.zeta.org.au>
<HSU.93Oct15200852@laphroaig.cs.hut.fi>
Distribution: inet
Date: Fri, 15 Oct 1993 19:41:06 GMT
Lines: 34
h...@cs.hut.fi (Heikki Suonsivu) writes:
> b...@kralizec.zeta.org.au (Bruce Evans) writes:
> >for this and therefore risks serious file system corruption should the
> >...
> >A measly 10 to 20 times faster. This is one thing makes Linux "feel"
> Personally, I would prefer that there would be per-filesystem option to set
> whether you wish file system structure updates done synchronously.
> Normally one wants the system be reasonably stable, but when doing large
> copies of directory trees (like moving contents of one filesystem to
> another) it would be nice to avoid extra cost of doing synchronous IO.
No thanks. I want reliability of my filesystems during a crash.
fsck and the filesystem are supposed to work together; the filesystem
must gaurantee that writes (especially during directory operations)
are done in a repeatable order so that fsck can figure out where in
the sequence of writes the crash occurred. fsck's purpose is simple:
it is supposed to back out of those unfinished operations.
Since BSD FFS gaurantees a cluster of related writes to be done in such
an atomic way; it is much more likely that fsck can reconstruct the
filesystem. There are gauranteed to be only a few changes in-progress.
With Linux things are different: if you have a Linux machine try this:
run both a file creation and deletion program at the same time, ie.
% rm largedir & tar xf file.tar &
when the disks are going, hit reset
Invariably, Linux will have more filesystem corruption than BSD.
An additional comment; I believe the BSD buffer cache clusters a few types
of operations that need not be clustered, I am hoping that Torek will jump
in here and give more details..
--
This space not left unintentionally unblank. dera...@fsa.ca