[comp.sys.ibm.pc.hardware] 550Kb/sec on IDE ST1144A???

yon%smltalk.cbm.dec.com@decwrl.dec.com (David A. Yon) (05/08/91)

Hey all,

	I've just purchased a 33Mhz 386 clone, which included a 124meg IDE
drive (the Seagate ST1144A) with a generic IDE controller.  In the course
of researching this purchase (calling Gateway, Treasure Chest, etc) I was
qouted data transfer rates of around 1.0-1.2mb/sec on IDE drives.  Yet
with this drive I'm only getting around 550Kb/sec!

	I purchased from a local dealer at a computer show, and when I called
him about this problem, he said that he had never seen IDE drives do much
more than 550Kb/sec.

	Now, I'm upgrading from a 12mhz 286 which had the ST296N/ST-02 SCSI
combination, and I was getting 808Kb/sec out of that.  (granted I've improved
the access time from 28ms to 20ms, but I'm not sure which will have a larger
effect on the performance).

	So...

	1) Does anyone have this combination?  What are your experiences?

	2) Does anyone know the typical performance of IDE drives/controllers?
	   Would the setup of the IDE card matter (there were precious few 
	   jumpers on the card)

	3) Does anyone know what a jumper labeled "IRQ 14 buffered/unbuffered" on
 	   the IDE card would mean?  The strange thing here is that the
	   jumper is described as either shorting pins 1-2, or shorting pins 2-3.
	   Yet there was no jumper installed at all.

	I remember that the ST-02 has the all-important "0 wait-state" jumper,
which when enabled made a big difference in the transfer rate of my drives.  I
didn't see anything like that on my IDE card.

	Thanks in advance for any help...

David Yon
----
yon%smltalk.cbm.dec.com@decwrl.dec.com
yon@world.std.com
617-621-7427 (w)
508-443-7526 (h)

rreiner@yunexus.YorkU.CA (Richard Reiner) (05/09/91)

>	I've just purchased a 33Mhz 386 clone, which included a 124meg IDE
>drive (the Seagate ST1144A) with a generic IDE controller. 
>with this drive I'm only getting around 550Kb/sec!

A friend and I each have the same drive in cached 386-33s, and we each
get about 980 KB/sec.

>	I purchased from a local dealer at a computer show, and when I called
>him about this problem, he said that he had never seen IDE drives do much
>more than 550Kb/sec.

The dealer is either inexperienced or a liar.  I have almost never
seen a non-tiny one (80 MB or more) do *less* then 700 KB/sec in a 386
machine, and I've seen plenty of them.

//richard

bressler@iftccu.ca.boeing.com (Rick Bressler) (05/09/91)

I think the primary difference is in the benchmark used.  For example, I see
almost the exact same figures, (1.2MB/sec) with CORETEST and 5-600k/s with
checkit and my AMI bios built in diagnostics.  Probably, CORETEST is not 
getting very far outside of the built in cache, or is reading without 
moving the heads at all.  It's hard to tell, since the 'real' configuration 
of the drive is hidden.  On the other hand, CORETEST reports lower rates, 
down to 900k/s on the inner tracks, and this is as it should be, since 
the density of the data drops from 44 (I think) sectors / track on the outer 
tracks, to something like 32 on inner tracks.  In fact, these numbers actually 
seem reasonable.  

Theoretically:
44 sectors / track * 3600 RPM at interleave of 1 should yield  1.28 mb / sec.
32  "          "       "                                 "      937k/sec.

These are actually about what CORETEST reports.  Perhaps it is running 
efficiently enough that it is actually getting an advantage from the 1:1 
interleave, where the other tests are real - life benchmarks where 
the 1:1 interleave is two fast.  You will note the figures are almost exactly
1/2 those of CORETEST.

sigma@obee.ipl.rpi.edu (Kevin Martin) (05/09/91)

rreiner@yunexus.YorkU.CA (Richard Reiner) writes:
>>	I purchased from a local dealer at a computer show, and when I called
>>him about this problem, he said that he had never seen IDE drives do much
>>more than 550Kb/sec.

>The dealer is either inexperienced or a liar.  I have almost never
>seen a non-tiny one (80 MB or more) do *less* then 700 KB/sec in a 386
>machine, and I've seen plenty of them.

This depends enormously on how you measure transfer rate!  CoreTest 2.92 or
whatever the latest is reports my CP-3204F IDE drive at 1136 Kb/sec.  This
is in a noncache 386/25.  But CheckIt! reports 546 Kb/sec.  No other
program tells me anything useful.

All I need to know is that the drive is FAST, especially with a 3Mb cache.

-- 
Kevin Martin
sigma@ipl.rpi.edu
"Can I kiss one of the bridesmaids instead?"

yon%smltalk.cbm.dec.com@decwrl.dec.com (David A. Yon) (05/09/91)

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

ericb@hplsla.HP.COM (Eric Backus) (05/10/91)

>        I've just purchased a 33Mhz 386 clone, which included a 124meg IDE
>drive (the Seagate ST1144A) with a generic IDE controller.  In the course
>of researching this purchase (calling Gateway, Treasure Chest, etc) I was
>qouted data transfer rates of around 1.0-1.2mb/sec on IDE drives.  Yet
>with this drive I'm only getting around 550Kb/sec!

I have a Gateway 33Mhz 386 Cache system with a Seagate ST1144A drive.  If
I completely strip the system down (NO config.sys or autoexec.bat files
at all), Norton SI measures a transfer rate above 900 Kb/sec.  With
smartdrv.sys and a few other things installed, it measures more like 750
Kb/sec.  Gateway originally told me the drive would do 1.25 Mb/sec, which
may have been a little optimistic.  I have no idea how accurate Norton SI
is, but I do know I've been happy with my drive.
--
				Eric Backus
				ericb%hplsla@hplabs.hp.com
				(206) 335-2495

whitney@peewee.cs.unlv.edu (Lee Whitney) (05/10/91)

In article <1991May9.141234.4719@hollie.rdg.dec.com>, yon%smltalk.cbm.dec.com@decwrl.dec.com (David A. Yon) writes:

) 	At any rate, the drive is performing flawlessly, and blazingly fast!


Do you all think the 1144A is really that fast?  After using both drives for a couple months it seems that it is slower than the conner drives (80 meg), although this is subjective.


Has anybody used both the 1144A and one of the Seagate Swift (15ms) drives?  I am wondering how much of a practical performance difference there is between the two families.


					Lee

mvolo@uncecs.edu (Michael R. Volow) (05/11/91)

Transfer rates in HD tests depend on block size. The version of Coretest
that I have defaults to 32-64k block size. I believe that this is an
unrealistic way to test hard disks, as programs often load in chunks of
.5-2k. Why not re-run the test with Coretest, but specifying a small
block size and then report the HD's transfer rate.
-- 
Michael Volow, Psychiatry, Durham VA Med Center, Durham NC 27712
919 286 0411 Ext 6933               mvolo@ecsvax.edu