Date: Thu, 20 Feb 1997 14:07:28 +1100 From: Bruce Evans <bde@zeta.org.au> To: msmith@atrad.adelaide.edu.au, se@freebsd.org Cc: hardware@freebsd.org Subject: Re: _big_ IDE disks? Message-ID: <199702200307.OAA16623@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa >> wdc0: unit 0 (wd0): <Maxtor 85120 A8 ->, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702200307.OAA16623>