Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Jul 1997 01:59:35 -0400 (EDT)
From:      john hood <cgull@smoke.marlboro.vt.us>
To:        Søren Schmidt <sos@sos.freebsd.dk>
Cc:        se@FreeBSD.ORG (Stefan Esser), freebsd-current@FreeBSD.ORG
Subject:   Re: code talks:  announcing EIDE bus master patches
Message-ID:  <199707300559.BAA02894@smoke.marlboro.vt.us>
In-Reply-To: <199707292224.AAA00624@sos.freebsd.dk>
References:  <19970729221036.52544@mi.uni-koeln.de> <199707292224.AAA00624@sos.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
Søren Schmidt writes:
 > In reply to Stefan Esser who wrote:
 > > But the "per char" read performance improvement indicates
 > > what's really going on: CPU cycles spent in the interrupt
 > > handler probably account for the 4.5MB/s mark in the PIO
 > > case, while raw data rate of the disk is approached with
 > > the DMA driver.
 > 
 > Exactly!

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.

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
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

 > > But writes are still significantly slower than reads, which
 > > makes me think, that one revolution of the media is lost per
 > > 64KB written ...

Could be; the code path is more complex than would be good for best
performance.  I noticed that somebody long ago added commands to
enable read and write caches on IDE drives, and then somebody
commented them out.  What happened there?  Is it worth trying that
again, or shall we just have another long discussion about filesystem
commits and stability and recoverability and not do anything to the
code? :)

 > I think it might be some kind of interaction with the drives
 > cache, but our driver might be guilty too..
 > 
 > > > Not bad, for a "simple" software upgrade :)
 > > 
 > > True! But there is still room for improvement ... ;)
 > 
 > Well, I don't think we are going to get much more performance
 > out of it, at least not in an order like this, but there sure
 > is room for cleaning up the driver, which I'll eventually get
 > to if/when I get the time...
 >  
 > > > 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.

 > Yep. Now we only need ATA drives that can overlap commands. It seems they
 > are getting there, but its a mess still. When that settles (and we get
 > new drives :) ), we can get even a wee bit more performance...

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.

But I don't have an electrical engineering degree, and so nobody
listens to my rants about hardware. :)

  --jh

-- 
John Hood				cgull@smoke.marlboro.vt.us

Predictably, they all eventually wandered away, rubbing their bruises
and brushing mud out of their hair.  Some went off to work for the
ESA, launching much smaller rockets into low orbits, while others
elected to sit on their front porches drinking Jim Beam from the
bottle and launching bottle rockets from the empties. [Jordan Hubbard]




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707300559.BAA02894>