Date: Sun, 13 Oct 1996 01:32:23 -0400 (EDT) From: Brian Tao <taob@io.org> To: FREEBSD-SCSI-L <freebsd-scsi@freebsd.org> Cc: jeff@openstore.com Subject: RAID benchmarks: CMD and RAIDION Message-ID: <Pine.NEB.3.92.961013012655.29152V-100000@zap.io.org>
next in thread | raw e-mail | index | archive | help
This is a followup to some RAID benchmark results I had posted
three weeks ago. The host system and disk subsystems have changed, so
I redid the iozone, bonnie and touch benchmarks.
The three contenders are a wide Seagate 5400 rpm 1GB Hawk drive, a
CMD-5500 RAID controller with 5 narrow Seagate 7200 rpm 4GB Barracuda
drives, and a Streamlogic RAIDION LT RAID controller with 3 narrow
Micropolis 4GB drives (I was unable to get specifics on the drives
themselves).
The CMD-5500 controller has 64MB of RAM, of which about 62MB is
usable as write-back cache. The RAIDION has 8MB of RAM, of which
about 5.5MB is usable as write-back cache (I mistakenly said it only
had 4MB in my previous post). Read-ahead was turned off on both
RAIDs. The RAIDs and the Seagate Hawk are hooked up to an Adaptec
2940UW controller on a 200-MHz Pentium Pro host with 128MB. There
were no special SCSI tweaks made to the kernel, other than including
the ahc driver.
>>>>>
FreeBSD 2.2-960801-SNAP #0: Tue Sep 24 06:28:45 EDT 1996
root@install1.io.org:/mnt/sys/compile/BEAST
Calibrating clock(s) relative to mc146818A clock...
i586 clock: 199307170 Hz, i8254 clock: 1193171 Hz
CPU: Pentium Pro (199.30-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x617 Stepping=7
Features=0xf9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,<b11>,MTRR,PGE,MCA,CMOV>
real memory = 134217728 (131072K bytes)
avail memory = 130293760 (127240K bytes)
Probing for devices on PCI bus 0:
chip0 <generic PCI bridge (vendor=8086 device=1237 subclass=0)> rev 2 on pci0:0
chip1 <generic PCI bridge (vendor=8086 device=7000 subclass=1)> rev 1 on pci0:1:0
pci0:1:1: Intel Corporation, device=0x7010, class=storage (ide) [no driver assigned]
de0 <Digital DC21140 Fast Ethernet> rev 18 int a irq 10 on pci0:10
de0: SMC 9332 DC21140 [10-100Mb/s] pass 1.2
de0: address 00:00:c0:07:06:e7
de0: enabling 10baseT port
ahc0 <Adaptec 2940 Ultra SCSI host adapter> rev 0 int a irq 11 on pci0:11
ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs
ahc0 waiting for scsi devices to settle
(ahc0:1:0): "SEAGATE ST31230W 0300" type 0 fixed SCSI 2
sd0(ahc0:1:0): Direct-Access 1010MB (2069860 512 byte sectors)
sd0(ahc0:1:0): with 3992 cyls, 5 heads, and an average 103 sectors/track
(ahc0:2:0): "OSS INFINITY A4-1" type 0 fixed SCSI 2
sd1(ahc0:2:0): Direct-Access 8191MB (16775168 512 byte sectors)
sd1(ahc0:2:0): with 16382 cyls, 16 heads, and an average 64 sectors/track
(ahc0:3:0): "MICROP LTX 011000 7t38" type 0 fixed SCSI 2
sd1(ahc0:3:0): Direct-Access 8189MB (16771841 512 byte sectors)
sd1(ahc0:3:0): with 8189 cyls, 64 heads, and an average 32 sectors/track
<<<<<
There was a problem when both RAIDs were daisychained together.
The boot manager would only see a single bootable disk (even though
both were fdisked as "startable"). Pressing F1 to boot the first disk
(presumably the Seagate Hawk) would hang the boot manager for about 30
seconds, then the F1 prompt would reappear. That's why both RAID
units appear as sd1 (I only hooked one up at a time). Dunno if anyone
has seen that particular problem before...
Although the CMD-5500 shipped with five 4GB drives, I only
allocated three of them for the comparison tests. Filesystem size is
approximately 8GB, RAID 5 (parity staggered across all drives), 64K
block size. The RAIDION's maximum block size is 64K, the CMD's is
512K.
The benchmark results displayed below are iozone on a 256MB file,
bonnie on a 256MB file, and the timed output for the following command
line:
time touch `jot 10000` ; time touch `jot 10000` ; time rm `jot 10000`
I'm working with the RAIDION vendor now to figure out why their
product has such a poor showing in the sequential throughput tests. ;-)
Turning the RAIDION down to RAID 0, same block size, results in a
small increase in performance (~1.3MB/s write, ~6.3MB/s read). This
is probably due to having three disks dedicated to reading and
writing rather than any overhead save from the calculation of parity.
The CMD has a load monitor on its R3000-based CPU. Interestingly,
it was doing more work at RAID 0 (~33% idle) than it was at RAID 5
(~65% idle). The on-site tech figures the parity calculation is
actually handled by an ASIC, and not the CPU itself. With all five
drives in RAID 0, I was able to sustain a 100% load on the CPU,
pumping ~14MB/s writing and ~11MB/s reading. CMD claims a peak of
17MB/s (with many more disks and fast/wide disks, I imagine).
Both have utilities accessible via a 9600 bps VT100 terminal. The
CMD one is far more comprehensive, with performance and environmental
monitoring (updated in real time) and lots of status reports on the
health of the system.
That's about all I have to say right now; the numbers pretty much
speak for themselves (especially the file creation and deletion...
write-back cache helps *immensely* here). For those interested in
buying a RAID product, you are looking at between $750 to $1250 US per
gigabyte of storage for a system that offers you protection through
parity, online spares, hot swappable drives, etc. Pretty hefty
premium, but then compare that to the cost of losing several gigabytes
of mail spool...
I'd be interested if someone could provide similar benchmarks with
a Mylex or a DPT RAID controller.
>>>>>
BLOCK ---- SINGLE ---- --- RAIDION --- ----- CMD -----
SIZE WRITE READ WRITE READ WRITE READ
512 3518302 5572451 988854 5132149 7573228 8915344
1024 3536771 5746736 992367 5044742 7531726 9344503
2048 3531319 5796177 999846 5084305 7515253 9557646
4096 3511111 5800090 1000895 5069303 7313694 9447274
8192 3570955 5811863 996541 5261022 7543301 9528490
16384 3553597 5592405 997640 5036607 7530076 9554988
32768 3566508 5808916 1000982 5053645 7403520 9447274
65536 3580631 5802049 981398 5100911 7578239 9541721
131072 3516861 5740016 976545 5037346 7454922 9344503
262144 3448734 5249769 971327 5057365 7335554 9263882
-------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
single 256 3473 29.0 3555 7.6 1659 5.4 4782 44.6 3716 5.6 105.2 2.0
raidion 256 985 8.2 954 1.9 772 2.2 4754 44.3 5110 5.6 120.8 1.7
cmd 256 7213 59.4 7176 16.1 3521 11.1 7328 68.4 6136 6.7 187.8 2.7
SINGLE
touch: 0.277u 56.454s 3:54.02 24.2% 10+170k 166+20314io 14pf+0w
retouch: 0.193u 2.796s 1:49.61 2.7% 17+190k 2+10000io 0pf+0w
unlink: 0.199u 4.792s 1:52.40 4.4% 167+226k 1+10000io 6pf+0w
RAIDION
touch: 0.245u 57.470s 1:16.07 75.8% 10+171k 159+20314io 15pf+0w
retouch: 0.174u 2.797s 0:11.59 25.5% 16+176k 2+10000io 0pf+0w
unlink: 0.171u 4.838s 0:13.55 36.9% 160+216k 1+10000io 3pf+0w
CMD
touch: 0.192u 56.159s 1:08.75 81.9% 10+169k 166+20314io 29pf+0w
retouch: 0.187u 2.764s 0:09.25 31.7% 16+185k 1+10000io 0pf+0w
unlink: 0.216u 4.757s 0:11.07 44.8% 164+220k 2+10000io 0pf+0w
<<<<<
--
Brian Tao (BT300, taob@io.org, taob@ican.net)
Senior Systems and Network Administrator, Internet Canada Corp.
"Though this be madness, yet there is method in't"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.92.961013012655.29152V-100000>