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>
index | next in thread | raw e-mail
>> 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. Brucehome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702200307.OAA16623>