Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!rochester!cornell!uw-beaver!tektronix!tekcrl!tekgvs!keithe
From: keithe@tekgvs.LABS.TEK.COM (Keith Ericson)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Seagate 251 and RLL controllers
Keywords: RLL Hard Drive
Message-ID: <5556@tekgvs.LABS.TEK.COM>
Date: 12 Jul 89 18:08:14 GMT
References: <723@srhqla.SR.COM>
Reply-To: keithe@tekgvs.LABS.TEK.COM (Keith Ericson)
Distribution: na
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 76

In article <723@srhqla.SR.COM> tcm@srhqla.SR.COM (Tim Meighan) writes:


>Well, let's be fair about this.  I really don't think that Seagate is
>trying to "scare" us into thinking we'll ruin a 251 drive mech by hooking it
>up to an RLL controller.  What they are saying is that they won't honor
>the warranty on a drive mech USED AS AN RLL DRIVE that hasn't been certified
>to have a platter surface capable of handling RLL encoding, which is, after
                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>all, higher density than MFM encoding.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

No, no, no, no, no!  The flux changes per inch is NOT higher in RLL than
it is in MFM.  One of the consequences of RLL encoding is that the
timing constraints on exactly WHEN those flux changes occur is much
tighter, and a "crummy" surface won't be able to maintain those timing
specs.  But the actual fcpi is the SAME.

Yes, each byte of recorded information represents, on average, 1.5 bytes
of "real" information, but what the platters sees is no different between
MFM and RLL.


>Note that failure of a drive mech isn't always mechanical failure; it could
>be that the drive just doesn't read and write data reliably.

If RLL use of a drive causes mechanical damage there's really something
wrong goning on...

>                                                              So, by telling
>you not to use anything but a certified drive mech for RLL encoding, Seagate
>is just trying to protect itself from legal hassles.

No, what it is telling you is "We made this big batch of drives; we tested
them all to see which ones will work RELIABLY with RLL.  Those we charge
more money for."  (Guess where 5% and 10% carbon resistors came from - the
same batch, but the 5% were tested and made the spec; the 10% parts didn't.)


>You may or may not agree with their policy of certifying specific drive
>mechs as suitable for RLL encoding, and charging more for such drive mechs.
>I think such a policy is reasonable, but it is certainly a matter of
>personal opinion.  In any event, regardless of what you think of Seagate
>and the quality of their products, this by itself hardly qualifies them
>as a second-rate company.

>BTW, it is extremely easy for a manufacturer to determine if a drive
>mech has been formatted for RLL encoding,

OH?  How?

>                                          so Mr. Ericson's assertion
>that there is no way they would know if you did such a thing is untrue.
>What were you going to do, Keith, a low-level MFM re-format of your
>BROKEN drive so they couldn't tell it had once been RLL?

Look, if an non-RLL-certified drive fails to work reliably with an RLL
controller, it will be by loss of bits - failure to read, write, and/or
verify data.  It's not going to go up in smoke, fry IC's, warp platters or
sieze bearings!

So, Yes - I'd re-format it with an MFM controller and use it as such.  I've
done it many times (more than I had hoped I'd have to) with Miniscribe 3053's.

>                                                          Good luck!  :-)

Look, I KNOW I'm pushing the spec to connect an RLL controller to a drive
not necessarily certified for it.  But I don't see Maxtor nor Micropolis
telling me, in effect, that I risk damaging the whole drive by doing it.  I
mean, get REAL, Seagate!!!  I'm also pushing the spec to format 1200
cylinders on a Maxtor drive certified to have 1024.  But I've learned that
these manufacturers make quality products, I take my chances, and get a
little extra.  I haven't had that experience with Seagate.


kEITHe