Xref: utzoo comp.sys.ibm.pc:16141 comp.periphs:1003
Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!hplabs!pyramid!octopus!pete
From: pete@octopus.UUCP (Pete Holzmann)
Newsgroups: comp.sys.ibm.pc,comp.periphs
Subject: TECHNICAL DETAILS: Perstor RLL controllers
Message-ID: <243@octopus.UUCP>
Date: 5 Jun 88 15:10:14 GMT
Reply-To: pete@octopus.UUCP (Pete Holzmann)
Organization: Octopus Enterprises, Cupertino CA
Lines: 111

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-7746