wales@valeria.cs.ucla.edu (Rich Wales) (08/25/90)
I called Perstor a few days ago and had them send me one of their
brochures. I called them again today and just finished speaking with
one of their sales staff. Here's what I found out.
I asked how it was that Perstor could get reliable performance at such
high data densities, even on non-RLL drives. Their answer is that their
ADRT technique encodes the data more compactly, but still uses the same
flux density as MFM. The disk is =not= stressed beyond MFM specs; their
method works even on drives that won't take RLL at all. ADRT is =not= a
"compression" technique, so it should work no matter what a given sector
contains. I was, unfortunately, unable to get any more details on the
ADRT method (it's proprietary) -- but their sales brochure says it's
based on the "IBM 3370 DK" technique.
Perstor currently sells four different controllers:
(1) PS180-16FN, for a 16-bit bus. In addition to being able to handle
two hard drives, this Perstor controller (and =only= this model) can
also handle two floppy drives (5.25" and/or 3.5").
(2) PS180-8XT, for an 8-bit bus.
(3) PS180-8AT, for an 8-bit bus. The only difference between the -8AT
and the -8XT is in the BIOS chip. I think (but am not 100% sure)
that the -8AT will only work in a 286 or 386 system.
(4) ADRC-9008, for an 8-bit bus. This board gets 32 sectors per track
(instead of 31), but its transfer rate is 20-25% slower than the
PS180-8XT. Also, the low-level format program for this board is in
the BIOS (the other models come with separate formatting software).
The material I got in the mail also included a long list of drives that
Perstor says its controllers will work with. Some drives the salesman I
spoke with said will =not= work with a Perstor include Quantum, Tandon,
most Priams, older Fujitsus, and older Shugarts. Kalok drives, I was
told, are "hit-and-miss"; some models work, some don't.
If you connect two drives to a Perstor controller, their geometries need
to be "compatible" (though not necessarily identical). "Compatible" in
this context means that the two drives' sizes need to be in the same
"drive table". I specifically asked about the combination of 9x1024
(e.g., a Seagate ST4096) and 4x615 (e.g., a Seagate ST225 or Lapine
Titan 20), and was told these two geometries =are= compatible.
Jerry Pournelle favorably reviewed the Perstor PS180-16FN in his column
in the March 1990 issue of BYTE (p. 65).
Disclaimer: I do not work for Perstor. In fact, I'm not even a Perstor
customer yet -- though I suspect I will probably become one soon.
--
-- Rich Wales <wales@CS.UCLA.EDU> // UCLA Computer Science Department
3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683
"You must not drink the tea. It is deadly to humans."scjones@thor.UUCP (Larry Jones) (08/25/90)
In article <38331@shemp.CS.UCLA.EDU>, wales@valeria.cs.ucla.edu (Rich Wales) writes: > I asked how it was that Perstor could get reliable performance at such > high data densities, even on non-RLL drives. Their answer is that their > ADRT technique encodes the data more compactly, but still uses the same > flux density as MFM. The disk is =not= stressed beyond MFM specs; their > method works even on drives that won't take RLL at all. ADRT is =not= a > "compression" technique, so it should work no matter what a given sector > contains. I was, unfortunately, unable to get any more details on the > ADRT method (it's proprietary) -- but their sales brochure says it's > based on the "IBM 3370 DK" technique. ADRT is just Perstor's name for a particular version of RLL encoding. An RLL encoding simply maps a number of bits into a larger number of bits and guarantees that strings of repeating zeros and ones in the result will be between some minimum and maximum value. If the minimum is greater than 1, you can record the resulting bit string faster without having the flux changes be any closer together than normal. So, by picking your encoding carefully, you can record more bits in the same amount of space without increasing the flux density. The tricky part is that you can't let the maximum get too big, or you can't keep your clock synchronized and you start to loose track of exactly were the bits are. Also, as the minimum gets larger and you record faster, you need to know the location of the flux changes a lot more accurately to know exactly which bit it corresponds to. The traditional RLL encoding makes the tradeoff such that the maximum flux density is somewhat higher than for MFM and the timing of the flux changes is also somewhat higher. Perstor's encoding makes a different tradeoff that keeps the maximum flux density to be just a teeny tiny bit higher than MFM, but the timing is much more critical. This turns out to be a win for Perstor since many more non-RLL rated disks are capable of meeting their timing requirements than are capable of handling traditional RLL's higher flux density. ---- Larry Jones UUCP: uunet!sdrc!thor!scjones SDRC scjones@thor.UUCP 2000 Eastman Dr. BIX: ltl Milford, OH 45150-2789 AT&T: (513) 576-2070 Girls are like slugs -- they probably serve some purpose, but it's hard to imagine what. -- Calvin
phil@brahms.amd.com (Phil Ngai) (08/27/90)
In article <138@thor.UUCP> scjones@thor.UUCP (Larry Jones) writes: |The traditional RLL encoding makes the tradeoff such that the |maximum flux density is somewhat higher than for MFM and the timing |of the flux changes is also somewhat higher. Perstor's encoding I believe you are wrong about this. -- Phil Ngai, phil@amd.com {uunet,decwrl,ucbvax}!amdcad!phil