pete@octopus.UUCP (Pete Holzmann) (06/05/88)
Mark Fife (VP of ???) at Perstor read my RLL articles on the net and was kind
enough to send me their official press releases, and some additional technical
info. Based on an analysis of that info, I am writing two articles: this one,
which talks about the new Perstor controllers, and another, which lists
RLL-compatible drives.
This article is intended to NOT be hype for Perstor. I am not duplicating
their press release; my analysis will (hopefully) show the weak areas as
well as the strengths.
This article assumes prior knowledge: if you haven't read my previous
article(s) on RLL technology, you may need to go find a copy and read it.
I'm sorry, but I don't have a copy myself [the positive response to that
article surprised me, to say the least!]
First, some corrections to definitions: people call the Perstor drives
'ARLL' drives because they have the same data density (31/34 sectors per
track) as what was originally called ARLL. Actually, Perstor appears to
be using a normal 2,7 RLL data pattern. They are getting the increased
data density by upping the clock rate, then compensating for the trouble
that causes in other ways. Since this is not the same as ARLL, they have
made up their own name: ADRT (Advanced Data Recording Technology, if you
*must* know).
I'll start with a short table showing some physical aspects of the different
RLL technologies:
Attribute 1,3 RLL 2,7 RLL 2,7 RLL 2,7 RLL
(MFM) (normal RLL) (ADRT 1.8) (ADRT 2.0)
Data rate 200ns/bit 150ns/bit 111ns/bit 100ns/bit
(5MBit/sec) (7.5MBit/sec) (9MBit/sec) (10MBit/sec)
clocks/bit 2 2 2 2
physical 100ns 75ns 55.5ns 50ns
clock rate
on drive
min/max clocks 2/4 3/8 3/8 3/8
pulse-to-pulse
on drive
min/max time 200/400ns 225/600 167/444 150/400
between pulses
on drive
(leading edge)
As you can see, there is no magic involved in the Perstor controllers.
They DO push the drive's parameters pretty far. Some discussion:
Clock rate on drive: This is directly related to that 'window margin'
spec we talked about earlier. Obviously, Perstor controllers
require much tighter window margins.
Min/max time between pulses: by increasing the clock rate, the Perstor
controllers get the maximum pulse interval closer to the original
design time for MFM drives (400 ns), than does a normal RLL drive.
The minimum pulse interval (high frequency rate) is much smaller
than for MFM or normal RLL.
The net result of these changes, especially since they are stressing the
high frequency/high pulse density end of the specs, is that
drives are more error-prone when data is written using the ADRT
timing. Thus, in order to have a viable product, Perstor had to
make compensating adjustments.
Here's what they did:
1) Instead of using a normal 32 bit ECC, they use 56 bit ECC. This will
more than compensate for the increased error rate expected, AS
LONG AS THE DRIVE IS ABLE TO STORE *SOMETHING*. In other words,
with increased storage density, more errors will result; but at
some point, the head/recording surface simply can't keep up:
the bits in error will go up to 100% (I supposes I should say
50%, since random bits will be right 50% of the time :-)). Thus,
a need for...
2) Specify carefully which drives will work. Specifically, Perstor
recommends:
a) Hi resolution media (plated or the latest oxides)
b) tight speed tolerance (old drives have 3% tolerance; Perstor
requires 1%, preferable .5%, which is common on modern
drives)
c) Temperature range must be kept to 'typical operational
environment' rather than 'extreme limits'. In other words,
reduced temperature range from drive specs.
CONCLUSION
The net effect of this is that, as with 'normal RLL' controllers, MOST
modern drives will work great with the Perstor controller. Some definitely
will not. Any dealer hype to the contrary is just that.
As far as I can tell, just about any drive that works with the Perstor
controller will work fine on a 'normal RLL' controller, which is why the
drive list in the next article is rather handy to have (thanks, Perstor!)
Note that the Perstor controller is currently limited to 1024 cylinders.
They are working on a new ROM that will handle more.
That's it!
Pete
--
OOO __| ___ Peter Holzmann, Octopus Enterprises
OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014
OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete
___| \_____ Phone: 408/996-7746john@bby-bc.UUCP (john) (06/07/88)
In article <243@octopus.UUCP>, pete@octopus.UUCP (Pete Holzmann) writes: > Mark Fife (VP of ???) at Perstor read my RLL articles on the net and was kind > enough to send me their official press releases, and some additional technical > info. Based on an analysis of that info, I am writing two articles: this one, > <good article on perstor controllers> There seem to be two classes of Perstor controller according to your article; is one obselete now? In their ads the controller seems to be a pc/xt type - do they have a 16 bit at controller? What does the controller look like to the operating system - does it pretend to have twice as many tracks (or heads) or does software have to know there are up to 34 sectors/track? I realize they probably provide software for dos but it would be real nice to be able to drop it into an AT unix box and have work (I know - probably too much to hope for). Thanks for another good article.
pete@octopus.UUCP (Pete Holzmann) (06/18/88)
In article <288@bby-bc.UUCP> john@bby-bc.UUCP (john) writes: >In article <243@octopus.UUCP>, pete@octopus.UUCP (Pete Holzmann) writes: >There seem to be two classes of Perstor controller according to your >article; is one obselete now? There *are* two classes. The first one is hardly obsolete; I can't even find one to buy yet! In fact, only the hard-disk-only versions of the first controller (1.9X) are available now. Hard+floppy and the new 2.0X version are supposed to be available later this summer. I'm sorry if I am spending too much time talking about vaporware. I doubt that the higher density type will replace the lower density one in the market. The lower density type works with most existing MFM and RLL drives. The higher density one will only work with the best of existing drives. >In their ads the controller seems to be a pc/xt type - do they have >a 16 bit at controller? They have both 8 and 16 bit bus versions. >What does the controller look like to the operating system - does it >pretend to have twice as many tracks (or heads) or does software have >to know there are up to 34 sectors/track? I realize they probably >provide software for dos but it would be real nice to be able to >drop it into an AT unix box and have work (I know - probably too much >to hope for). As far as I can tell, they do what most high-density-drive/controller folks do. They design for DOS. Under DOS, the first sector (?) on the drive contains a parameter block listing things like heads, sector size, sectors per track, etc. Their low-level format routine would set things up to look this way. I know little about Unix/Xenix on AT's. If *nix looks at the disk parameter block to figure everything out, you ought to be in good shape. >Thanks for another good article. You're welcome! 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
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (06/20/88)
In article <288@bby-bc.UUCP> john@bby-bc.UUCP (john) writes: | What does the controller look like to the operating system - does it | pretend to have twice as many tracks (or heads) or does software have | to know there are up to 34 sectors/track? I realize they probably | provide software for dos but it would be real nice to be able to | drop it into an AT unix box and have work (I know - probably too much | to hope for). Well, Xenix/386 (and 286, I'm told) asks for the heads tracks *and sectors* when installing. The heads and tracks can be configured to non-standard types, I would bet money (the price of the PS180 controller) that the sectors can be changed, too. I have some serious questions on how well UNIX handles sectors going bad when the system is running. What I've seen indicates that most AT versions don't handle it at all well... backups are guns; better to have one and not need it, than to need one and not have it. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me