Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!lll-winken!decwrl!pa.dec.com!hollie.rdg.dec.com!smltalk.cbm.dec.com!yon
From: yon%smltalk.cbm.dec.com@decwrl.dec.com (David A. Yon)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: 550Kb/sec on IDE ST1144A???
Message-ID: <1991May9.141234.4719@hollie.rdg.dec.com>
Date: 9 May 91 14:12:34 GMT
References: <7280002@iftccu.ca.boeing.com>
Sender: news@hollie.rdg.dec.com (Mr News)
Reply-To: yon%smltalk.cbm.dec.com@decwrl.dec.com (David A. Yon)
Followup-To: comp.sys.ibm.pc.hardware
Organization: Digital Equipment Corporation
Lines: 37


Hey all,

	Seems I've found the problem with the ST1144A.  I called Seagate
yesterday and they told me to try running Coretest 2.92, since that version
handles IDE drives better.

	So I went home and ran Coretest again (that was the source of
my original Data Transfer Rate quote, by the way), to find that it was
version 2.91.  "Aha!" I thought, "wrong version!" ...and then I looked at 
the result of the benchmark... 959Kb/sec!  Huh...?  I thought about it
for second, and the disparity became clear.

	When I originally ran Coretest, the drive was partitioned the
way my dealer had done, with a single 130meg C: drive.  Call me wierd,
but I *like* having several logical drives, so I went ahead and re-
partitioned the drive despite the poor Coretest result.  And then I
never ran Coretest again until last night!

	My guess was that the repartitioning was enough to slightly change 
the logical-to-physical geometry mapping, causing an adjustment in how the
logical cylinders mapped to the physical cylinders, or perhaps moved a logical
set of clusters away from a locked-out sector.  Either of these would slow
down the DTR that Coretest reported.  In the first case, if Coretest were
reading a set of clusters that it assumed were on the same cylinder, but
actually physically resided on two adjacent cylinders (do to the geometry 
translation that usually goes on in SCSI/IDE drives), the extra head 
movement would invalidate the DTR finding.  In the second case, if the
logical clusters resided among some locked-out bad blocks, the time spent
skipping over those blocks would also cause a lower DTR to appear in the 
benchmark.

	At any rate, the drive is performing flawlessly, and blazingly fast!
Thanks to all who responded, especially the email that I got from overseas
this morning (Sweden, England, and Norway...gotta love the Internet!).

David Yon