From owner-freebsd-hackers Sun Feb 25 11:59:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA15183 for hackers-outgoing; Sun, 25 Feb 1996 11:59:01 -0800 (PST) Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA15175 for ; Sun, 25 Feb 1996 11:58:54 -0800 (PST) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (193.174.9.9) with smtp id ; Sun, 25 Feb 96 20:58 MET Received: from wavehh.UUCP by mail.hanse.de with UUCP for se@ZPR.Uni-Koeln.DE id ; Sun, 25 Feb 96 20:58 MET Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA24996; Sun, 25 Feb 96 14:39:36 +0100 Date: Sun, 25 Feb 96 14:39:36 +0100 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9602251339.AA24996@wavehh.hanse.de> To: freebsd-hackers@freebsd.org Cc: se@ZPR.Uni-Koeln.DE Subject: Re: Disk perf. with different HDs/Adapt. Newsgroups: hanse-ml.freebsd.hackers References: <199602232004.AA07830@Sysiphos> Reply-To: cracauer@wavehh.hanse.de Sender: owner-hackers@freebsd.org Precedence: bulk se@ZPR.Uni-Koeln.DE (Stefan Esser) wrote: >On Feb 23, 14:26, Rashid Karimov wrote: >} Subject: Disk perf. with different HDs/Adapt. >} 13107200 bytes transferred in 2 secs (6553600 bytes/sec) >If you report 'dd' numbers, then **please** add at least 'time' info ... >E.g.: ># time dd if=/dev/rsd0a of=/dev/null count=200 bs=64k >13107200 bytes transferred in 2 secs (6553600 bytes/sec) > 1.92 real 0.01 user 0.05 sys I think /dev/null should not be used for benchmarks. I've seen systems where it makes a substantial difference whether the data was read and just not used or where the data was sent to /dev/null because the benchmark program couldn't just discard it. Additionally, as Stefan points of, the performance numbers of dd are quite useless anyway. I suggest using the 'bonnie' benchmark, which has a nice multi-processes seek benchmark as well and does precise timing. bonnie works on filesystems only, no raw devices. But I think the filesystem numbers are more useful anyway. >} P6-200 ASUS( hate it!) with RAID array ( all in HW no >} special drivers reqd) - only 3Mb/sec ! >Well, RAID doesn't seem the way to go, if you are looking >for top performance ... Were the drives synchronized and >was a reasonable write buffer in the controller ? That's my impression, too. I didn't see any real fast *and* system-independet RAID solutions so far. >How does CCD compare ? >It was quite good according to the last values I saw ... I tested on NetBSD with two NCR Controllers and four Quantum 540 MB drives. The ccd driver turned those old junk hardisks into one 2 GB drive with max 8 MB/sec write and 7.5 MB read out of a standard BSD filesystem (but I didn't find one single configuration where both of these top numbers were possible...). One individual drive had 3.5 MB/sec. The benchmark was bonnie, that means the test is reading one large file sequentially in chunks of 8 KB. Surprisingly, it wasn't too difficult to find good value for the disk geometry. Good performance even occured when using a 64 Head/32 sectors lazy-admin scheme. These software stringing solutions with standard harddisks/controller seem to be a good way. I've seens amazing numbers from HP 7000 workstation as well (years ago) and you don't need any special hardware. My impression is that most RAID solutions are not fast and will never be because most users don't run any benchmarks on them... Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer - Fax +49 40 522 85 36 BSD User Group Hamburg, Germany - No NeXTMail anymore, please. Copyright 1995. Redistribution via Microsoft Network is prohibited