Date: Sat, 17 Oct 1998 10:37:34 +0200 From: Andreas Braukmann <braukmann@tse-online.de> To: hardware@FreeBSD.ORG Subject: Re: IBM DDRS-39130 drive Message-ID: <19981017103734.L10960@paert.tse-online.de> In-Reply-To: <Pine.BSF.4.00.9810161514510.23004-100000@super-g.inch.com>; from spork on Fri, Oct 16, 1998 at 03:16:00PM -0400 References: <199810160432.VAA09147@austin.polstra.com> <Pine.BSF.4.00.9810161514510.23004-100000@super-g.inch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Fri, Oct 16, 1998 at 03:16:00PM -0400, spork wrote:
> Searching dejanews I've yet to find any negative comments on this
> or other IBM drives,
I'm hoping you won't find any, because our boxes are completely
stuffed with IBM drives. (mainly DCAS 4.3 GB and this exactly
DDRS 9 GB drive)
> Hopefully they get along with the CMD controller.
They do so far with our CMD 5440.
I don't have really valuable results wether regarding 'real RAID'-
benchmarks nor real stresstests. But nonetheless:
The machine: Dual PPro 166/512, Intel-Board PR440FX, 256 MB RAM
running 3.0-pretty-current-with-cam
SCSI-Host: onboard Adaptec 7880 UW
RAID: CMD 5440 with 64 MB Cache (4 SCSI-Channels)
5 x IBM DDRS-39130W S92A across 2 drive-channels
as an RAID-5 raid-set.
The set is divided into two redundancy sets (each ca. 17 GB)
(two ca. 9GB filesystems on each)
The bonnies:
First, a single bonnie on the first red.-set's first filesystem:
>haendel# bonnie -s 1024 -d .
>File './Bonnie.360', size: 1073741824
>Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
> -------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
> 1024 10397 97.9 9172 39.1 3857 20.3 5243 57.0 6025 20.1 147.7 6.0
Then, three bonnies (one GByte each) in parallel; two of them on the
same filesystem as the first test and the third on the first filesystem
of the second redundancy-set. (hmm, they're ponding on the same drives
anyways, but I suppose that the drives have to seek a heck more ...)
The three runs are overlapping a little bit (easy to recognize by a look
at the seek-results), because I just startet them by hitting return in
three shell-windows.
> -------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
>1-of-3 1024 5510 59.2 6099 29.8 1606 11.3 1731 20.4 2562 9.9 76.2 3.3
>2-of-3 1024 5451 58.5 5887 28.2 1380 9.8 2219 26.0 2581 10.0 74.7 3.4
>3-of-3 1024 6672 69.2 5538 23.4 1506 10.9 2449 28.3 2923 10.6 150.3 6.2
>'sum' 17633 17524 4492 6449 8066
Ahh. The stripe-size is 128 kByte (from memory).
The server provides file- and compute-services for our web-developers.
A definately backdraw of the CMD-controllers is, that they only accept
as few as 32 (sic!) tagged commands. That was really bad news for me,
I wasn't able to extract this from the technical docs or any sales- / tech-
representive.
After switching to CAM, I noted the cam-console-message
> (da2:ahc0:0:14:0): tagged openings now 32
Shortly after that David Greenman stated in a discussion regarding the
selection of an RAID-controller for ftp.cdrom.com:
DG> I had, too, chosen the CMD until I found out that it only supports 32
DB> tagged commands total. Maximally configured (45 drives), this means that
DB> not only would the CMD controller be unable to queue more than one command
DB> per disk, but in fact 1/3 of the disk drives would be completely idle at
DB> any given time.
hmmm. Since the load on our server will surely be not in class of 'ftp.cdrom.com' I currently suppose, that I can live with that.
-ab
--
/// TSE TeleService GmbH | Gsf: Arne Reuter |
/// Hovestrasse 14 | Andreas Braukmann | We do it with
/// D-48351 Everswinkel | HRB: 1430, AG WAF | FreeBSD/SMP
/// -------------------------------------------------------------------
/// PGP-Key: http://www.tse-online.de/~ab/public-key
/// Key fingerprint: 12 13 EF BC 22 DD F4 B6 3C 25 C9 06 DC D3 45 9B
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981017103734.L10960>