🚀 go-pugleaf

In article <1994Nov7.043425.28258@muffin.pronet.com> cas@muffin.pronet.com writes:
<mlord@bnr.ca (Mark Lord) writes:
<
<>In article <1994Nov3.231834.7897@muffin.pronet.com> cas@muffin.pronet.com writes:
<> < > < I just got a brand new (only a few weeks old) WD Caviar 540 to
..
<> < > Yeah, it will.  Just set it to 2 or 4, though, not 16.
<> <
<> < Why 2 or 4, and not 16?
<
<> Western Digital recommends settings between 4 and 8, inclusively.
<
<Thanks.  Do you know why they recommend those settings?

From "A Proposal to Implement High Speed IDE Host Transfers",
by Western Digital Corporation, October 6/1993.  Note that at this
time most of their drives had puny cache sizes of 64KB or less:

"Block PIO has the potential to both improve and hurt performance.
 Cache hits are improved due to the lowered host interrupt processing.
 Write performance is improved due to getting data into the buffer faster.
 Read performance can actually decline slightly due to the Block Mode Read
 transferring the last group of "n" sectors after reading the last sector
 into the buffer [implementation dependent -ml].  This actually extends
 the data transfer time relative to standard PIO mode.  For this reason,
 it is suggested that the blocking factor be kept small [think of similarity
 with memory cache-line size on a processor -ml].  Benchmarks that test host
 transfer rates, such as Coretest, perform better with larger blocking
 factors.  Given this trade-off, Western Digital suggests blocking factors
 between 4-8 [whereas I would suggest they optimize their algorithm somewhat,
 either using dual-port buffering (like their drives claim), or by not wasting
 performance by transferring the unnecessary/unrequested extra sectors at the
 end of the last incomplete "block" -ml]."

On my own system, my MC2112A (1Gig) IDE gives blindingly fast read performance
with settings up to 32, and then tapering off somewhat at higher settings,
probably because the transfer of a "block" cannot begin until all of the 
requested sectors of the block have been read (since PIO transfers are "blind"
in mode0).  Thus with larger block sizes, there will be increased latencies,
especially when a block spans more than one cylinder.

For writes, my MC2112A appears to incur a fixed amount of setup time depending
on the current block size setting (multsect count).  This is seen as a delay
between the issuance of the WRITE_MULTIPLE command, and the receipt of DREQ
(data request) from the drive for the first block, which *must* be polled for
(no IRQ).  Somewhat puzzling.  So I typically have a hook in my kernel to
use multiple mode only for transfers > 2 sectors.

I also happen to have a WD540MB drive, which seems to work equally well
at settings of 8 or 16 (max).  This drive has a moderate 128KB buffer/cache.

-- 
mlord@bnr.ca	Mark Lord	BNR Ottawa,Canada	613-763-7482