From owner-freebsd-current Fri Nov 1 04:14:18 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA23939 for current-outgoing; Fri, 1 Nov 1996 04:14:18 -0800 (PST) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA23896 for ; Fri, 1 Nov 1996 04:13:41 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr2-48.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA16785 (5.67b/IDA-1.5 for ); Fri, 1 Nov 1996 13:12:35 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id MAA00737; Fri, 1 Nov 1996 12:23:38 +0100 (MET) Message-Id: <199611011123.MAA00737@x14.mi.uni-koeln.de> Date: Fri, 1 Nov 1996 12:22:18 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: dkelly@hiwaay.net (David Kelly) Cc: jgrosch@superior.truenorth.org (Josef Grosch), current@FreeBSD.org, roberto@keltia.freenix.fr, jlemon@americantv.com, jgrosch@sirius.com, michaelv@MindBender.serv.net Subject: Re: SCSI and IDE (was Re: 2.1.5r -> current upgrade) In-Reply-To: ; from David Kelly on Nov 1, 1996 01:12:00 -0600 References: X-Mailer: Mutt 0.45 Mime-Version: 1.0 Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk David Kelly writes: > > System simply has some unused hardware removed from GENERIC but > none of the changes since the SNAP: > FreeBSD 2.2-961014-SNAP #0: Wed Oct 30 12:12:30 CST 1996 > dkelly@PeeCee.tbe.com:/usr/src/sys/compile/PEECEE > > Speaking of SCSI, I was playing today with IDE and SCSI on my new > AMD 586/133 PCI MB. The SCSI is on a 2940, bios rev 1.10 or so: > > (ahc0:0:0): "SEAGATE ST3610N 9290" type 0 fixed SCSI 2 > sd0(ahc0:0:0): Direct-Access 510MB (1046206 512 byte sectors) > > The IDE is an old mode 0 drive on the MB EIDE controller: > > wdc0: unit 0 (wd0): > wd0: 486MB (996912 sectors), 989 cyls, 16 heads, 63 S/T, 512 B/S > On the IDE drive: > PeeCee: {872} time iozone 32 > [snip] > IOZONE performance measurements: > 1188424 bytes/second for writing the file > 2111586 bytes/second for reading the file > 0.2u 10.8s 0:44.54 24.7% 69+750k 374+542io 0pf+0w > > Now on to the SCSI drive: > PeeCee: {873} cd /usr1 > PeeCee: {874} time iozone 32 > [snip] > IOZONE performance measurements: > 3455323 bytes/second for writing the file > 4149726 bytes/second for reading the file > 0.2u 10.9s 0:18.17 61.5% 26+281k 363+533io 0pf+0w > ^^^^ this is the interesting part. > > Notice how both took the same amount of system time? > (nit pickers: SCSI took 0.1 second longer.) > > I'm disappointed. A bit. Hmmm, I wasn't ... The real test is to have some other program running in the background, and to measure how much the disk accesses slow it down. My guess is, that most of the CPU overhead required to deal with the IDE drive is not accounted to that process, since it will occur within an interrupt handler. And looking at the real time reported, it seems obvious that the SCSI drive took only 40% of the time required by the IDE drive to complete the same task. (Neither of the drives is "modern", and both were designed for typical desktop PC use.) Do a "make world" on both drives, and report the difference ... > BTW, tried a 1542CF first thing after upgrading to the SNAP > and upgrading the MB from a 486DX33 that wouldn't host a bus > master card. Iozone reported thruput about the same as the IDE. > Didn't think to do the "time" part. And I don't think I'm > interested enough to take it apart and put the 1542CF back in. The AH1540 was a nice card, when it came out some 10 years ago. I installed one in a project were a i386/25 PC became a machine capable of supporting 8 users, most working on accounting. It made a world of a difference compared to the same system with EIDE drives on a dumb controller (which could not deal with a multi- user load, since too much of the CPU went into data transfers). But an IDE drive (even at PIO 0) connected to a P5 will be faster than the AH1542. The ISA bus limits it severely, and the 8085 on the 1542 card is not a very fast SCSI protocol processor. But again: If you need to keep I/O load offloaded from the CPU, then bus-master SCSI does a good job of it. Even if it did not result in a shorter real-time taken. But since disk I/O is often correlated to a high CPU load (think about doing a large compile) the cycles spent on I/O are lost for data processing and lead to a longer real-time. Regards, STefan