Date: Wed, 30 Jul 1997 20:53:22 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: john hood <cgull@smoke.marlboro.vt.us> Cc: =?iso-8859-1?Q?S=F8ren_Schmidt?= <sos@sos.freebsd.dk>, freebsd-current@FreeBSD.ORG, Stefan Esser <se@FreeBSD.ORG> Subject: Re: code talks: announcing EIDE bus master patches Message-ID: <19970730205322.19889@mi.uni-koeln.de> In-Reply-To: <199707300559.BAA02894@smoke.marlboro.vt.us>; from john hood on Wed, Jul 30, 1997 at 01:59:35AM -0400 References: <19970729221036.52544@mi.uni-koeln.de> <199707292224.AAA00624@sos.freebsd.dk> <199707300559.BAA02894@smoke.marlboro.vt.us>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 30, john hood <cgull@smoke.marlboro.vt.us> wrote: > Well, bonnie reports an increase in CPU load and some increase in I/O > speed on the hack box I developed the code on, while a little > spin-loop-at-idle-priority hack i coded up shows an improvement in > available CPU that it can consume. My conclusion: bonnie's CPU load > numbers are useless, at least for IDE drives. Well, as I already wrote (and Bruce Evans explained in much detail), the PIO transfers' CPU cycles are accounted anonymously in the "interrupt" category, and can't be associated with the process that caused them ... > Here's some more useless bonnie results. These are for a system with > a K5-PR90, a "VXPro" chipset (a relabeled VIA Apollo VP-1), 32MB of > RAM and two Quantum FB1080As. > > bash-2.00$ cat bonnie.pio > -------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 > 100 2913 66.7 4432 25.9 1541 15.5 3764 55.1 4512 31.4 70.9 9.1 What's missing from 100% in the "per char" tests is mostly spent on PIO transfers. > bash-2.00$ cat bonnie.dma > -------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 > 100 3934 98.2 4290 28.0 1606 22.3 4538 86.2 4483 48.2 74.9 9.9 > > > > It has improved my worldstone by ~10% if that counts for real world use.. > > > > > > Yes, one thing that is often underestimated is the fact, > > > that while PIO mode transfers consume only a small fraction > > > of the cycles of a fast CPU, but they tend to consume them > > > exactly at the time, when the CPU is highly loaded anyway. > > But said CPU is often waiting for the disk anyway. Yes, it is. But my point was that in many applications the CPU is **not** waiting for the disk, and then PIO can have a large impact on latencies observed by the user. On a Unix system, lots of file operations are running asynchronously (writes and file read ahead). And 10% is about the performance that can be had by going from a P-133 to a P-166 (which used to be a few hundred dollars until very recently :) > Eeeugh. I think it's time for a new disk i/o standard that uses a > simple high-speed serial link and starts over on the whole command set > architecture thing. I had some hopes for Fibre Channel and SSA, but > both of those use SCSI commands if I'm not mistaken. Pardon my ignorance, but what's wrong with SCSI commands ??? Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970730205322.19889>