pete@octopus.UUCP (Pete Holzmann) (05/12/88)
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 - A drive that does not work with RLL will develop 'bad tracks' over time. These *can* be fixed by reformatting. - People sometimes end up in panic mode after RLL fails. There are many failure modes for setting up a hard disk; some people may not be able to reformat their drives to MFM, but it is not the fault of the RLL controller! (Unless it had some kind of electrical defect). - An RLL controller needs a drive that can handle the *waveform* requirements. False things: (I'm going to give the opposite, true statements): - Non-certified drives OFTEN work just fine, forever! Some certified drives are marginal, and can't handle RLL for that matter. - "Storage Density" (physical flux changes per area) is no higher on an RLL drive than on an MFM drive. I guess it is time to shed some more light (hopefully!) on this subject. 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. RLL simply requires more accuracy in TIMING. The term used is 'window margin'. Essentially, there is a window of time within which the drive+ controller must decide whether or not there is a flux change on the media surface. When using RLL, this window is smaller: the timing of the flux changes must be more accurate. So: low quality disk media produces poor window margins, because of the low density of magnetic particles, etc. Cheap drive electronics produce poor window margins, because of loose tolerances. Poor RLL controller design can do the same thing: some controllers contribute less to window margin error than others. What does this mean? - RLL (or any other encoding scheme for that matter) does not physically damage or change the disk drive in any way - Some lower-quality drives should NEVER be used for RLL, because they don't have good enough window margins. This includes Seagate ST225 (and probably should include the ST238; it is 'certified' by Seagate, but often has trouble anyway). - Many high quality drives, especially those with plated media and all-around good electronics, will work without trouble! When you buy 'certification' from these manufacturers, you are NOT buying a different drive. You are simply paying extra for a guarantee of stricter tolerances. Depending on the drive involved, this guarantee may be essential [ST225/238- only a few drives pass the test] or it may be completely unnecessary [Maxtor drives work GREAT with RLL, even though not 'certified'] or something in between. - There are tests that can be performed on any drive/controller combination to see if RLL will work well. It simply involves measuring the window margin. The window margin can't be fully exercised without specialized hardware: You can't change the timing of your PC's disk interface beyond its worst case. - On the other hand, if you perform an intense read/write/format test on your drive, using worst case data patterns, you can develop a good level of confidence in your system. This is what the SpinRite program does: It beats up on the inner track of a drive [inner track has highest flux-change density] with a bunch of worst case data patterns. If this passes, there is little or no cause for alarm. Hope this clears things up a little! Pete -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746
pjh@mccc.UUCP (Pete Holsberg) (05/13/88)
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.
phil@amdcad.AMD.COM (Phil Ngai) (05/14/88)
In article <650@mccc.UUCP> pjh@mccc.UUCP (Pete Holsberg) writes: >...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 On magnetic medium, a 1 is represented by a change in flux and a 0 by no change in flux. Of course, if you get too many successive 0s, the time when you are looking for a flux change, sometimes referred to as a bit cell, will drift with respect to when the flux change really occurs. MFM, the low density alternative to RLL, throws in a flux change between two successive 0s, in the middle of the bit cell for the second 0. One limit on the media is how many flux changes you can get per inch. The literature on RLL says that it encodes data into a form where there are a minimum of two zeros between each one, compared to the minimum of one zero between each one in MFM. This means that after encoding into RLL, you can write onto the disk three times as fast as you can with MFM. Because the process of encoding into RLL gives two bits for every bit in, RLL delivers user bits at the rate of 150% of MFM. There is a table of how RLL encoding is done. 10 becomes 1000, 11 becomes 0100, and so on. I am not enough mathematician to explain how it is derived. The way I look at it, intuitively, is that with MFM you have to throw in that flux change in the middle of the 0 bit cell, right next to the flux change from a possible previous 1, so that sets your timing. But successive 1s are a whole bit cell apart. In effect, MFM is wasteful because it makes the media "hurry up and wait". It has to put some flux changes close together and others wastefully apart. RLL uses the media more evenly and thus more efficiently. We have a few app notes on this subject. You can call up our literature department at 800 538 8450 or 408 732 2400, and ask for PID #09010A, _PLDs implement encoder/decoder for disk drives_, and PID #09014A, _Constant-density recording comes alive with new chips_. I hope you find this useful. I do not speak for the company, nor do I work on disk drives so I take no responsibility for the accuracy of what has been presented here. I merely thought my contribution might be of value. (if you are curious, I work on processors) -- Make Japan the 51st state! I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com
brb@akgua.ATT.COM (Brian R. Bainter) (05/16/88)
From article <216@octopus.UUCP>, by pete@octopus.UUCP (Pete Holzmann): > - Many high quality drives, especially those with plated media and > all-around good electronics, will work without trouble! > Pete I've got to agree strongly there with you Pete. I have been using a 20M Fuji chrome drive RLL'ed to 30M for nearly a year now without any problems what so ever. I even bought a second drive and it is working with the same flawless performance. If anyone wants a recommendation, this is my choice. One other note about the drives. They both came with 0 factory defects so the quality is pretty much there. Works for me! Brian R. Bainter