[comp.sys.ibm.pc.hardware] 80 mb RLL 28ms Micropolis Drive much slower than Seagate ST251 ...

amichiel@rodan.acs.syr.edu (Allen J Michielsen) (10/13/90)

In article <15946@shlump.nac.dec.com> heintze@fmcsse.enet.dec.com (Siegfried He
>...{new drive takes}... 20 minutes to execute... I am certain my seagate did 
>not take this long.... used to require about 5 minutes to execute

>type.  He recommended I run SETUP and change the drive type to 1.  It was
> set to 40 and I changed this to 1.    This seemed to help a little.  
>I have no idea what these numbers mean.

>How could this be that there is such a drastic desparity in performance 
>between two 28 ms drives? ... if anything, the Micropolis should be faster 
>since seagate often fudges their performance claims.
>
   1. While i did edit all reference to both, it is possible that either your
system combo of interleave & disk cache with the new drive are causing the
entire problem.  You probably can regain all of this performance by a LLF
(IF this is true).
   2. Every controller uses interleave, it's a parameter.  It may not be
variable, well so to speak, but...
   3. Seagate fudgin... 'bullshit'.  seagate makes in my opinion, good drives
with good performance FOR THE PRICE (street not list).  It is generally true
that micropolis drives are better (better parts, higher reliab, faster,...)
But they also are more expensive.  I just bought a NEW seagate 80 Mb MFM
drive from a dealer, with shipping and a no-terry warranty for $ 494. How
much was terry's micropolis, and where did it come from (is there a police
report ?).
   4. I suspect you are seeing a combination of slight problems, all the above,
but mostly one of a difference in the track to track seek times.  The seagate
should have a rating of 8 MS, and I have NEVER EVER seen one more than 9. I
recommend you get a copy of a public domain (released) program called coretest.
it's from coretest international.  It is intended to PR how good the systems
they sell are. It is fairly easily cheated in the measured disk i/o tests, but
is very good with av seek and trak-track times.

I tried a too intensive disk cache with the effect that it increased the disk
i/o + cpu response time by a factor of 2 to 4 times. (1 minute to 2 to 4 min).
I also have a measured system response time to the same 4 times (same 1 to 4),
with 2 identical system, 1 of which measures 1.7 Ms track to track, the other
is 7.4 Ms track to track. 

The setup disk number is a system bios (somewhat) dependent variable.  The 
number conveys the disk parameters to the system & controller. number of heads,
number of cylinders, number of tracks, error correction coding, safe park
zone, reduced write current and compensation, is about it.  It often is 
critically important to match these up perfectly during a format or LLF,
and not quite as much for day to day disk i/o.  I doubt if a 'close' error
would result any big performance read difference.  If the error was great,
then a LLF is basically required.
al


--
Al. Michielsen, Mechanical & Aerospace Engineering, Syracuse University
 InterNet: amichiel@rodan.acs.syr.edu  amichiel@sunrise.acs.syr.edu
 Bitnet: AMICHIEL@SUNRISE