Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!newsroom.utas.edu.au!munnari.OZ.AU!spool.mu.edu!daily-planet.execpc.com!news.sol.net!uniserve!van-bc!news.mindlink.net!sol.ctr.columbia.edu!news.uoregon.edu!news.dacom.co.kr!usenet.seri.re.kr!news.cais.net!news.jsums.edu!gatech!news.mathworks.com!fu-berlin.de!news.belwue.de!news.uni-stuttgart.de!news.rhrz.uni-bonn.de!RRZ.Uni-Koeln.DE!zpr.uni-koeln.de!se
From: se@ZPR.Uni-Koeln.DE (Stefan Esser)
Newsgroups: comp.unix.bsd.freebsd.misc,comp.os.linux.development.system
Subject: Re: The better (more suitable)Unix?? FreeBSD or Linux
Date: 17 Feb 1996 20:09:10 GMT
Organization: Institute for Mathematics, University of Cologne, Germany
Lines: 120
Sender: se@Sysiphos (Stefan Esser)
Message-ID: <4g5cl6$q6k@news.rrz.uni-koeln.de>
References: <4er9hp$5ng@orb.direct.ca> <4fjodg$o8k@venger.snds.com> <311DA774.167EB0E7@FreeBSD.org> <31220995.C4C54C1@acm.org> <4g0sam$r6p@agate.berkeley.edu>
NNTP-Posting-Host: sysiphos.mi.uni-koeln.de
To: nickkral@america.CS.Berkeley.EDU (Nick Kralevich)
Bcc: se
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:14498 comp.os.linux.development.system:18207
In article <4g0sam$r6p@agate.berkeley.edu>, nickkral@america.CS.Berkeley.EDU (Nick Kralevich) writes:
|> The following benchmarks were done using a stabdalone i486DX33 with 16
|> MB of RAM, and Western Digital Caviar IDE drives. The Linux kernel
|> which was used was Linux 1.1.62. The BSD kernel that was used was
|> FreeBSD 2.0 Alpha, based on the 4.4 BSD Lite distribution. The block
|> size used by the BSD FFS was 4k with 1k fragments; the block size used
|> by the Linux ext2fs was 1k blocks (the ext2fs cluster code provides most
|> of the performance gains of going to 4k blocks with 1k fragments, so
|> it's unlikely that ext2fs will actually implement support for
|> fragments).
Hmm, that's a very uncommon file system structure for BSD:
There is support for 8 fragments, and if you want 1KB granularity,
you could have used the much faster 8K/1K file system. 4K/512 is
used nearly exclusively for news spool, today, and the only reason
that a 4KB block size is still supported ...
|> The first benchmark that was done is the Bonnie Benchmark. It has the
|> following stages:
|>
|> * Writes data to a file (using character I/O)
|> * Rewrites the file
|> * Writes data to the file (using block I/O)
|> * Reads the file (using character I/O)
|> * Reads the file (using block I/O)
|> * Seeks into the file
|>
|> The benchmark was done using a 60MB file (which is the limit of XiaFS, a
|> much older and by now somewhat obsolete Linux filesystems):
|>
|>
|> Char Block Rewrite Char Block Seeks
|> Write Write Read Read
|> KB/Sec KB/Sec KB/Sec KB/Sec KB/Sec /Sec
|>
|> FFS Async 710 684 401 721 888 27.6
|>
|> FFS Sync 699 677 400 710 878 27.4
|>
|> Ext2 FS 452 1237 536 397 1033 46.6
|>
|> Xia FS 440 704 380 366 895 36.0
|>
|> Note that character-oriented read()'s and write()'s are slower under
|> ext2fs, but as soon as you start doing block oriented writes, ext2fs
|> blows away the FFS --- and it doesn't much matter whether the FFS
|> filesystem was mounted with or without the async flag.
Hmm, those numbers are that low, that they don't
make any sense for a comparison at all.
Let's look at some currently posted numbers:
[I have remove the indentation of the Bonnie result
lines, since they extend beyond 80 characters, else.
FreeBSD reference numbers are given in the last set
of results below the quoted message ...]
%%%%%%%%%%%%%%%%%%%% begin quote %%%%%%%%%%%%%%%%%
% >Mine's set up for 10 MHz and is rev 0412 (whatever that means). I get
% >the following on a P90 with 16 MB RAM and 1.3.59 + patch 4 + my
% >memcpy() patch:
%
% I'd be interested in the URL to the patches, and how you quantify the
% change.
%
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 3342 84.9 3855 43.3 1305 31.5 3143 79.5 3855 47.2 53.8 5.6
%
% As a comparison :
%
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
200 1236 93.9 4750 85.8 1328 57.8 936 93.8 3222 94.6 52.9 7.6
% This is with a 1G hawk (about 3/4 the speed of the Baracuuda), on an
% i486-66; same kernel, same driver, 8MHz transfer rate, but with a 4K
% block size filesystem.
%%%%%%%%%%%%%%%%%%%%% end quote %%%%%%%%%%%%%%%%%%
[ BTW, those numbers where reported by
Robert Krawitz <rlk@sunspot.tiac.net>
and Drew Eckhardt <drew@qualcomm.com>]
Or another set of numbers (the first two on a
DX4/100 with 32MB RAM, the third on a DX2/66
with 16MB of RAM, both NCR 53c810 and Quantum
Atlas 2GB):
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
Linux/BSD 100 2208 90.6 3693 46.6 1347 28.7 1538 70.5 2946 50.5 109.8 13.3
Linux/r12 100 2267 91.5 4711 63.7 1613 37.0 1518 70.8 2855 46.9 100.8 11.8
FreeBSD 100 1532 98.2 6154 67.6 2781 56.9 1664 98.6 6224 74.1 79.2 9.1
[Linux results from: Holger Kiehl
<kiehl@t24.za-offenbach.dwd.d400.de>]
The first two lines show that the DX4 is faster
in the per char read values, and that 32MB of RAM
cache more data than 16KB in the seek column.
But if you look at the other results, you'll find
that my small DX2 outperforms the Linux DX4 easily.
Seems that the standard FFS is much faster than
even the Linux EXT2 with 4KB blocks. (See block
input, per char input and rewrite values.)
Regards, STefan
--
Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021
Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160
==============================================================================
http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>