From owner-freebsd-hardware Wed Feb 19 19:12:04 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA10397 for hardware-outgoing; Wed, 19 Feb 1997 19:12:04 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA10213; Wed, 19 Feb 1997 19:09:17 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id OAA16623; Thu, 20 Feb 1997 14:07:28 +1100 Date: Thu, 20 Feb 1997 14:07:28 +1100 From: Bruce Evans Message-Id: <199702200307.OAA16623@godzilla.zeta.org.au> To: msmith@atrad.adelaide.edu.au, se@freebsd.org Subject: Re: _big_ IDE disks? Cc: hardware@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa >> wdc0: unit 0 (wd0): , 32-bit, multi-block-16 >> wd0: 788MB (10003392 sectors), 9924 cyls, 16 heads, 63 S/T, 512 B/S >> -------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 >> 128 3858 71.8 8178 28.2 2486 14.1 4210 71.1 8280 28.1 117.0 4.7 > >Ok. Quite good performance for an (E)IDE drive ... I checked the specs for it. It really can do > 8MB/s except possibly on the inner tracks. >Bruce Evans recently pointed out, that the CPU% load actually >is 100%, but the cycles not accounted for are spent in the WD >driver's interrupt handler. This is for the per-char i/o. In PIO4 mode, transferring at 8MB/sec "only" takes 50% of the CPU. It's not quite as inefficient as putc() :-). The 28% overhead for the block mode i/o's is probably mostly for copying from the buffer cache. If the CPU is a P5/166, then i586-optimized copyout is apparently not being used. I think the overhead would be about 20% with it (I see 14% for 5MB/sec on a P5/133). >The 8MB/s on block transfers should thus correspond to some >65%CPU spent in the interrupt handler, which would mean, that Not quite that much. However, 16-bit transfers would take 100% of the CPU. >the CPU is near 100% busy doing these transfers (while there >would be some 70% of the CPU left for other processes, if the >disk was driven by a bus-master controller.) The i/o through the buffer cache will also thrash the L1 and L2 caches. As well as a 20-30% penalty for copying, there will be a delayed penalty for cache misses. This is difficult to measure. I guess it is 10-20%. The bus-mastering controller will also cause some memory access stalls. You will be lucky if it leaves 50% for other processes. >> (Just for amusement, I ran iozone without any of the go-faster options >> for the 'wd' driver enabled : >> >> Writing the 128 Megabyte file, 'iozone.tmp'...22.453125 seconds >> Reading the file...23.945312 seconds >> >> IOZONE performance measurements: >> 5977685 bytes/second for writing the file >> 5605177 bytes/second for reading the file >> >> .... so they definitely help 8) Multi-mode doesn't affect the speed much, except indirectly by reducing the number of interrupts. 16-bit transfers apparently caused saturation before 8MB/sec. >We really should be able to compare with a bus-master EIDE >driver. The PIIX3 docs (available from Intel's WWW server as >a PDF file) give enough detail, to implement DMA transfers >for that chip IMHO, so somebody should go for it ... I compared with the Linux one. The overhead was hard to measure (Linux's hdparm reported confusing (lower) speeds) but seemed to be small. Bruce