From owner-freebsd-hackers Sat Oct 25 04:05:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA29177 for hackers-outgoing; Sat, 25 Oct 1997 04:05:43 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA29171 for ; Sat, 25 Oct 1997 04:05:39 -0700 (PDT) (envelope-from se@X14.MI.Uni-Koeln.DE) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id NAA14757; Sat, 25 Oct 1997 13:04:04 +0200 (MET DST) Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id LAA00954; Sat, 25 Oct 1997 11:15:40 +0200 (CEST) X-Face: " Date: Sat, 25 Oct 1997 11:15:40 +0200 From: Stefan Esser To: dkelly@hiwaay.net Cc: Joe McGuckin , freebsd-hackers@FreeBSD.ORG Subject: Re: 2.2.2-RELEASE '875 SCSI won't negotiage References: <199710210124.UAA14405@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710210124.UAA14405@nospam.hiwaay.net>; from dkelly@hiwaay.net on Mon, Oct 20, 1997 at 08:24:34PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 1997-10-20 20:24 -0500, dkelly@hiwaay.net wrote: > ncr0 rev 3 int a irq 11 on pci0:11 > ncr0 waiting for scsi devices to settle > (ncr0:0:0): WIDE SCSI (16 bit) enabled(ncr0:0:0): 10.0 MB/s (200 ns, offset 15) > (ncr0:0:0): "IBM OEM DCHS09W 2222" type 0 fixed SCSI 2 > sd1(ncr0:0:0): Direct-Access > sd1(ncr0:0:0): WIDE SCSI (16 bit) enabled > sd1(ncr0:0:0): 20.0 MB/s (100 ns, offset 15) > 8689MB (17796077 512 byte sectors) This is correct for the non-Ultra version of the NCR driver (as of 2.2-stable before September 8, 1997). > Am mildly concerned about the 10.0 MB/s message that starts it off. And I'm No reason to worry! The IBM drives have certain specific features, and their active request for negotiation of a synchronous data rate is one of them. The driver does not know anything about the drive, when it initiates the negotiation, and will not go beyond 5MHz, at that stage. After the INQUIRY returned the drive name and features, and after the quirks code had a chance to limit what the driver will agree on, the driver initiates a negotiation and the final synchronous transfer parameters are agreed on. > thinking about the whole issue because I'm not certian my performance is up > to snuff. Using bonnie: > > IBM OEM DCHS09W on Asus SC875, new & empty 2.4G filesystem at end of disk: > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 3972 41.8 3986 14.6 2234 7.5 6700 76.3 8228 16.4 108.4 2.6 > ^^^^ this seems low This IS low! Seems your drive does not signal early command completion on writes, even if tags are used (or did you disable tags ?) What's the state of the WCE bit in mode page 8 ? # scsi -f /dev/sd0 -m 8 WCE: 1 [ ... having read further down, I see you DTRT WRT WCE ... ] But your other Bonnie numbers seem odd, too. Or was there much other activity on that system at the time of the test ? The "per char" input rate should only be limited by available CPU cycles, or the data rate should be no lower than in the "block" input case. Having the file system at the end of the disk does of course affect performance. > SEAGATE ST32550N on Adaptec 2940 (AIC-7870) old 86% full 1.8G fs > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 3980 43.2 4402 13.9 1774 5.0 4260 48.3 3759 5.7 71.5 1.5 > > System is an Asus P6NP5 PPro-166/512k 32M RAM. > > # scsi -f /dev/rsd1c -m 8 -P 3 > WCE: 0 > Observed the Seagate had the WCE set (Write Cache Enable) so I did the same > for the IBM. > > Flipped the WCE bit from 0 to 1 and got this on the IBM (last fs): > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 7402 76.5 7927 31.0 2311 7.8 6587 75.2 8207 16.2 110.3 2.5 > ^^^^ ^^^^ both of these are *much* better. With an assumed data rate of near 8MB/s and a 64KB transfer, you wrote 64KB in 8ms. Since Bonnie could not issue the next command in time, one revolution of the media (8.3ms) was lost, and the actual peformance was near 64KB/16ms or 4MB/s. > After enabling the write cache, this drive is comparable to the new Seagate > 4.3G Barracuda on an Adaptec 2940AU (AIC-7860) and P-133 I'm playing with > at work: > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 3653 75.6 8523 36.4 2293 15.9 3595 70.6 9183 38.4 92.2 4.3 This is obviously a file system on the outer tracks (or only a few hundred MB offset from the start of the disk). > It really bugged me that my UW HD on PentiumPro was being beat by a P-133 > with narrow SCSI. Then I began to wonder if there was a difference between Well, I beat most people's Bonnie results with my 486/133 and a 2GB Quantum Atlas connected to a NCR 53c810 for quite a while :) > inner and outer tracks. This fs starts about 200M past block 0, while the > above (up 2, the IBM) starts 2.4G from the end of the disk: > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > 100 8098 79.7 9385 38.3 2758 9.2 6426 74.0 9772 20.1 111.2 2.5 > > ...and that's more like it! Yes, it definitely is ... ;) Regards, STefan