🚀 go-pugleaf

In article <1994Nov1.231848.22798@muffin.pronet.com> cas@muffin.pronet.com writes:
<I just got a brand new (only a few weeks old) WD Caviar 540 to replace
<my ancient Maxtor SCSI drive which finally died.  Does anyone know
<whether enabling multimode will benefit me or not?

Yeah, it will.  Just set it to 2 or 4, though, not 16.

<2.  hdparm -t crashes?
<
<When I first installed hdparm, I enabled 16 sector multimode, then ran
<"hdparm -t" whilst compiling a new version of the kernel in another VC.
<I didn't expect any meaningful results (because of the disk thrashing
<caused by the compile) but I also certainly didn't expect the system to
<lock up.  All disk activity ceased, but I was still able to switch
<consoles.  Couldn't do anything so eventually had to press the reset
<button.

I noticed something similar with older kernels (I'm using 1.1.61 right now)
back around 1.0.9 and the early 1.1.x series.  Seems to have gone away now.
It looked very much like a bug somewhere in the buffer management code.
-- 
mlord@bnr.ca	Mark Lord	BNR Ottawa,Canada	613-763-7482

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
<> < replace my ancient Maxtor SCSI drive which finally died.  Does
<> < anyone know whether enabling multimode will benefit me or not?
<
<> 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.
-- 
mlord@bnr.ca	Mark Lord	BNR Ottawa,Canada	613-763-7482

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
> < > < replace my ancient Maxtor SCSI drive which finally died.  Does
> < > < anyone know whether enabling multimode will benefit me or not?
> <
> < > 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?  I'm not
questioning what you're saying, I just like to know the WHY of things
as well as the WHAT - if I know why, then i can figure out the what
myself...


-- 
cas@muffin.apana.org.au

    "Organise a strike in your school or workplace on the grounds that it
     does not satisfy your need for indolence & spiritual beauty."
                              -- Hakim Bey, The Temporary Autonomous Zone

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