Xref: utzoo comp.sys.ibm.pc:15523 comp.sys.misc:1417
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!purdue!gatech!udel!princeton!mccc!pjh
From: pjh@mccc.UUCP (Pete Holsberg)
Newsgroups: comp.sys.ibm.pc,comp.sys.misc
Subject: Re: RLL- why it is hard on drives (was Re: Disk Controller Question ?)
Message-ID: <650@mccc.UUCP>
Date: 13 May 88 13:26:53 GMT
References: <1255@kodak.UUCP> <638@mccc.UUCP> <216@octopus.UUCP>
Reply-To: pjh@mccc.UUCP (Pete Holsberg)
Organization: The College On The Other Side of Route 1
Lines: 49

In article <216@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes:
...In article <638@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes:
...}In article <1255@kodak.UUCP> crassi@kodak.UUCP (charlie crassi) writes:
...}...I was told that the RLL controller will work fo about a month and then     
...}...will destroy the media which is not coated thick enough. Is there any
...}...truth to the matter.
...}
...}
...}Your data is living on borrowed time!  Any medium which is not certified
...}for RLL will eventually fail (unless you are VERY lucky!) because of the
...}demands an RLL controller makes on it.  The horror stories told on
...}CompuServe were enough to convince me to stop using my Adaptec
...}controller with an ST-225.  People have reported that they were not able
...}to reformat their disks with their MFM controllers after abandoning
...}RLL!!  This is not to castigate RLL, but an RLL controller needs a drive
...}that can handle the storage density and waveform requirements.
...
...Sorry, but this response is only half true!
...
...True things:	- ST225 drives do not work well with RLL

Based on experience, that should read "most ST-225s do not work well
with RLL".  However, as I said orginally, I would never recommend that
anyone use an ST-225 with RLL.

...		- A drive that does not work with RLL will develop 'bad tracks'
...			over time. These *can* be fixed by reformatting.

Jeez, Pete!  Call me a liar in front of all these people?  If you don't
believe what I said, trot over to CompuServe's IBMNET and ask Dave
Hoagland about the MFM drives that he was unable to reformat MFM after
running them as RLL-formatted drives.  Dave is the hardware guru for a
government laboratory and is one of the most knowledgeable people I have
ever typed at.

...MFM formatting is *actually* a form of RLL. What we call 'RLL' is just a
...different encoding scheme. It increases the amount of data stored on the
...disk by placing the flux changes on the platter in a more accurate pattern
...than that used by MFM. The DENSITY of flux changes is not any different.

Pardon my simplistic look, but if a drive rotates at a constant speed
regardless of its formatting and produces data (RLL formatting) at 1.5
times the rate of MFM data transfer, then it seems that there are -- at
least effectively if not physically -- more bits per inch.  How the
higher effective bpi is produced is the subject of your posting, but
it's not clear what there is about RLL that produces the increase in
effective bpi.  Would you like to go into a little detail on 2,7 and all that?

Sorry if I caused any confusion.