From owner-freebsd-scsi Tue Sep 17 19:13:24 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA15479 for freebsd-scsi-outgoing; Tue, 17 Sep 1996 19:13:24 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA15438; Tue, 17 Sep 1996 19:13:18 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id TAA09645; Tue, 17 Sep 1996 19:13:16 -0700 (PDT) Date: Tue, 17 Sep 1996 19:13:16 -0700 (PDT) Message-Id: <199609180213.TAA09645@silvia.HIP.Berkeley.EDU> To: gibbs@freebsd.org CC: scsi@freebsd.org Subject: A couple of SCSI problems From: asami@freebsd.org (Satoshi Asami) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Justin, (1) A bus reset arriving at an unfortunate time can crash the system. This is what happened when I rebooted a machine connected to another via a 2-controller SCSI chain: === ## gdb -k kernel.11 vmcore.11 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc...(no debugging symbols found)... IdlePTD 201000 current pcb at 1e81f0 panic: %s: Timed-out command times out again #0 0xf0113197 in boot () (kgdb) bt #0 0xf0113197 in boot () #1 0xf0113456 in panic () #2 0xf01d82e5 in ahc_timeout () #3 0xf010b17c in softclock () #4 0xf01b5e0c in splz_swi () #5 0xf012d72f in biowait () #6 0xf012bb3f in bread () #7 0xf019bc45 in ffs_update () #8 0xf019f25c in ffs_fsync () #9 0xf019de90 in ffs_sync () #10 0xf01328bb in sync () #11 0xf011306d in boot () #12 0xf0113456 in panic () #13 0xf01d82e5 in ahc_timeout () #14 0xf010b17c in softclock () #15 0xf01b5d87 in doreti_swi () #16 0xcf985 in ?? () #17 0xd1ae3 in ?? () #18 0xd5249 in ?? () #19 0xd5076 in ?? () #20 0x2f538 in ?? () #21 0xa6e1 in ?? () #22 0x1571b in ?? () #23 0x2e93b in ?? () #24 0x30e26 in ?? () #25 0x107e in ?? () === The crashed system was running a single "make" on a 35-disk CCD. (2) The ahc probe sometimes gets stuck right after it prints out "target foo refuses wide negotiation, using 8-bit transfers". This can happen for a variety of reasons, from loose cabling (on my home computer a while ago when the narrow SCSI connector on the CDROM was loose) to mystery (same symptom since last week, except the cable is not loose this time and I currently run the machine without CDROM) to bus resets. About bus resets: as I wrote above, one of the machines crashed when the other sent a bus reset as part of the boot process -- well, the crashed machine in turn sent a bus reset, which screwed up the booting process of the other machine, which hung, printing out this message and some other stuff (mostly incoherent, like "size: 0MB"). There are no narrow SCSI devices on this system. It booted fine when I power-cycled it. Whatever the reason, it seems like there is a minor race condition, as the symptom seems almost exactly like what used to happen before you came over to our lab and fixed a bug. What do you think, Justin? Satoshi From owner-freebsd-scsi Tue Sep 17 20:42:57 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA17584 for freebsd-scsi-outgoing; Tue, 17 Sep 1996 20:42:57 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA17550; Tue, 17 Sep 1996 20:42:51 -0700 (PDT) Message-Id: <199609180342.UAA17550@freefall.freebsd.org> To: asami@freebsd.org (Satoshi Asami) cc: gibbs@freebsd.org, scsi@freebsd.org Subject: Re: A couple of SCSI problems In-reply-to: Your message of "Tue, 17 Sep 1996 19:13:16 PDT." <199609180213.TAA09645@silvia.HIP.Berkeley.EDU> Date: Tue, 17 Sep 1996 20:42:51 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm trying to concentrate on finishing this AdvanSys driver right now and will return to aic7xxx and generic SCSI code hacking as soon as I'm done. I have a small list of things to investigate in the aic7xxx driver and this will be added to the list as well. If all goes as planned the AdvanSys driver will be completed by next weekend. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Wed Sep 18 15:12:32 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA22916 for freebsd-scsi-outgoing; Wed, 18 Sep 1996 15:12:32 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA22750; Wed, 18 Sep 1996 15:12:11 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id SAA09657; Wed, 18 Sep 1996 18:12:07 -0400 (EDT) Date: Wed, 18 Sep 1996 18:12:07 -0400 (EDT) From: Brian Tao Reply-To: FREEBSD-SCSI-L To: FREEBSD-SCSI-L , FREEBSD-CURRENT-L , FREEBSD-ISP-L Subject: Streamlogic RAID array benchmarks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I now have a P166 equipped with an Adaptec AHA-2940UW controller and a 3x4GB RAID 5 subsystem from Streamlogic (kindly lent to us by Tenex Data Systems here in Toronto). The drive comes preformatted and preconfigured with two data drives and one parity drive. It has two 68-pin wide connectors on the back and a nifty little pop-up LCD panel on the front to control various aspects of the RAID. There is also a 9-pin male serial port on the back if you want to hook up a VT-100 terminal to it. The RAID worked right out of the box. I have a narrow 4GB Barracuda plugged into the 50-pin connector on the Adaptec, and the RAID on the external 68-pin connector. The RAID drives themselves are connected via a 10MB/s narrow SCSI bus to the Streamlogic RAID controller, which then interfaces with the host via a F/W bus. It has four narrow busses, allowing for up to 28 drives per RAID controller. The GENERIC kernel recognizes this setup: FreeBSD 2.2-960801-SNAP #0: Sat Aug 3 15:18:25 1996 jkh@time.cdrom.com:/usr/src/sys/compile/GENERIC Calibrating clock(s) relative to mc146818A clock... i586 clock: 133663775 Hz, i8254 clock: 1193428 Hz CPU: Pentium (133.63-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x1bf real memory = 67108864 (65536K bytes) avail memory = 62947328 (61472K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 1 on pci0:7:0 pci0:7:1: Intel Corporation, device=0x7010, class=storage (ide) [no driver assigned] ahc0 rev 0 int a irq 11 on pci0:8 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "SEAGATE ST15150N 0022" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4095MB (8388315 512 byte sectors) (ahc0:2:0): "MICROP LTX 011000 7t38" type 0 fixed SCSI 2 sd1(ahc0:2:0): Direct-Access 8189MB (16772017 512 byte sectors) [...] All the usual tools under FreeBSD treat the RAID as a single drive. The default stripe size is 8K, RAID 5 (striping with parity). This can be changed via the LCD keypad on the unit itself, or with a VT-100 interface via the serial port. The problem I have is that it isn't particularly fast on the raw throughput tests. Granted, there is some overhead in calculating the parity, but I would expect it to go at least as fast as the single 4GB drive. Results from various benchmarks are included below. The tests were conducted on newly newfs'd filesystems. sd0 is the single 4GB drive and sd1 is the RAID. A unit from CMD should be arriving next week, so I'll have another product to benchmark. Comments welcome, and please note the Reply-To. -- 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" >>>>> Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd0s1d 2847603 4 2619791 0% /single /dev/sd1s1a 8135644 10 7484783 0% /raid Bonnie 1.0 output is shown here. The single drive easily outpaces the RAID for both linear and random accesses. -------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 raid 100 1354 25.1 1308 4.5 1056 7.3 3059 55.9 3190 11.5 139.0 5.1 single 100 3506 66.8 3429 12.0 1848 12.5 5367 99.1 6462 25.6 202.5 7.1 Iozone 2.01 from the packages collection showed a dramatic difference in favour of the non-RAID drive. It was over twice as fast as the RAID both in block reads and block writes. I'm a little suspicious of the read numbers for the single drive... I thought the ST15150N's maxed out at around 6.5MB/s (at least on narrow controllers)? I'm seeing over 8MB/s on a single drive. Does the 2940UW make that much difference even on narrow drives? The test file size was 128MB. Size is the data block size, Write and Read are in bytes per second. -------- RAID -------- ------- SINGLE ------- Size Write Read Size Write Read 256 1334877 3420921 256 3551027 7683304 512 1398101 3477002 512 3312101 8134407 1024 1410614 3519022 1024 3372569 8458822 2048 1413748 3575415 2048 3369923 8646134 4096 1414563 3585862 4096 3360694 8729608 8192 1421233 3568730 8192 3356754 8769713 16384 1419941 3554700 16384 3374556 8347847 32768 1419354 3469979 32768 3375219 8751843 65536 1420176 3408028 65536 3367281 8774192 I then ran a simple test that should take advantage of the 4MB write cache on the RAID controller. Create 10000 files in an empty directory, then retouch their inodes, then delete them all. I performed this on synchronously and asynchronously mounted filesystems on both types of drives. The RAID drive is as fast as an async-mounted single drive filesystem. Times are in min:sec. ----- RAID ----- ---- SINGLE ---- Sync Async Sync Async touch 1:42.24 1:23.95 3:57.62 1:27.80 retouch 0:12.37 0:03.24 1:23.72 0:03.26 remove 0:17.58 0:08.55 1:25.80 0:10.19 Synchronous (RAID): # time touch `jot 10000 1` 0.4u 84.6s 1:42.24 83.2% 10+170k 143+20315io 0pf+0w # time touch `jot 10000 1` 0.3u 3.6s 0:12.37 32.8% 22+193k 0+10000io 0pf+0w # time rm * 0.4u 10.0s 0:17.58 59.6% 184+252k 0+10000io 0pf+0w Asynchronous (RAID): # time touch `jot 10000 1` 0.4u 83.3s 1:23.95 99.7% 10+170k 159+315io 0pf+0w # time touch `jot 10000 1` 0.3u 3.2s 0:03.24 110.8% 22+191k 0+0io 0pf+0w # time rm * 0.2u 9.5s 0:08.55 115.2% 186+253k 0+305io 0pf+0w Synchronous (single): # time touch `jot 10000 1` 0.4u 86.9s 3:57.62 36.7% 10+170k 162+20314io 0pf+0w # time touch `jot 10000 1` 0.4u 3.8s 1:23.72 5.1% 21+191k 0+10000io 0pf+0w # time rm * 0.4u 10.4s 1:25.80 12.6% 186+251k 0+10000io 0pf+0w Asynchronous (single): # time touch `jot 10000 1` 0.4u 82.3s 1:27.80 94.3% 10+170k 159+315io 0pf+0w # time touch `jot 10000 1` 0.3u 3.2s 0:03.26 111.0% 22+191k 0+0io 0pf+0w # time rm * 0.4u 9.4s 0:10.19 96.2% 187+254k 0+305io 0pf+0w The last benchmark was to untar the contents of the /usr filesystem (15330 files, 78469120 bytes). The tar file was located on the same filesystem to which it was untarred. As in the previous benchmark, the RAID is much faster with numerous small file operations. RAID: # time tar xf usr-test.tar 1.7u 20.4s 5:02.25 7.3% 285+329k 2472+51582io 0pf+0w # time rm -rf usr 0.5u 11.3s 2:57.98 6.6% 163+569k 2132+29479io 0pf+0w Single: # time tar xf usr-test.tar 1.6u 18.0s 8:49.25 3.7% 287+329k 1995+49819io 10pf+0w # time rm -rf usr 0.5u 9.1s 4:44.14 3.4% 164+569k 2462+29479io 1pf+0w <<<<< From owner-freebsd-scsi Wed Sep 18 15:31:58 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA00734 for freebsd-scsi-outgoing; Wed, 18 Sep 1996 15:31:58 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA00572; Wed, 18 Sep 1996 15:31:31 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id RAA01314; Wed, 18 Sep 1996 17:31:29 -0500 (EST) From: "John S. Dyson" Message-Id: <199609182231.RAA01314@dyson.iquest.net> Subject: Re: Streamlogic RAID array benchmarks To: freebsd-scsi@freebsd.org Date: Wed, 18 Sep 1996 17:31:29 -0500 (EST) Cc: freebsd-current@freebsd.org, freebsd-isp@freebsd.org In-Reply-To: from "Brian Tao" at Sep 18, 96 06:12:07 pm Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Iozone 2.01 from the packages collection showed a dramatic > difference in favour of the non-RAID drive. It was over twice as fast > as the RAID both in block reads and block writes. I'm a little > suspicious of the read numbers for the single drive... I thought the > ST15150N's maxed out at around 6.5MB/s (at least on narrow > controllers)? I'm seeing over 8MB/s on a single drive. Does the > 2940UW make that much difference even on narrow drives? The test file > size was 128MB. Size is the data block size, Write and Read are in > bytes per second. > If you are running -current (I forgot to check), and since you have 64MBytes, the buffer cache will help even though it is overrun. The buffer cache policy is NOT pure LRU, and you will see the effects of it on a 64MByte system even for a 100MByte benchmark. John From owner-freebsd-scsi Wed Sep 18 19:31:30 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA07891 for freebsd-scsi-outgoing; Wed, 18 Sep 1996 19:31:30 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA07872; Wed, 18 Sep 1996 19:31:27 -0700 (PDT) Received: from post.io.org by mail.crl.com with SMTP id AA19603 (5.65c/IDA-1.5); Wed, 18 Sep 1996 19:31:54 -0700 Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id WAA11954; Wed, 18 Sep 1996 22:28:45 -0400 (EDT) Date: Wed, 18 Sep 1996 22:28:45 -0400 (EDT) From: Brian Tao To: dyson@freebsd.org Cc: FREEBSD-SCSI-L Subject: Re: Streamlogic RAID array benchmarks In-Reply-To: <199609182231.RAA01314@dyson.iquest.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 18 Sep 1996, John S. Dyson wrote: > > If you are running -current (I forgot to check), and since you have > 64MBytes, the buffer cache will help even though it is overrun. The > buffer cache policy is NOT pure LRU, and you will see the effects of > it on a 64MByte system even for a 100MByte benchmark. The tests were done on a 2.2-960801-SNAP system. Regardless, it doesn't hide the fact that the RAID had much lower throughput than the single drive. I going to try reformatting the RAID to level 0 and seeing if not having parity makes a difference (although I might as well save a few thousand dollars and just use ccd at that point). -- 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" From owner-freebsd-scsi Wed Sep 18 19:49:20 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA14883 for freebsd-scsi-outgoing; Wed, 18 Sep 1996 19:49:20 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA14848; Wed, 18 Sep 1996 19:49:12 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id VAA01096; Wed, 18 Sep 1996 21:48:59 -0500 (EST) From: "John S. Dyson" Message-Id: <199609190248.VAA01096@dyson.iquest.net> Subject: Re: Streamlogic RAID array benchmarks To: taob@io.org (Brian Tao) Date: Wed, 18 Sep 1996 21:48:59 -0500 (EST) Cc: dyson@freebsd.org, freebsd-scsi@freebsd.org In-Reply-To: from "Brian Tao" at Sep 18, 96 10:28:45 pm Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Wed, 18 Sep 1996, John S. Dyson wrote: > > > > If you are running -current (I forgot to check), and since you have > > 64MBytes, the buffer cache will help even though it is overrun. The > > buffer cache policy is NOT pure LRU, and you will see the effects of > > it on a 64MByte system even for a 100MByte benchmark. > > The tests were done on a 2.2-960801-SNAP system. Regardless, it > doesn't hide the fact that the RAID had much lower throughput than the > single drive. I going to try reformatting the RAID to level 0 and > seeing if not having parity makes a difference (although I might as > well save a few thousand dollars and just use ccd at that point). > I agree, and understand your point. Also, ccd as of today (and vn) are kind-of broken. Appear to work, but are okay until you need them (This is meant almost with humor -- but it isn't funny to some people :-()... John From owner-freebsd-scsi Wed Sep 18 20:56:46 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA13213 for freebsd-scsi-outgoing; Wed, 18 Sep 1996 20:56:46 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (wck-ca11-10.ix.netcom.com [204.31.231.170]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA13097; Wed, 18 Sep 1996 20:56:28 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id UAA23889; Wed, 18 Sep 1996 20:56:08 -0700 (PDT) Date: Wed, 18 Sep 1996 20:56:08 -0700 (PDT) Message-Id: <199609190356.UAA23889@silvia.HIP.Berkeley.EDU> To: dyson@freebsd.org CC: taob@io.org, dyson@freebsd.org, freebsd-scsi@freebsd.org In-reply-to: <199609190248.VAA01096@dyson.iquest.net> (toor@dyson.iquest.net) Subject: Re: Streamlogic RAID array benchmarks From: asami@freebsd.org (Satoshi Asami) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * I agree, and understand your point. Also, ccd as of today (and * vn) are kind-of broken. Appear to work, but are okay until * you need them (This is meant almost with humor -- but it isn't * funny to some people :-()... I agree. The problem is, I can't it to fail here! :( Satoshi From owner-freebsd-scsi Thu Sep 19 00:10:56 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA11723 for freebsd-scsi-outgoing; Thu, 19 Sep 1996 00:10:56 -0700 (PDT) Received: from sasami.jurai.net (root@sasami.jurai.net [206.151.208.162]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA11578; Thu, 19 Sep 1996 00:10:38 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.7.5/8.7.3) with SMTP id CAA15277; Thu, 19 Sep 1996 02:11:51 -0500 (CDT) Date: Thu, 19 Sep 1996 02:11:50 -0500 (CDT) From: "Matthew N. Dodd" To: Brian Tao cc: FREEBSD-SCSI-L , FREEBSD-CURRENT-L , FREEBSD-ISP-L Subject: Re: Streamlogic RAID array benchmarks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk You said you only had 4 meg of write cache on the Streamlogic. I'd be intrested to see the same tests run with 16 or 32 megs of R/W cache on the RAID. I know the CMD 5400s and 5300s support 128m of RAM, and the 5500 supports 512 meg. More RAM should change those numbers a bit. | Matthew N. Dodd | winter@jurai.net | http://www.jurai.net/~winter | | Technical Manager | mdodd@intersurf.net | http://www.intersurf.net | | InterSurf Online | "Welcome to the net Sir, would you like a handbasket?"| From owner-freebsd-scsi Thu Sep 19 01:17:03 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA10317 for freebsd-scsi-outgoing; Thu, 19 Sep 1996 01:17:03 -0700 (PDT) Received: from gargoyle.carpe.net (root@gargoyle.carpe.net [194.162.243.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA10179; Thu, 19 Sep 1996 01:16:36 -0700 (PDT) Received: from helva.grefen.carpe.net (helva.grefen.carpe.net [194.162.243.129]) by gargoyle.carpe.net (8.7.4/8.7.3) with ESMTP id KAA01437; Thu, 19 Sep 1996 10:19:24 +0200 (MET DST) Received: from hex.grefen.carpe.net (root@hex [194.162.243.130]) by helva.grefen.carpe.net (8.7.5/8.7.3) with ESMTP id KAA04849; Thu, 19 Sep 1996 10:21:02 +0200 (MET DST) Received: from hex.grefen.carpe.net (grefen@localhost [127.0.0.1]) by hex.grefen.carpe.net (8.7.3/8.7.3) with ESMTP id KAA03416; Thu, 19 Sep 1996 10:20:59 +0200 (MET DST) To: FREEBSD-SCSI-L Cc: FREEBSD-CURRENT-L , FREEBSD-ISP-L Subject: Re: Streamlogic RAID array benchmarks Reply-To: grefen@carpe.net In-reply-to: Brian Tao's message of Wed, 18 Sep 96 18:12:07 EDT. References: Date: Thu, 19 Sep 1996 10:20:56 +0200 Message-ID: <3409.843121256@hex.grefen.carpe.net> From: Stefan Grefen Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message Brian Tao wrote: [...] > > All the usual tools under FreeBSD treat the RAID as a single > drive. The default stripe size is 8K, RAID 5 (striping with parity). > This can be changed via the LCD keypad on the unit itself, or with a > VT-100 interface via the serial port. > > The tests were conducted on newly newfs'd filesystems. sd0 is the > single 4GB drive and sd1 is the RAID. A unit from CMD should be > arriving next week, so I'll have another product to benchmark. > Comments welcome, and please note the Reply-To. You see the benefits of a RAID array only if you access it with stripe-block size or multiple of it. Especially writes suffer from bad performance if you write fractions of a stripe-block (since it first has to read the the remainder of it or the parity block (or both) depending on implementation and where the fractional access occurred). This gives you a high latency which is results in poor performance at least for single-stream access. I assume from your statements that they use the 3 disks as "Data Data Parity" not as a 'true' RAID 5 "Data Data Data Data Parity" (this would have other side effects too). Assuming that 'stripe size is 8K' means that it has 4K blocks on each drive, Every request <8K is SLOW. (it can also mean 8k blocks on each drive which will demand 16k blocks, the phrase 'stripe size' is used different by different vendors). Some of the RAID drives can be configured to complete the SCSI operation when the block is in memory instead when it is commited to disk. This has the same effect as a disk write buffer (with the disadvanatge that it isn't written in case of a power failure). This can't be turned of on some CMD arrays (the recommend to only use it with an UPS). You need to newfs your filesystem to at least 8 (or 16k) blocksize in the default configuration. This ensures that the majority of writes are as fast as possible. If you have large files and writes you can go for even bigger blocksizes. If you have lots of small files reduce the RAID block to the minimum value and use smaller blocksizes. For 'normally' used filesystems a 1-1 mapping of stripe-blocks to filesystem blocks gives (on most systems) the best overall performance. (You have to balance bandwidth versus latency). On the other hand if the Seagate uses a write buffer and tagged queuing and the RAID doesn't it'll loose on any non purely sequential access. To figure out how fast the RAID can go just dd a huge file (/dev/zero) to and from the raw partition with different blocksizes. $ time dd if=/dev/zero of=/dev/rsd1a bs=4196 count=5120 # this will be SLOW $ time dd if=/dev/zero of=/dev/rsd1a bs=8192 count=10240 $ time dd if=/dev/zero of=/dev/rsd1a bs=16384 count=5120 ... Another good test is to talk to Arrays Cache (turn on every bit of performance switch you can find regardless of data-security) and write as above with the minmum possible request size to it. (512). This gives you the upper-limit on scsi-transaction the drives can handle on your bus. (don't be suprised if it maxes out at 500 (250 k) or so :-) )). Stefan > -- > 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" > > -- Stefan Grefen Am Grossberg 16, 55130 Mainz, Germany grefen@carpe.net +49 6131 998566 Fax:+49 6131 998568 Living on Earth may be expensive, but it includes an annual free trip around the Sun. From owner-freebsd-scsi Thu Sep 19 10:30:24 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA08853 for freebsd-scsi-outgoing; Thu, 19 Sep 1996 10:30:24 -0700 (PDT) Received: from ns.frihet.com (root@frihet.bayarea.net [205.219.92.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA08732; Thu, 19 Sep 1996 10:29:59 -0700 (PDT) Received: from ns.frihet.com (tweten@localhost [127.0.0.1]) by ns.frihet.com (8.7.5/8.6.12) with ESMTP id KAA06675; Thu, 19 Sep 1996 10:29:20 -0700 (PDT) Message-Id: <199609191729.KAA06675@ns.frihet.com> X-Mailer: exmh version 1.6.7 5/3/96 Reply-To: "David E. Tweten" To: grefen@carpe.net cc: FREEBSD-SCSI-L , FREEBSD-CURRENT-L , FREEBSD-ISP-L Subject: Re: Streamlogic RAID array benchmarks Date: Thu, 19 Sep 1996 10:29:20 -0700 From: "David E. Tweten" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk grefen@carpe.net said: >I assume from your statements that they use the 3 disks as "Data >Data Parity" not as a 'true' RAID 5 "Data Data Data Data Parity" >(this would have other side effects too). If I read this right, it is an interesting, though incorrect, interpretation of the meaning of the various levels of RAID. Garth Gibson's definition, in the original RAID paper written while he was a Berkeley PhD. student, required that RAID 5 have no disk devoted exclusively either to data or to parity. Instead, the responsibility for parity rotated through all disks in the array as a function of sequential block on disk. That way the potential for concentrating parity block accesses on one disk could be avoided in the presence of small writes. Small writes can be handled by reading all the blocks in a parity group that aren't going to be written and combining all data blocks to get a new parity block. They can also be handled by reading (or remembering) the original data and reading the original parity, followed by combining old data, new data, and old parity to get new parity. The statistical effect of it all is to generate more disk traffic for "the parity disk". The "5" had nothing to do with the number of disks. The numbers, 1 through 5 had everything to do with various disk array architectures. If my memory can be trusted (a dubious proposition), it went something like this: RAID 1 mirroring (ie, write the same block on n disks) RAID 2 bitwise SECDED (eg., Thinking Machines Data Vault) RAID 3 multi-disk array with dedicated parity disk RAID 4 ? (something truly awful that I can't remember) RAID 5 multi-disk array with rotating parity assignment So, while designating three disks as "data, data, parity" is certainly not RAID 5, neither is designating five disks as "data, data, data, data, parity". They are both RAID 3 architecture. -- David E. Tweten | 2047-bit PGP Key fingerprint: | tweten@frihet.com 12141 Atrium Drive | E9 59 E7 5C 6B 88 B8 90 | tweten@and.com Saratoga, CA 95070-3162 | 65 30 2A A4 A0 BC 49 AE | (408) 446-4131 Those who make good products sell products; those who don't, sell solutions. From owner-freebsd-scsi Fri Sep 20 00:19:03 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA25433 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 00:19:03 -0700 (PDT) Received: from gargoyle.carpe.net (root@gargoyle.carpe.net [194.162.243.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA25263; Fri, 20 Sep 1996 00:18:45 -0700 (PDT) Received: from helva.grefen.carpe.net (helva.grefen.carpe.net [194.162.243.129]) by gargoyle.carpe.net (8.7.4/8.7.3) with ESMTP id JAA04536; Fri, 20 Sep 1996 09:19:25 +0200 (MET DST) Received: from hex.grefen.carpe.net (root@hex [194.162.243.130]) by helva.grefen.carpe.net (8.7.5/8.7.3) with ESMTP id JAA07099; Fri, 20 Sep 1996 09:21:21 +0200 (MET DST) Received: from hex.grefen.carpe.net (grefen@localhost [127.0.0.1]) by hex.grefen.carpe.net (8.7.3/8.7.3) with ESMTP id JAA06410; Fri, 20 Sep 1996 09:21:19 +0200 (MET DST) To: "David E. Tweten" Cc: FREEBSD-SCSI-L , FREEBSD-CURRENT-L , FREEBSD-ISP-L Subject: Re: Streamlogic RAID array benchmarks Reply-To: grefen@carpe.net In-reply-to: "David E. Tweten"'s message <199609191729.KAA06675@ns.frihet.com> of Thu, 19 Sep 96 10:29:20 PDT. References: <199609191729.KAA06675@ns.frihet.com> Date: Fri, 20 Sep 1996 09:21:17 +0200 Message-ID: <6407.843204077@hex.grefen.carpe.net> From: Stefan Grefen Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199609191729.KAA06675@ns.frihet.com> "David E. Tweten" wrote: > grefen@carpe.net said: > >I assume from your statements that they use the 3 disks as "Data > >Data Parity" not as a 'true' RAID 5 "Data Data Data Data Parity" > >(this would have other side effects too). > > If I read this right, it is an interesting, though incorrect, > interpretation of the meaning of the various levels of RAID. It didn't wanted to imply that the parity is always on the same disk. As "Data Data Data Data Parity" on a 3 disk system rotes the parity through the disks !!. [...] Stefan -- Stefan Grefen Am Grossberg 16, 55130 Mainz, Germany grefen@carpe.net +49 6131 998566 Fax:+49 6131 998568 Living on Earth may be expensive, but it includes an annual free trip around the Sun. From owner-freebsd-scsi Fri Sep 20 02:19:55 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA20671 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 02:19:55 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA20646 for ; Fri, 20 Sep 1996 02:19:42 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id LAA17660 for ; Fri, 20 Sep 1996 11:19:06 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id LAA16560 for freebsd-scsi@freebsd.org; Fri, 20 Sep 1996 11:25:59 +0200 Date: Fri, 20 Sep 1996 11:25:59 +0200 From: Christoph Kukulies Message-Id: <199609200925.LAA16560@gilberto.physik.rwth-aachen.de> To: freebsd-scsi@freebsd.org Subject: TLZ04 (DAT) problem Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It used to work in 1.1.5.1 and I haven't used it for quite a log time. Today I wanted to do a rdump from another machine and got the following: This is what is detected during boot: Sep 20 11:07:13 escunix /kernel: (aha0:3:0): "DEC TLZ04 1989(C)DEC 1915" type 1 removable SCSI 2 And this is the error: Sep 20 11:12:37 escunix /kernel: st0(aha0:3:0): ABORTED COMMAND asc:4e,0 Overlap ped commands attempted Sep 20 11:12:42 escunix /kernel: st0(aha0:3:0): timed out Any clues? Is it perhaps a consequence of bad media? --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-scsi Fri Sep 20 03:34:25 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA25084 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 03:34:25 -0700 (PDT) Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA24946 for ; Fri, 20 Sep 1996 03:34:07 -0700 (PDT) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.7.6/8.7.3) id MAA06639 for freebsd-scsi@freebsd.org; Fri, 20 Sep 1996 12:33:45 +0200 (SAT) From: John Hay Message-Id: <199609201033.MAA06639@zibbi.mikom.csir.co.za> Subject: Adaptec AHA2940AU anyone? To: freebsd-scsi@freebsd.org Date: Fri, 20 Sep 1996 12:33:45 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL24 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I got an AHA2940AU with my PPro-200 by mistake. I actually ordered an AHA2940UW which I know is supported by FreeBSD. Because it will take a while to get it replaced (they are out of stock at the moment), I decided to give it a try. It was easy to get it to work, but I have a problem that when I do a reboot, the Adaptec BIOS don't see the disk anymore. Even a reset is not good enough. I have to power cycle the machine before the BIOS will see the disk again. Do any of you have an idea where I can look to see what is going wrong, or should I just return the card? I had a look on Adaptec's web site, but I can't find any reference to this card. BTW The patch is against 2.1.5, but the code in -current look the same. John -- John Hay -- John.Hay@mikom.csir.co.za *** pci/aic7870.c.org Sat Jun 8 09:10:57 1996 --- pci/aic7870.c Mon Sep 16 21:22:17 1996 *************** *** 81,86 **** --- 81,87 ---- #define PCI_DEVICE_ID_ADAPTEC_3940U 0x82789004ul #define PCI_DEVICE_ID_ADAPTEC_2944U 0x84789004ul #define PCI_DEVICE_ID_ADAPTEC_2940U 0x81789004ul + #define PCI_DEVICE_ID_ADAPTEC_2940AU 0x61789004ul #define PCI_DEVICE_ID_ADAPTEC_3940 0x72789004ul #define PCI_DEVICE_ID_ADAPTEC_2944 0x74789004ul #define PCI_DEVICE_ID_ADAPTEC_2940 0x71789004ul *************** *** 211,216 **** --- 212,220 ---- case PCI_DEVICE_ID_ADAPTEC_2940U: return ("Adaptec 2940 Ultra SCSI host adapter"); break; + case PCI_DEVICE_ID_ADAPTEC_2940AU: + return ("Adaptec 2940A Ultra SCSI host adapter"); + break; case PCI_DEVICE_ID_ADAPTEC_2944: return ("Adaptec 2944 SCSI host adapter"); break; *************** *** 259,264 **** --- 263,269 ---- case PCI_DEVICE_ID_ADAPTEC_3940U: case PCI_DEVICE_ID_ADAPTEC_2944U: case PCI_DEVICE_ID_ADAPTEC_2940U: + case PCI_DEVICE_ID_ADAPTEC_2940AU: case PCI_DEVICE_ID_ADAPTEC_3940: case PCI_DEVICE_ID_ADAPTEC_2944: case PCI_DEVICE_ID_ADAPTEC_2940: *************** *** 340,345 **** --- 345,351 ---- break; case PCI_DEVICE_ID_ADAPTEC_2944U: case PCI_DEVICE_ID_ADAPTEC_2940U: + case PCI_DEVICE_ID_ADAPTEC_2940AU: ahc_t = AHC_294U; break; case PCI_DEVICE_ID_ADAPTEC_2944: From owner-freebsd-scsi Fri Sep 20 07:27:01 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA29066 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 07:27:01 -0700 (PDT) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA29041 for ; Fri, 20 Sep 1996 07:26:57 -0700 (PDT) Received: by iworks.InterWorks.org (1.37.109.8/16.2) id AA21855; Fri, 20 Sep 1996 09:27:30 -0500 Message-Id: <9609201427.AA21855@iworks.InterWorks.org> Date: Fri, 20 Sep 1996 09:27:30 -0500 From: "Daniel M. Eischen" To: freebsd-scsi@FreeBSD.org, jhay@mikom.csir.co.za Subject: Re: Adaptec AHA2940AU anyone? Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I got an AHA2940AU with my PPro-200 by mistake. I actually ordered an > AHA2940UW which I know is supported by FreeBSD. Because it will take > a while to get it replaced (they are out of stock at the moment), I > decided to give it a try. > > It was easy to get it to work, but I have a problem that when I do > a reboot, the Adaptec BIOS don't see the disk anymore. Even a reset > is not good enough. I have to power cycle the machine before the BIOS > will see the disk again. > > Do any of you have an idea where I can look to see what is going wrong, > or should I just return the card? I had a look on Adaptec's web site, > but I can't find any reference to this card. I know of someone with the same exact problem with the Linux aic7xxx driver. Only a cold reboot will cause his disk to be seen. My first thought was that the disk drive wasn't jumpered correctly. It doesn't seem that is the case, though. Does this card have a BIOS? Some 7850 controllers do not have a BIOS (the 7860 is just an Ultra version of the 7850 - only 3 SCBs too). Is the card set to reset the SCSI bus at chip reset? Any peculiar options in BIOS? It sounds like these cards could have a bug in the firmware. Do you have any other operating systems on the system, and do they behave the same way when warm rebooted? Dan Eischen deischen@iworks.InterWorks.org From owner-freebsd-scsi Fri Sep 20 10:29:34 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA22539 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 10:29:34 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA22512; Fri, 20 Sep 1996 10:29:31 -0700 (PDT) Message-Id: <199609201729.KAA22512@freefall.freebsd.org> To: John Hay cc: freebsd-scsi@freebsd.org Subject: Re: Adaptec AHA2940AU anyone? In-reply-to: Your message of "Sat, 20 Sep 1996 12:33:45 +0200." <199609201033.MAA06639@zibbi.mikom.csir.co.za> Date: Fri, 20 Sep 1996 10:29:30 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Hi, > >I got an AHA2940AU with my PPro-200 by mistake. I actually ordered an >AHA2940UW which I know is supported by FreeBSD. Because it will take >a while to get it replaced (they are out of stock at the moment), I >decided to give it a try. > >It was easy to get it to work, but I have a problem that when I do >a reboot, the Adaptec BIOS don't see the disk anymore. Even a reset >is not good enough. I have to power cycle the machine before the BIOS >will see the disk again. Do you have the Adaptec BIOS sending the start unit command to your drive? I've heard that Quantum has started shipping new drives with the jumper for delayed start enabled, so this could be your problem. >BTW The patch is against 2.1.5, but the code in -current look the >same. I'll look into incorperating your patch sometime this weekend. Its not 100% correct as the 2940AU uses an aic7860 and may need to be treated different than the aic7870 and aic7880 chips on the real 2940s. >John >-- >John Hay -- John.Hay@mikom.csir.co.za > >*** pci/aic7870.c.org Sat Jun 8 09:10:57 1996 >--- pci/aic7870.c Mon Sep 16 21:22:17 1996 >*************** >*** 81,86 **** >--- 81,87 ---- > #define PCI_DEVICE_ID_ADAPTEC_3940U 0x82789004ul > #define PCI_DEVICE_ID_ADAPTEC_2944U 0x84789004ul > #define PCI_DEVICE_ID_ADAPTEC_2940U 0x81789004ul >+ #define PCI_DEVICE_ID_ADAPTEC_2940AU 0x61789004ul > #define PCI_DEVICE_ID_ADAPTEC_3940 0x72789004ul > #define PCI_DEVICE_ID_ADAPTEC_2944 0x74789004ul > #define PCI_DEVICE_ID_ADAPTEC_2940 0x71789004ul >*************** >*** 211,216 **** >--- 212,220 ---- > case PCI_DEVICE_ID_ADAPTEC_2940U: > return ("Adaptec 2940 Ultra SCSI host adapter"); > break; >+ case PCI_DEVICE_ID_ADAPTEC_2940AU: >+ return ("Adaptec 2940A Ultra SCSI host adapter"); >+ break; > case PCI_DEVICE_ID_ADAPTEC_2944: > return ("Adaptec 2944 SCSI host adapter"); > break; >*************** >*** 259,264 **** >--- 263,269 ---- > case PCI_DEVICE_ID_ADAPTEC_3940U: > case PCI_DEVICE_ID_ADAPTEC_2944U: > case PCI_DEVICE_ID_ADAPTEC_2940U: >+ case PCI_DEVICE_ID_ADAPTEC_2940AU: > case PCI_DEVICE_ID_ADAPTEC_3940: > case PCI_DEVICE_ID_ADAPTEC_2944: > case PCI_DEVICE_ID_ADAPTEC_2940: >*************** >*** 340,345 **** >--- 345,351 ---- > break; > case PCI_DEVICE_ID_ADAPTEC_2944U: > case PCI_DEVICE_ID_ADAPTEC_2940U: >+ case PCI_DEVICE_ID_ADAPTEC_2940AU: > ahc_t = AHC_294U; > break; > case PCI_DEVICE_ID_ADAPTEC_2944: > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Fri Sep 20 12:27:19 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA01948 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 12:27:19 -0700 (PDT) Received: from sunrise.cs.berkeley.edu (root@sunrise.CS.Berkeley.EDU [128.32.38.121]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA01812; Fri, 20 Sep 1996 12:27:07 -0700 (PDT) Received: (from asami@localhost) by sunrise.cs.berkeley.edu (8.7.5/8.6.12) id MAA14507; Fri, 20 Sep 1996 12:24:09 -0700 (PDT) Date: Fri, 20 Sep 1996 12:24:09 -0700 (PDT) Message-Id: <199609201924.MAA14507@sunrise.cs.berkeley.edu> To: freebsd-scsi@freebsd.org CC: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-isp@freebsd.org In-reply-to: (message from Brian Tao on Wed, 18 Sep 1996 18:12:07 -0400 (EDT)) Subject: Re: Streamlogic RAID array benchmarks From: asami@freebsd.org (Satoshi Asami) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > -------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 >raid 100 1354 25.1 1308 4.5 1056 7.3 3059 55.9 3190 11.5 139.0 5.1 >single 100 3506 66.8 3429 12.0 1848 12.5 5367 99.1 6462 25.6 202.5 7.1 Just FYI, we've seen close to 30MB/s with ccd (no mirroring). You need two 2940?W's (or one 3940?W) and at least four disks though. Satoshi From owner-freebsd-scsi Fri Sep 20 16:16:34 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA17951 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 16:16:34 -0700 (PDT) Received: from gargoyle.carpe.net (root@gargoyle.carpe.net [194.162.243.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA17920 for ; Fri, 20 Sep 1996 16:16:29 -0700 (PDT) Received: from helva.grefen.carpe.net (helva.grefen.carpe.net [194.162.243.129]) by gargoyle.carpe.net (8.7.4/8.7.3) with ESMTP id BAA06264; Sat, 21 Sep 1996 01:19:27 +0200 (MET DST) Received: from hex.grefen.carpe.net (root@hex [194.162.243.130]) by helva.grefen.carpe.net (8.7.5/8.7.3) with ESMTP id BAA07424; Sat, 21 Sep 1996 01:15:02 +0200 (MET DST) Received: from hex.grefen.carpe.net (grefen@localhost [127.0.0.1]) by hex.grefen.carpe.net (8.7.3/8.7.3) with ESMTP id BAA07555; Sat, 21 Sep 1996 01:14:59 +0200 (MET DST) To: "Daniel M. Eischen" Cc: freebsd-scsi@FreeBSD.org, jhay@mikom.csir.co.za Subject: Re: Adaptec AHA2940AU anyone? Reply-To: grefen@carpe.net In-reply-to: "Daniel M. Eischen"'s message <9609201427.AA21855@iworks.InterWorks.org> of Fri, 20 Sep 96 09:27:30 CDT. References: <9609201427.AA21855@iworks.InterWorks.org> Date: Sat, 21 Sep 1996 01:14:58 +0200 Message-ID: <7551.843261298@hex.grefen.carpe.net> From: Stefan Grefen Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message <9609201427.AA21855@iworks.InterWorks.org> "Daniel M. Eischen" wrote: > > I know of someone with the same exact problem with the Linux aic7xxx > driver. Only a cold reboot will cause his disk to be seen. My first > thought was that the disk drive wasn't jumpered correctly. It doesn't > seem that is the case, though. I've seen the same thing with UNIXWARE 2.1, a Fujitsu drive and a normal 2940 (albeit only sporadic). > > It sounds like these cards could have a bug in the firmware. Do you > have any other operating systems on the system, and do they behave > the same way when warm rebooted? All other drives (inlcuding another Fujitsu) did act on the reset and worked ok. Someone with a SCSI-analyser must have a look at this I fear. Stefan > > Dan Eischen > deischen@iworks.InterWorks.org -- Stefan Grefen Am Grossberg 16, 55130 Mainz, Germany grefen@carpe.net +49 6131 998566 Fax:+49 6131 998568 Living on Earth may be expensive, but it includes an annual free trip around the Sun. From owner-freebsd-scsi Fri Sep 20 18:06:29 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA26309 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 18:06:29 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA26272; Fri, 20 Sep 1996 18:06:26 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30) id SAA25861; Fri, 20 Sep 1996 18:06:21 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id SAA19669; Fri, 20 Sep 1996 18:01:52 -0700 (PDT) Message-Id: <199609210101.SAA19669@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: asami@freebsd.org (Satoshi Asami) cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: Streamlogic RAID array benchmarks In-reply-to: Your message of Fri, 20 Sep 96 12:24:09 -0700. <199609201924.MAA14507@sunrise.cs.berkeley.edu> Date: Fri, 20 Sep 1996 18:01:51 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> -------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 >>raid 100 1354 25.1 1308 4.5 1056 7.3 3059 55.9 3190 11.5 139.0 5.1 >>single 100 3506 66.8 3429 12.0 1848 12.5 5367 99.1 6462 25.6 202.5 7.1 >Just FYI, we've seen close to 30MB/s with ccd (no mirroring). You >need two 2940?W's (or one 3940?W) and at least four disks though. Just for our edification, what kind of CPU did you use? Also For Everyones' Information, you won't get close to that on a real filesystem unless you use a Pentium or better. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-scsi Fri Sep 20 18:44:21 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA20811 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 18:44:21 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA20765; Fri, 20 Sep 1996 18:44:16 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.6/8.6.9) id SAA13100; Fri, 20 Sep 1996 18:43:44 -0700 (PDT) Date: Fri, 20 Sep 1996 18:43:44 -0700 (PDT) Message-Id: <199609210143.SAA13100@silvia.HIP.Berkeley.EDU> To: michaelv@MindBender.serv.net CC: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-isp@freebsd.org In-reply-to: <199609210101.SAA19669@MindBender.serv.net> (michaelv@MindBender.serv.net) Subject: Re: Streamlogic RAID array benchmarks From: asami@freebsd.org (Satoshi Asami) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * >Just FYI, we've seen close to 30MB/s with ccd (no mirroring). You * >need two 2940?W's (or one 3940?W) and at least four disks though. * * Just for our edification, what kind of CPU did you use? * * Also For Everyones' Information, you won't get close to that on a real * filesystem unless you use a Pentium or better. Yeah, it's a P5 (133MHz). We got pretty much the same result with the P6 (200MHz) too (which is kinda surprising, given that their memory system is so much slower). Satoshi P.S. http://now.cs.berkeley.edu/Td/bcopy.html for more on the memory thing. From owner-freebsd-scsi Fri Sep 20 18:52:58 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA26168 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 18:52:58 -0700 (PDT) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA26139 for ; Fri, 20 Sep 1996 18:52:55 -0700 (PDT) Received: by iworks.InterWorks.org (1.37.109.8/16.2) id AA24992; Fri, 20 Sep 1996 20:53:32 -0500 Message-Id: <9609210153.AA24992@iworks.InterWorks.org> Date: Fri, 20 Sep 1996 20:53:32 -0500 From: "Daniel M. Eischen" To: grefen@carpe.net Subject: Re: Adaptec AHA2940AU anyone? Cc: freebsd-scsi@FreeBSD.org, jhay@mikom.csir.co.za Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > I know of someone with the same exact problem with the Linux aic7xxx > > driver. Only a cold reboot will cause his disk to be seen. My first > > thought was that the disk drive wasn't jumpered correctly. It doesn't > > seem that is the case, though. > > I've seen the same thing with UNIXWARE 2.1, a Fujitsu drive and a normal > 2940 (albeit only sporadic). Hmm. > > It sounds like these cards could have a bug in the firmware. Do you > > have any other operating systems on the system, and do they behave > > the same way when warm rebooted? > > All other drives (inlcuding another Fujitsu) did act on the reset and worked > ok. The only thing I can think of is that we think the driver isn't correctly picking up the SCSI bus reset flag correctly. The code looks like it correctly sets the reset bus flag. Boot with verbose (-v) and see if you get the message "Resetting Channel A" when warm booting. Dan Eischen deischen@iworks.InterWOrks.org From owner-freebsd-scsi Fri Sep 20 21:11:53 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA01641 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 21:11:53 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA01616; Fri, 20 Sep 1996 21:11:47 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30) id VAA29382; Fri, 20 Sep 1996 21:11:53 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id VAA20862; Fri, 20 Sep 1996 21:11:37 -0700 (PDT) Message-Id: <199609210411.VAA20862@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: asami@freebsd.org (Satoshi Asami) cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: Streamlogic RAID array benchmarks In-reply-to: Your message of Fri, 20 Sep 96 18:43:44 -0700. <199609210143.SAA13100@silvia.HIP.Berkeley.EDU> Date: Fri, 20 Sep 1996 21:11:37 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > * >Just FYI, we've seen close to 30MB/s with ccd (no mirroring). You > * >need two 2940?W's (or one 3940?W) and at least four disks though. > * > * Just for our edification, what kind of CPU did you use? > * > * Also For Everyones' Information, you won't get close to that on a real > * filesystem unless you use a Pentium or better. >Yeah, it's a P5 (133MHz). We got pretty much the same result with the >P6 (200MHz) too (which is kinda surprising, given that their memory >system is so much slower). How is that surprising? The SCSI controller lives on the other side of the bus, and does the bus-mastering irrespective of the CPU. The CPU does not do bcopies for bus-mastering SCSI transfers. The problems with the 486 is that its slowness causes too great a latency between when work becomes available, and when it has something ready to keep the disk subsystem working, causing less than 100% efficiency. If all have a (working) PCI bus, what happens on the SCSI controller side should not be affected by the CPU, except for how busy the CPU can keep the SCSI controller. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-scsi Fri Sep 20 21:30:28 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA09101 for freebsd-scsi-outgoing; Fri, 20 Sep 1996 21:30:28 -0700 (PDT) Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA09059; Fri, 20 Sep 1996 21:30:21 -0700 (PDT) Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.6/8.6.9) id VAA14425; Fri, 20 Sep 1996 21:29:42 -0700 (PDT) Date: Fri, 20 Sep 1996 21:29:42 -0700 (PDT) Message-Id: <199609210429.VAA14425@silvia.HIP.Berkeley.EDU> To: michaelv@MindBender.serv.net CC: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-isp@freebsd.org In-reply-to: <199609210411.VAA20862@MindBender.serv.net> (michaelv@MindBender.serv.net) Subject: Re: Streamlogic RAID array benchmarks From: asami@freebsd.org (Satoshi Asami) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * >Yeah, it's a P5 (133MHz). We got pretty much the same result with the * >P6 (200MHz) too (which is kinda surprising, given that their memory * >system is so much slower). * * How is that surprising? The SCSI controller lives on the other side * of the bus, and does the bus-mastering irrespective of the CPU. The * CPU does not do bcopies for bus-mastering SCSI transfers. It does, because this is a bufferred I/O. We were measuring this through the filesystem, remember? An interesting sidenote of this is that when we were using the same P5-133 with the regular (rep/movsl) copyin/copyout, we got only about 20MB/s. We changed it to the Pentium-optimized copy, and managed to push it up close to 30MB/s. The slow bcopy can move about 40MB/s, the fast one 80MB/s. However, the P6-200, despite its 45MB/s bcopy speed, gives us the same 30MB/s through the filesystem. (For those you like math, 45MB/s is 22.2ns/byte, and 30MB/s is 33.3ns/B, and given that the max transfer rate on of 33MHz PCI is 132MB/s, or 7.5 ns/B, this is really close to the limit (22.2 + 7.5 = 29.7 =~ 33.3)....) Satoshi P.S. Doing parallel reads from raw devices, I could get about 65MB/s on the P5...haven't tried that on the P6. From owner-freebsd-scsi Sat Sep 21 08:31:01 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA21680 for freebsd-scsi-outgoing; Sat, 21 Sep 1996 08:31:01 -0700 (PDT) Received: from deacon.cogsci.ed.ac.uk (deacon.cogsci.ed.ac.uk [129.215.144.7]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA21635 for ; Sat, 21 Sep 1996 08:30:55 -0700 (PDT) From: richard@cogsci.ed.ac.uk Received: from pitcairn.cogsci.ed.ac.uk (pitcairn.cogsci.ed.ac.uk [129.215.197.19]) by deacon.cogsci.ed.ac.uk (8.6.10/8.6.12) with ESMTP id QAA05607 for ; Sat, 21 Sep 1996 16:30:53 +0100 Date: Sat, 21 Sep 1996 16:30:52 +0100 Message-Id: <9295.199609211530@pitcairn.cogsci.ed.ac.uk> To: freebsd-scsi@freebsd.org Subject: HP T4000s tape drive Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've just got an HP (Colorado) T4000s tape drive working under FreeBSD 2.1.0. It's a SCSI QIC-3095 drive, 4GB uncompressed. The main change required is that the PF bit in mode select must be set to one. Is a "quirk" the right way to do this? I haven't yet looked at the -current code to see how the SCSI code has changed since 2.1.0. The other changes are to increase SCSI_2_MAX_DENSITY_CODE from 0x17 (not essential, since you can't change the density of this drive) and add a SCSI_SILENT flag to the scsi_prevent call in st_mount_tape(). -- Richard From owner-freebsd-scsi Sat Sep 21 13:40:26 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA08160 for freebsd-scsi-outgoing; Sat, 21 Sep 1996 13:40:26 -0700 (PDT) Received: from phoenix.csie.nctu.edu.tw (root@phoenix.csie.nctu.edu.tw [140.113.17.171]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA08125 for ; Sat, 21 Sep 1996 13:40:18 -0700 (PDT) Received: from FreeBSD.csie.NCTU.edu.tw (freebsd.csie.nctu.edu.tw [140.113.235.250]) by phoenix.csie.nctu.edu.tw (8.7.5/8.7.5) with ESMTP id EAA04304 for ; Sun, 22 Sep 1996 04:37:53 +0800 (CST) Received: (from jdli@localhost) by FreeBSD.csie.NCTU.edu.tw (8.7.6/8.7.3) id EAA27543 for freebsd-scsi@freebsd.org; Sun, 22 Sep 1996 04:39:36 +0800 (CST) From: Jian-Da Li Message-Id: <199609212039.EAA27543@FreeBSD.csie.NCTU.edu.tw> Subject: Jaztool for FreeBSD, anyone ? To: freebsd-scsi@freebsd.org Date: Sun, 22 Sep 1996 04:39:36 +0800 (CST) X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi : I tried to port jaztool (http://www.cnct.com/~bwillmot/jaztool/) for linux to freebsd without success since I don't know ioctl() and scsi_command at all. I just hang the scsi bus nicely. :) This tool use ioctl() with scsi_command, I felt that it should be very easy to port. Is there anyone who know about these and is willing to help, or just tell me which files to take as examples in freebsd-source and let me try and error , hang and reboot :) There is also a Ziptool (http://www.torque.net/ziptool.html) which is similar with jaztool, but I don't have Zip. Thanks. -- 李 建 達 (Jian-Da Li) 交 大 資 工 E-Mail : http://www.csie.nctu.edu.tw/~jdli