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
�