dick@slvblc.UUCP (Dick Flanagan) (01/27/88)
In article <2736@cup.portal.com> Tim_Sam_Carson@cup.portal.com writes: >Has anyone ever tried using a RLL controller on a Seagate ST-225 ? >If so, did it work? If it did, how much did you gain? I had a pair of ST-225's in an XT and I replaced their old controller with an Adaptec 2070A RLL controller. One of the ST-225's is working flawlessly to this day (24-hours per day for over a year), while the other one was finally replaced a few months ago with an ST-238. The ST-225 that was finally replaced became very sensitive to transient read errors until it finally reached the point where those errors could no longer be tolerated. (I gave it to a friend to try back in non-RLL service, but I have not heard back as to the success or failure of that venture.) I have heard about many people who have placed ST-225's into RLL service, and the vast majority of them have been successful (the GEnie IBM Round Table has an entire topic on this subject). With RLL controllers available for around $100 (the 2070A, anyway), it makes sense to at least try it with your -225's. As far as gain is concerned, a chkdsk on my remaining RLL'ed ST-225 shows 31,191,040 bytes. Good luck! Dick -- Dick Flanagan, W6OLD GEnie: FLANAGAN UUCP: ...!sun!plx!slvblc!dick Voice: 1 408 336-3481 USPO: PO Box 155, Ben Lomond, CA 95005 LORAN: N37 05.5 W122 05.2 --
pjh@mccc.UUCP (Peter J. Holsberg) (01/28/88)
In article <2736@cup.portal.com> Tim_Sam_Carson@cup.portal.com writes: >Has anyone ever tried using a RLL controller on a Seagate ST-225 ? >If so, did it work? If it did, how much did you gain? YES, I did, but it is NOT recommended. The ST225 is not certified for use with RLL formatting. You run the risk of losing everything on that disk (which now holds 30M instead of the 20M under MFM formatting). -- Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh Technology Division CompuServe: 70240,334 Mercer College GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800
msprick@amdcad.AMD.COM (Rick Dorris) (01/28/88)
In article <162@mccc.UUCP> pjh@mccc.UUCP (Peter J. Holsberg) writes: >In article <2736@cup.portal.com> Tim_Sam_Carson@cup.portal.com writes: >>Has anyone ever tried using a RLL controller on a Seagate ST-225 ? >>If so, did it work? If it did, how much did you gain? > > >YES, I did, but it is NOT recommended..... Hell, is that an understatement. I knew someone that used an RLL controller on a Seagate ST-225. I'd never try it after seeing how many nights he stayed up trying to figure out why he was losing so much data and crashing his machine. He reformated with a different card and his problems have vanished. If you want 30meg go out and buy a 30 meg drive. Rick
rpo@celerity.UUCP (Bob Ollerton) (01/29/88)
I was sold a rll with my ST225. I had nothing but problems with
data erros and the drive foing to sleep. I got no help from the dealer,
and the disk finally crashed. Thanks.
So, I bought another disk and a standard MFM controller and everything is
fine. Lesson learned:
1. the St225 is a cheap drive and has a track record for failing
in the first 30 days and if they make it past that, the run for ever.
2. RLL is a problem for the 225's and I don't know which drives
its recommended for.
Does anyone have a list of drives that RLL works for?bownesrm@beowulf.UUCP ( Stowaway aboard the Long Shot) (02/07/88)
In article <532@celerity.UUCP>, rpo@celerity.UUCP (Bob Ollerton) writes: > > I was sold a rll with my ST225. I had nothing but problems with > data erros and the drive foing to sleep. I got no help from the dealer, > and the disk finally crashed. Thanks. > First problem. The St225 is NOT MEANT to run rll. Sorry. > So, I bought another disk and a standard MFM controller and everything is > fine. Lesson learned: > 1. the St225 is a cheap drive and has a track record for failing > in the first 30 days and if they make it past that, the run for ever. Don't bet on it. Mine ran fine for ~9 mos and the the stepper motor driver went south. Took the pc board with it. Scorched it pretty badly. I was NOT pleased. $120 to get it fixed. > > 2. RLL is a problem for the 225's and I don't know which drives > its recommended for. > Take a look in the special issue of EDN (last spring sometime) for a good comprehensive list of who builds drives for which interface and for how much. Sorry I can't be more specific, I read it and throw it out. > Does anyone have a list of drives that RLL works for? See above. Bob Bownes, aka iii, aka captain comrade bob | Since I AM my employer, Function Consulting, Albany, New York, 12203 | I guess these opinions are (518)-482-8798 voice (518)-482-9228 (anon uucp) | those of my employer bownesrm@beowulf.uucp | my houseplants, and my TR-6. ------------------------------------------------+------------+------------------ PS/2: Yesterday's Hardware Today. | Stolen from Jerry OS/2: Yesterday's Software Tomorrow. | Pournelle in OS/2 Extended Version: Yesterday's Software REAL SOON NOW. | InfoWorld -------------------------------------------------------------+------------------
rob@dhw68k.cts.com (Robert Kenyon) (02/12/88)
So what's the final story? Doe the RLL controller thrash the 225? (after
finding the ST225 to be unhappy running RLL, is it possible to go back
to MFM?) I hear a lot of people crying and a few people cheering. What
is the final word? Do I write off my drive if it can't cut it?
--
I once was here but now I'm not. And no one's gonna pin it on me...
Robert Kenyon - {trwrb,hplabs}!felix!dhw68k!rob - InterNet: rob@dhw68k.cts.compjh@mccc.UUCP (Peter J. Holsberg) (02/14/88)
In article <5037@dhw68k.cts.com> rob@dhw68k.cts.com (Robert Kenyon) writes: | |So what's the final story? Doe the RLL controller thrash the 225? (after |finding the ST225 to be unhappy running RLL, is it possible to go back |to MFM?) I hear a lot of people crying and a few people cheering. What |is the final word? Do I write off my drive if it can't cut it? | The problem is: there's no final story! Some people have been successful in using an RLL controller with a 225 (I was) and some haven't. Some have been succesful in reformatting a RLL 225 to MFM (I was) and some haven't. If I were "Consumers Report", I'd say NOT RECOMMENDED. You want RLL? Look for a drive that's certified. -- Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh Technology Division CompuServe: 70240,334 Mercer College GEnie: PJHOLSBERG Trenton, NJ 08690 Voice: 1-609-586-4800
berger@clio.las.uiuc.edu (02/15/88)
Most drives intended for MFM work fine with RLL. Seagate is one of the
only manufacturers to advise against it, and they refuse to service a
drive (warranted or otherwise) if it's been used outside of their
explicit specifications. If you try it, it's at your own risk.
Mike Berger
Department of Statistics
Science, Technology, and Society
University of Illinois
berger@clio.las.uiuc.edu
{ihnp4 | convex | pur-ee}!uiucuxc!clio!bergerwtm@neoucom.UUCP (Bill Mayhew) (02/19/88)
In article <16800212@clio>, berger@clio.las.uiuc.edu writes: > Most drives intended for MFM work fine with RLL. Seagate is one of the > only manufacturers to advise against it,... The makers of RLL controller cards are also pretty cagey about naming drives that will work with their cards too. There are reasons. The bit rate from a standard MFM encoded drive is 500,000 bits/sec. The bit rate for RLL is 750,000 bis/sec. The reason for this is obvious. Since you can't change the RPM of the drive, and the drive has more bits/track, then the data has to move at a hgiher bit rate for RLL. The higher bit rate requires that the bandwith of the head amplifiers be sufficent first of all; secondly, the media of the disk platter itself has to be able to handle the proper bit density. My literautre on the OMTI 5527 controller card mentions the following drives as being approved by OMTI for use with the card: Mfr: Model: Capacity: Atasi 3085 109.1 meg Lapine LT300 32.8 Microscience HH-330 32.6 HH-738 32.6 Miniscribe 3438 32.7 8438 32.6 PTI PT 238R 32.7 PT 357R 49.1 Priam V170 91.9 V185 108.6 514 179.2 519 244.4 Seagate ST238 32.7 ST251R 43.6 ST277R 65.4 ST4077R 68.1 ST4144R 122.7 Toshiba MK-53FB 55.2 MK-54FB 77.3 MK-56FB 110.5 These figures are quoted by SMS / OMTI as of 11/1986. Assumes RLL 2/7 coding. Compatible with OMTI 3127, 3527, 5527, 5529, 8627. --Bill
sl@van-bc.UUCP (Stuart Lynne) (02/25/88)
In article <1017@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: >In article <16800212@clio>, berger@clio.las.uiuc.edu writes: > > >> Most drives intended for MFM work fine with RLL. Seagate is one of the >> only manufacturers to advise against it,... > > >The makers of RLL controller cards are also pretty cagey about >naming drives that will work with their cards too. There are >reasons. The bit rate from a standard MFM encoded drive is 500,000 >bits/sec. The bit rate for RLL is 750,000 bis/sec. The reason for >this is obvious. Since you can't change the RPM of the drive, and >the drive has more bits/track, then the data has to move at a >hgiher bit rate for RLL. The higher bit rate requires that the >bandwith of the head amplifiers be sufficent first of all; >secondly, the media of the disk platter itself has to be able to >handle the proper bit density. I'm *probably wrong*, but my understanding of RLL is not that your have *more* bits being stored on the disk, but simply that your are making more efficent use of them by encoding your data with smaller/shorter bit patterns. You do see an effective data rate that is much higher between the cpu and disk controller, but *not* between the controller and the drive. The reason that the manufacturers rate some drives as RLL capable is simply that because your are using an encoding scheme with less redundancy you will have a higher error rate unless you have better media. So you are paying for (usually) plated media which they test better. A similiar phenomenom occurs with AT floppy disks. Diskette manufacturers issue hideous warnings of impending doom if you dare to use other than special high density AT style floppy diskettes (which they incidentally charge a *lot* more for). Most of us just buy the good old cheapies and simply throw out the 1 or 2 per box which don't work. Unfortunately with a hard disk you can't just throw it out if it doesn't work, so probably in most cases if you are buying *new* equipment it's worth your while to buy RLL rated drives. However if you already have a drive and happen to get an RLL controller you might as well try it. Of course if you end up getting hundreds of bad blocks then trying to map them out is not a good idea, but if its a reasonably small number you might consider using it that way. I'll be trying this out sometime this spring, as soon as the WD-1006 RA2 is available. And I've got some real oldtimer's that I'm going to try RLL on. BTW the transfer rate on standard ST-506 type drives is 5 MBits/second not .5 MBits/second. >reasons. The bit rate from a standard MFM encoded drive is 500,000 >bits/sec. The bit rate for RLL is 750,000 bis/sec. The reason for -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (02/26/88)
In article <1017@neoucom.UUCP> wtm@neoucom.UUCP (Bill Mayhew) writes: | In article <16800212@clio>, berger@clio.las.uiuc.edu writes: | | > Most drives intended for MFM work fine with RLL. Seagate is one of the | > only manufacturers to advise against it,... | | The makers of RLL controller cards are also pretty cagey about | naming drives that will work with their cards too. There are | reasons. The bit rate from a standard MFM encoded drive is 500,000 | bits/sec. The bit rate for RLL is 750,000 bis/sec. The reason for | this is obvious. Since you can't change the RPM of the drive, and | the drive has more bits/track, then the data has to move at a | hgiher bit rate for RLL. The higher bit rate requires that the | bandwith of the head amplifiers be sufficent first of all; | secondly, the media of the disk platter itself has to be able to | handle the proper bit density. Let me see if I can clarify this a bit... when RLL comtrollers put data on a disk, they don't just send it 50% faster, they preprocess it. Somewhat like data compression. While the *bit rate* goes up, the number of flux changes per inch (fpi) doesn't. For every combination of disk media and head there is an upper limit on how close two flux changes may be. This is why the write precomp changes on some disks, because the diameter of the inner tracks is smaller and the flux changes are closer together. Let me try to say it pictorially: no RLL 0..1..0..1..0..0..1..1 50% more fci 0.1.0.1.0.0.1.1 RLL 2,7 D...D...D...D...D...D How this works is that the timing of the flux changes is now more critical, and the number of bit per second is up 50%, but the flux changes stay an acceptable distance apart. They are often farther apart than with MFM. The reason some disks may fail is that the timing of the flux changes must be quite precise, and if the media doesn't yield a good clean transition the timing will "jitter" enough to give CRC errors. BTW: MFM is just a term used for one type of RLL compression, I believe RLL-0,2 but please don't quote me. Back in about 1978 floppies made the change from "single density" to "double density" using this newfangled thing "MFM recording. There is another RLL being tested which gives 100% increase in data on a disk, and I believe it's called RLL-4,9 (again don't quote me). Now some real hardware hacker can post a real rebuttal to this, telling me I've glossed over the detail, and explaining it in a way meaningful only to other hardware types. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
Geoffrey_Welsh@watmath.waterloo.edu (02/27/88)
> From: davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) > Message-ID: <9692@steinmetz.steinmetz.UUCP> > Date: 25 Feb 88 21:13:30 GMT > BTW: MFM is just a term used for one type of RLL compression, I believe > RLL-0,2 but please don't quote me. Back in about 1978 floppies made the > change from "single density" to "double density" using this newfangled > thing "MFM recording. There is another RLL being tested which gives 100% I'm no expert, especially on RLL, but I think you've explained it well. The 'single-density' floppies used "FM" formats, which included a clock bit and a data bit to make sure that the controller wouldn't lose sync. MFM is "self-clocking", so it packs more data without actually increasing the number of flux changes per unit distance. Some manufacturers decided to use GCR (group code record) in stead of MFM. This reduced overhead from FM's 50% clock bits to 20% (using 5/4 GCR encoding). I don't have the slightest clue what MFM overhead is, nor what RLL overhead is. The "new RLL" is called ERLL (extended RLL? enhanced RLL?), and promises to double the capacity of some drives. What I do not understand is how RLL can damage a drive; I have heard from many sources that using an RLL controller on a drive than can't handle it will leave you with a pile of junk. If indeed the problem is simply one of the timing being off and causing read errors in the controller, one ought to be able to reformat with a standard controller... Geoff ( watmath!fido!221/171!izot ) --- ConfMail V3.31 * Origin: The Waterloo Window: WOC's out there? (1:221/171)
root@uwspan.UUCP (John Plocher) (03/02/88)
+---- Bill Mayhew writes | +---- berger@clio.las.uiuc.edu writes: | | Most drives intended for MFM work fine with RLL. Seagate is one of the | | only manufacturers to advise against it,... | +---- | | The makers of RLL controller cards are also pretty cagey about | naming drives that will work with their cards too. +---- [This is NOT an ad - even though I quote from the one on page 258 of the March 1988 BYTE ] A company called Perstor has a controller that uses 34 SPT (instead of 17 or 26) and "Our competitors offer only a 50% increase in capacity with their controllers, while we have advanced the RLL standard to allow for a 90% or 100% increase in capacity." They also say "While other RLL controllers require drives approved for RLL encoding, the Perstor 200 series controllers allow you to upgrade current hard disk systems or create new systems with standard MFM drives or approved RLL drives." "If performance is the issue, the Perstor controllers are the answer, delivering up to a 110% increase in your data transfer performance." The design allows for TWO cards to be installed in one system - each card controls 2 floppies and 2 hard disks. Cost is less than $350. 8 bit card avail now, 16 bit in April. Anyone ever use one? Their engineer/support guy seemed to be OK, he knew about stuff - he said they do all disk interfacing within the design window for MFM drives and that they DO NOT require plated media... It almost sounds too good to be true - our Maxtor 2190's will format out to 295Mb EACH! Wow! Someone pinch me, please! -John -- Comp.Unix.Microport is now unmoderated! Use at your own risk :-)