297 lines
14 KiB
Plaintext
297 lines
14 KiB
Plaintext
Article 17745 of comp.sys.ibm.pc:
|
||
>From: pete@octopus.UUCP (Pete Holzmann)
|
||
Subject: RLL Technical Details (long) (was Re: RLL- why it is hard on drives)
|
||
Message-ID: <218@octopus.UUCP>
|
||
Date: 15 May 88 03:16:04 GMT
|
||
Organization: Octopus Enterprises, Cupertino CA
|
||
|
||
If you read all the way through this, you will (hopefully) understand WHY
|
||
RLL works/doesn't work depending on the configuration you set up. You will
|
||
also understand WHY many of the horror stories applied to RLL are almost
|
||
certainly mis-applied.
|
||
|
||
I. How is data stored on a disk drive?
|
||
|
||
As magnetic flux reversals (think of it as + to -). The POLARITY of the
|
||
magnetic flux doesn't mean a thing. It is the TIMING of the flux reversals
|
||
that is used to encode data.
|
||
|
||
II. What is RLL? What does the '2,7' in '2,7 RLL' mean?
|
||
|
||
RLL means Run Length Limited. The Limits in disk drive RLL refer to the
|
||
minimum and maximum time between flux reversals. '2,7' means minimum of 2,
|
||
maximum of 7. A minimum of zero would mean that flux reversals can occur
|
||
in every clock period. Thus, '2,7' means that flux reversals occur at least
|
||
every 8th clock period (7 periods without a reversal), but no more often
|
||
than every third clock.
|
||
|
||
RLL codes are 'self clocking'. Since you are guaranteed to have a flux
|
||
reversal within a limited time, a phase-locked-loop circuit can find the
|
||
basic clock period of data on the drive. As the basic clock period gets
|
||
smaller and/or the maximum inter-flux-reverse time increases, the job
|
||
gets harder and harder for the phase-locked-loop circuitry.
|
||
|
||
III. What about MFM?
|
||
|
||
MFM is simply 1,3 RLL encoding, with a basic clock period of 50 nsec.
|
||
One data bit is encoded every two clock periods. The MFM code is relatively
|
||
easy to understand [and I have some notes handy], so I'll give the complete
|
||
details:
|
||
|
||
In this table of flux encoding, '0' means no flux change, '1' means a
|
||
flux change encoding a '1' data bit, 'C' means a flux change
|
||
required to encode a '0' data bit due to clocking requirements.
|
||
|
||
The code: 1 always becomes 0 1
|
||
0 becomes 0 0 if preceeded by a 1
|
||
0 becomes C 0 if preceeded by a 0
|
||
|
||
Message Data: 1 0 0 0 0 0 0 0 0 0 0 0
|
||
Disk Data: 0 1 0 0 C 0 C 0 C 0 C 0 C 0 C 0 C 0 C 0 C 0 C 0 ...
|
||
|
||
Message Data: 1 1 1 1 1 1 1 1 1 1 1 1
|
||
Disk Data: 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 ...
|
||
|
||
Message Data: 1 0 0 1 1 0 1 0 0 1 0
|
||
Disk Data: 0 1 0 0 C 0 0 1 0 1 0 0 0 1 0 0 C 0 0 1 0 0
|
||
|
||
Note that there are between 1 and 3 zeros between every 1 in the disk data!
|
||
|
||
Note that since 'C' is physically the same as '1' (both are flux reversals),
|
||
the setup gets in trouble if it loses track of clock periods!
|
||
|
||
The way this is used on a disk drive is that there is a special data sequence
|
||
encoded at the beginning of each sector, with special hardware to detect
|
||
it: First, there is a long string of zero's; a hardware 'zero detector' is
|
||
enabled to look for it. At this point, it could as easily find a string of
|
||
one's as a string of zero's, since they are identical when taken out of
|
||
context. Second, a special byte is encoded that VIOLATES the RLL rules: an
|
||
'A1' or 'A8' byte is written, with a clock missing in one of the sequential
|
||
zero bits (the A1 and A8 tell us whether we are looking at the header of
|
||
the sector, which contains cyl/sector/etc info, or the data portion of the
|
||
sector). The special byte is called the Address Mark. If zeros followed by
|
||
an Address Mark are found, then the PLL (phase locked loop) is synchronized
|
||
and data can be read.
|
||
|
||
IV. Ok, so explain the 'RLL' schemes.
|
||
|
||
I don't have complete tables of code schemes for all of the RLL formats
|
||
handy; it would also take a long time to type them all in. Instead, I'll
|
||
explain what IS important about them.
|
||
|
||
First, let's compare 2,7 RLL with 1,3 RLL. Both codes happen to encode
|
||
one data bit into 2 clock periods. With 1,3 RLL (MFM), a flux reversal
|
||
can occur every two clock periods. With 2,7 RLL, a flux reversal can occur
|
||
every 3 clock periods. If we increase the clock rate by 50% using a 2,7
|
||
RLL scheme, we get the same maximum flux reversal rate as for MFM. But, we
|
||
get 50% more data out of the drive, at a 50% higher data rate.
|
||
|
||
Other RLL encoding schemes involve changes in the number of clock periods
|
||
used to encode a data bit. For example, 1,7 RLL encodes 2 data bits into
|
||
3 clock periods. The 1,7 clock period must be kept the same as for 1,3 (MFM)
|
||
(I hope you see why by now: both schemes involve a flux change as often as
|
||
every 2 clocks). The result is a 50% increase in storage capacity, just as
|
||
with 2,7 RLL.
|
||
|
||
Why not use 1,7 RLL? Because the difference between minimum and maximum
|
||
flux-change-intervals is so great. It turns out that the PLL electronics
|
||
for detecting this wide a range of intervals is a real pain; worse, presumably,
|
||
than the problems involved in implementing 2,7 RLL.
|
||
|
||
Other encoding schemes use different clock rates and different min/max
|
||
combinations. They all set things up so the maximum flux-reversal frequency
|
||
is the same.
|
||
|
||
The IMPORTANT differences between the schemes involve maximum clock freqency
|
||
(50% higher for 2,7 RLL than MFM, 100% higher for ARLL than MFM) and maximum
|
||
Frequency Ratio (comparing minimum and maximum flux-reversal intervals).
|
||
In addition, some schemes involve simpler encoding/decoding algorithms (e.g.
|
||
the normal 1,3 RLL/MFM); others are very complex: 2,7 RLL is a variable length
|
||
code (e.g. 0011 maps to 00001000 but 010 maps to 100100); I don't have a
|
||
simple formula for the 2,7 RLL code! Variable length codes make error
|
||
recovery more difficult, and hence make bad-sector marking more important.
|
||
|
||
A high frequency clock requires great accuracy in timing all along the chain
|
||
from disk surface to final data to be read (and the reverse). The time period
|
||
during which the controller must decide whether a flux reversal is present
|
||
or not is called the 'window'. The variation in flux-reversal detection
|
||
(+ or - from the nominal 'perfect detection time') allowed by a given encoding
|
||
scheme is called the 'required window margin'. Higher frequency clocks have
|
||
smaller window margin requirements. On a given drive/controller combination,
|
||
the window margin can be measured: simply sync up the electronics to the
|
||
pulses on the drive, read a worst-case data pattern, and see what kind of
|
||
variation in flux-reversal timing you get. Good drive/controller combinations
|
||
will place all flux reversals in a very narrow time window, giving a very
|
||
good window margin, and hence will work well with high-frequency encoding
|
||
schemes.
|
||
|
||
A big difference between minimum and maximum flux reversal intervals
|
||
simply requires complex decoding and phase-locked-loop circuitry
|
||
that can handle a wide range of frequencies. All of which leads us to...
|
||
|
||
V. What does all this mean in terms of real drives, controllers, etc.?
|
||
|
||
First, let's understand which parts of the whole deal go where. Here are
|
||
the pieces needed to read/write disk info, and where they are located:
|
||
|
||
Component Where it is
|
||
|
||
Disk surface Drive
|
||
Head Drive
|
||
Analog head electronics Drive
|
||
(conditions signal to/from
|
||
head)
|
||
Cable Between drive and controller
|
||
Analog data separator Controller
|
||
(detects flux reversals)
|
||
Phase Locked Loop Controller
|
||
(determines data clocking)
|
||
Digital read/write stuff Controller
|
||
(includes bit/byte conversions,
|
||
etc etc etc)
|
||
|
||
Note that MOST of the junk is in the controller, not the drive!
|
||
|
||
On the drive:
|
||
|
||
Oxide-surface disks on early drive designs (e.g. ST-225, ST-238) do not
|
||
place the flux-reversal with enough accuracy to be used in most RLL
|
||
situations. This is why ST-225/238 drives have so much trouble.
|
||
Newer drive designs use plated media, which allow better magnetic
|
||
definition.
|
||
|
||
The drive head and associated electronics are usually tuned to match
|
||
the expected signals to and from the drive. If the drive was designed
|
||
without 'RLL' (2,7) in mind, the frequency response of the drive
|
||
electronics is 'mushy': it may not provide a crisp/accurate enough
|
||
signal to allow the PLL to correctly sync up. On more recent drives,
|
||
the same exact setup is used for 'MFM' (1,3 RLL) and 'RLL' (2,7); the
|
||
drives that are certified for RLL are simply tested to verify that
|
||
everything is OK. (The reason I'm so down on Seagate ST225/238 is that
|
||
they didn't redesign anything. They simply test the same old stuff, and
|
||
if it happens to pass the RLL test, they sell it as RLL).
|
||
|
||
On the controller:
|
||
|
||
On an 'RLL' controller, everything must be carefully designed to meet the
|
||
tighter timing requirements. Note that a VERY accurate controller can
|
||
make up for a somewhat mushy drive: the overall timing requirements are
|
||
based on the sum total of electronics in the path from disk media to final
|
||
digital output. Spreading the timing error evenly between drive and
|
||
controller is theoretically cheaper, since neither one need be set up
|
||
for very tight tolerances; however, a very accurate controller is not
|
||
that hard to build today, hence the better success we're all having
|
||
at running 'non-RLL' drives with RLL controllers.
|
||
|
||
In general:
|
||
|
||
There's no such thing as a free lunch. There is no encoding scheme
|
||
(so far) that gets you more data without requiring more density or
|
||
more timing accuracy of some kind. Somebody mentioned an amazing new
|
||
Perstor controller that doubles drive density, supposedly without
|
||
increasing the timing requirements. HAH! You sure can't get double
|
||
the flux-reversals in the same space, so you MUST do it by increasing
|
||
the timing requirements. The Perstor simply is an ARLL controller
|
||
(I'm not certain, but I believe ARLL, getting 100% more data than MFM,
|
||
is a 4,7 RLL encoding scheme); it will have trouble with some low
|
||
quality drives just like the other RLL controllers do.
|
||
|
||
I have not personally tested the window margins on lots of drives or
|
||
controllers. I have talked with people who HAVE done this testing; their
|
||
results say that the Adaptec RLL controllers have the best timing of
|
||
all RLL controllers on the market today (as of a month ago), and confirm
|
||
what I've heard/seen about Miniscribe and Maxtor drives (they also have
|
||
good enough timing), and about Seagate ST225/238 (poor to marginal).
|
||
|
||
VI. What about ESDI and SCSI?
|
||
|
||
Well, they are kind of handy: all of the data encoding/decoding circuitry
|
||
is on the drive; it is all designed together, and is well matched (hopefully!).
|
||
Putting it all together like that makes it easier to use fancier high frequency
|
||
encoding schemes, so you'll typically see higher data densities on ESDI and
|
||
SCSI drives.
|
||
|
||
VII. Anything else?
|
||
|
||
Sure! There are lots of even more technical, related issues to discuss:
|
||
bit shift details (bit shift is a lower level description of what causes
|
||
large window margins on a given drive); signal-to-noise ratios; pulse
|
||
amplification; pulse equalization; etc etc... and far on into things that
|
||
I know nothing about (and hope I never have to!). Actually, it's pretty
|
||
amazing when you think about it: for 99.999% of the people out there,
|
||
this stuff is just boxes, cables and cards that you plunk together and
|
||
they just *work*!
|
||
|
||
Well, that's about it. I've run out of time, so I'd better send this now.
|
||
I hope it helped more than it confused! [And no, I don't think you'll find
|
||
drive manufacturers or controller manufacturers very willing to provide
|
||
detailed spec's on their window margins; that would make it too easy to
|
||
compare drive quality! :-(]
|
||
|
||
Pete
|
||
|
||
P.S.: If you read all the way to here, congratulations! I don't really expect
|
||
that this stuff would really be interesting enough for people to read through
|
||
250 lines of gobbledy gook... :-)
|
||
--
|
||
OOO __| ___ Peter Holzmann, Octopus Enterprises
|
||
OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014
|
||
OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete
|
||
___| \_____ Phone: 408/996-7746
|
||
|
||
|
||
From ucdavis!ucbvax!hplabs!pyramid!octopus!pete Tue May 17 11:13:55 PDT 1988
|
||
Article 17805 of comp.sys.ibm.pc:
|
||
Path: ucdavis!ucbvax!hplabs!pyramid!octopus!pete
|
||
>From: pete@octopus.UUCP (Pete Holzmann)
|
||
Newsgroups: comp.sys.ibm.pc,comp.periphs,comp.sys.misc
|
||
Subject: HERE IS THE RLL code! (unburied sooner than I thought...)
|
||
Message-ID: <226@octopus.UUCP>
|
||
Date: 16 May 88 19:57:19 GMT
|
||
Reply-To: pete@octopus.UUCP (Pete Holzmann)
|
||
Followup-To: comp.periphs
|
||
Organization: Octopus Enterprises, Cupertino CA
|
||
Lines: 38
|
||
Xref: ucdavis comp.sys.ibm.pc:17805 comp.periphs:1029 comp.sys.misc:1515
|
||
|
||
[Note: I've directed followups to comp.periphs, although I don't personally
|
||
read that group]
|
||
|
||
You asked for it; I happened to find a copy in one of my magazines (Fall
|
||
1986 Computer Technology Review)... so here it is: the RLL code!
|
||
|
||
I think you'll agree that it *is* a variable length code, with constant
|
||
encoding density. It is kind of fun to play with it and verify that it
|
||
really is a 2,7 RLL code. It isn't at all obvious how to start with "I
|
||
want a 2,7 RLL code" and end up with this chart:
|
||
|
||
Data Code
|
||
|
||
1 00
|
||
01 0001
|
||
10 0100
|
||
11 1000
|
||
000 100100
|
||
001 001000
|
||
010 000100
|
||
0110 00100100
|
||
0011 00001000
|
||
|
||
Have fun!
|
||
|
||
Pete
|
||
|
||
P.S.: People have requested the ERLL and ARLL codes. I don't have them handy.
|
||
I'm not sure I have a recent enough printed reference. I know where
|
||
to go (actually, who to talk to) to get the chart; but if somebody
|
||
on the net has the codes handy, maybe they can pipe up! I can't be
|
||
the only one with access to this stuff!
|
||
|
||
--
|
||
OOO __| ___ Peter Holzmann, Octopus Enterprises
|
||
OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014
|
||
OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete
|
||
___| \_____ Phone: 408/996-7746
|
||
|
||
|
||
|