[comp.unix.i386] PerStor Controllers

orion@nuchat (Roland Dunkerley III) (12/22/89)

I am currently in the process of putting together a
machine, and have seen the ads for the PerStor Disk
controllers claiming to give 190% of the storage on a
standard MFM drive.  The drives I plan to use are a
Seagate ST-251, and an ST-4096.  If this gadget works
it would give me 228Mb instead of the 120 that these
drives provide, with a 9Mbit/s transfer rate instead of
5.  My question is have any of you used the PerStor
controllers, do they really work as advertised on
standard drives with no problems?  What technology do
they use to accomplish this?  I will be running Unix
System V/386 from Bell Tech on this box, has anyone
gotten such a combination to work with BellTech Unix,
or with any other SV/386?  Oh, the release number is
3.0 if that makes a big difference, I had heard that
scsi controllers don't work without the 3.2 update...
As usual, please reply by mail, and if anyone else
wants to know I'll either forward the info to them, or
summarize and follow-up.

   thanx in advance,
    Roland Pleasant Dunkerley III, K.S.C., NonD
    (orion@nuchat.sccsi.com)
    K A T E   B U S H   I S   G O D !

baxter@ics.uci.edu (Ira Baxter) (12/23/89)

orion@nuchat (Roland Dunkerley III) writes:

>I am currently in the process of putting together a
>machine, and have seen the ads for the PerStor Disk
>controllers claiming to give 190% of the storage on a
>standard MFM drive.  The drives I plan to use are a
>Seagate ST-251, and an ST-4096.  If this gadget works
>it would give me 228Mb instead of the 120 that these
>drives provide, with a 9Mbit/s transfer rate instead of
>5.  My question is have any of you used the PerStor
>controllers, do they really work as advertised on
>standard drives with no problems?

I evaluated a Perstor PS180-16F controller, and its immediate
predecessor (I don't remember the model number) with both ISC 1.0.5
and 2.0.2, as well as dull ol' DOS.  The short analysis: it does work,
but I decided against it.

It was rather awhile ago, so I may have the details a bit fuzzy, but
this is what I remember.  A special set of installation programs are
required to set up the Perstor.  I found these programs to be rather
inferior in maturity, but they did work; typical problems were menus
that offered (at different times!) choice of obviously garbage disk
configurations, and a program to choose-the-best-interleave that
couldn't compute the transfer rates correctly... so you had to
determine the best interleave (I remember it being 3) yourself.  I was
pretty incensed that such trivial errors were present in a supposedly
mature product; perhaps these stupidities have been fixed by now.  One
must use the formatter provided by these programs rather than the ISC
formatter.  I don't remember any tools provided by Perstor to mark the
manufacturer-supplied bad block list, so they have to be re-discovered
(if re-discoverable) by the ISC surface-analysis process.  Since the
controller isn't very fast, the additional drive capacity provided by
the Perstor actually makes this more of a nuisance rather than less.
This business about 9Mb/sec transfer rate is max burst rather than
sustainable; there isn't any track buffer, and with a best interleave
of 3, the best sustainable transfer rate was about 250Kb/sec; this
wasn't much better than my MFM WD1003 controller that I wanted to
replace.  Last, but not least, the first controller they sent me would
format but produced zillions of errors during surface analysis;
Perstor finally replaced it with the PS180-16F and the problems went
away.  They claimed the problem was "marginal VCO" chips from their
chip vendor, but I think the real problem is that the entire design is
marginal (pushing the drive right to the edge of what it can do), and
their software support didn't give me a very good feeling about their
quality control.

The up side: the controller does work, and with a Maxtor 2190 (MFM
rated for 150Mb) one gets an awesome 290+Mb of real capacity.  Both
1.0.6, 2.0.2, and DOS 3.10 (with a 32Mb partition) seemed to work fine
for the day or two that I ran them.

>                                  What technology do
>they use to accomplish this?

The folk at Perstor are pretty closed-mouthed about this.  I suppose
one could guess by inspecting the chips on the board fairly carefully,
which I haven't done.  Considering the trouble I had with the
predecessor board, which was quoted as being due to the "marginal VCO"
chips by the factory tech, I would guess they simply run a higher bit
rate at the drive, and count on their 56-bit ECC to save them.  That
doesn't leave one with a warm feeling about the reliability of the
inner tracks.


>[stuff about potential configuration deleted]
All of my remarks are, I think, OS independent.

>   thanx in advance,
>    Roland Pleasant Dunkerley III, K.S.C., NonD

I finally chose to use a WD1006SRV2, which is RLL compatible, on my
Maxtor.  It doesn't double your capacity, but it does raise it
signifcantly, and with the track buffering, one gets around 500Kb/sec
sustained transfer rate.  ... and its cheaper than the Perstor (your
cost may vary).  The bad news is the WD1006SRV2 has its own peculiar,
but quite rare, lock-up problems, see the ongoing thread in this newsgroup.
I have been using the WD1006SRV2 for several months now, and except
for the rare hiccup, I'm very happy with.  Now, if we can only resolve
the hiccup...

Anybody want a very slightly used Perstor controller, cheap?
--
Ira Baxter

tron1@tronsbox.UUCP (HIM) (12/24/89)

>I am currently in the process of putting together a
>machine, and have seen the ads for the PerStor Disk
>controllers claiming to give 190% of the storage on a
>standard MFM drive.  The drives I plan to use are a
>Seagate ST-251, and an ST-4096.  If this gadget works
>it would give me 228Mb instead of the 120 that these
>drives provide, with a 9Mbit/s transfer rate instead of

I run a Perstor here , MAKE SURE YOU ORDER THE 16FN (network model) , and it
runs LIKE A CHAMp. NO problems whatsoever. The folks at both ISC and
perstore were a bit surprised I might add. 

Here is what I got...

   74.3 or so megabytes from my ST-251
  151.4 or so megabytes from my ST-4096

NO problems from either drive, no special installation tricks...

1) Boot under DOS
2) RUN PERSTORE's low level formatter (do a full surface verify)
3) Run PERSTORE's CMOS setup.
4) Install UNIX .. DO >NOT< format the device (would blow away the 'custom
   format) .... and DO ANOTHER READ/WRITE  VERIFY.

Thats it , you are all set from there on in.

One thing , MAKE SURE THE HD YOU WANT TO RUN HAS < 8 defects (ISC only
allows ?256? bad sectors, and any bad track on the drive is 31 of em!).. 

>it would give me 228Mb instead of the 120 that these
>drives provide, with a 9Mbit/s transfer rate instead of

Sounds about right

Am posting here and in email.

IN SHOT -- THIS THING WORKS and is the greates undiscovered treasure for
small UNIX owners , a 90% HD space increase for approx 160$ is NOT to be
laughed at!

(grin)

****************************************************************************
"Perfume and leather baby , you and me together baby,
  what good is living in paradise, if you don't let yourself once or twice."
 -Tiffany  
 
 Kenneth J. Jamieson ---- THE BOSS at Xanadu Enterprises Inc.
      UUCP: tron1@tronsbox.UUCP  BEST PATH ---> uunet!tronsbox!tron1 
      Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568 
****************************************************************************

daveb@i88.isc.com (Dave Burton) (12/28/89)

|>[I] have seen the ads for the PerStor Disk
|>controllers claiming to give 190% of the storage on a
|>standard MFM drive.  The drives I plan to use are a
|>Seagate ST-251, and an ST-4096.  If this gadget works
|>it would give me 228Mb instead of the 120 that these
|>drives provide, with a 9Mbit/s transfer rate instead of

... which is quite enticing ...

|I run a Perstor here , MAKE SURE YOU ORDER THE 16FN (network model) , and it
|runs LIKE A CHAMp. NO problems whatsoever. The folks at both ISC and
|perstore were a bit surprised I might add. 
|....
|IN SHO[R]T -- THIS THING WORKS and is the greates[t] undiscovered treasure for
|small UNIX owners , a 90% HD space increase for approx 160$ is NOT to be
|laughed at!

... but it doesn't work with _all_ UNIX systems. In particular, it
doesn't work with ESIX (Rev A,B,or C). A short talk with PerStor
revealed that the PerStor controller only worked with ISC 386/ix -
their words, not mine. Bummer.

| ... for approx 160$ ...

I paid $269 through Hard Drives Int'l for the hard+floppy version.

Disclaimer: Although I have some affiliation with ISC, this posting
is based on personal experience through my home system running ESIX.
This isn't intended as a plug for ISC, nor a slam against ESIX. In fact,
I'm quite pleased with ESIX.
--
Dave Burton
uunet!ism780c!laidbak!daveb

tron1@tronsbox.UUCP (HIM) (12/28/89)

I DO NOT intend this as a flame, but I would like to correct some points
before harm is done to a fine product:

(BTW , they don't pay me a dime)

>  Resp: 2 of 2 by *Masked* at ics.uci.edu
>Author: [Ira Baxter]
>  Date: Sun Dec 24 1989 17:29 EST
> Lines: 84

Writes:

>this is what I remember.  A special set of installation programs are
>required to set up the Perstor.  I found these programs to be rather
>inferior in maturity, but they did work; typical problems were menus
>that offered (at different times!) choice of obviously garbage disk
>configurations,

There is a reason for this. The perstore controller needs to re-assign to
device list in the CMOS drive table.  This means that when you run the
perstore drive configuration program, it will read the type from the CMOS
(wich was put there by you NORMAl cmos program) and interpret that against
ITS drive table, and get a bad config.  This goes away after the CMOS has
been done with the Perstore software.  

Example: My 4096 is a type 4 on the perstore list , but a dos program like
Disk Manager will get REAL confused when it looks up type 4 in the ROM table!

>manufacturer-supplied bad block list, so they have to be re-discovered
>(if re-discoverable) by the ISC surface-analysis process.  Since the

Actually , you can add the manufacturer list , I didnt , as with the new
format radically changing the sector layout , that information was moot
anyway. What I did was spen timeon the phone to a guy at Seagate, he
interpreted the bad track info with me into what sector was REALLY bad (that
caused the track to be flagged) and then I mapped THAT into the new drive
layout and locked out THOSE sectores.

>(if re-discoverable) by the ISC surface-analysis process.  Since the
>controller isn't very fast, the additional drive capacity provided by
>the Perstor actually makes this more of a nuisance rather than less.

Geeee... too much drive space a PROBLEM ??? (grin) ... face facts , for most
reads this doesn't matter MUCH (I hope ;-) that I have noticed, and what HAS
helped is the fact that the amount of HEAD track to track movement is way
down. (On sequential reads on a contiguous file , there are 31 sectores per
head step instead of 17) 

>chip vendor, but I think the real problem is that the entire design is
>marginal (pushing the drive right to the edge of what it can do), and

Hmmm.. wouldn't know , But havent had ONE problem in MONTHS.

>their software support didn't give me a very good feeling about their
>quality control.

Too bad. Everyone I talked to was GREAT.

In fact , they are VERY glad to see UNIX folks start to take an interest,
they will BEND OVER backwards to gain acceptance with the UNIX crowd on
386's so mention that when you call ! (grin)

>The up side: the controller does work, and with a Maxtor 2190 (MFM
>rated for 150Mb) one gets an awesome 290+Mb of real capacity.  Both
>1.0.6, 2.0.2, and DOS 3.10 (with a 32Mb partition) seemed to work fine
>for the day or two that I ran them.
 
Not bad huh?

>chips by the factory tech, I would guess they simply run a higher bit
>rate at the drive, and count on their 56-bit ECC to save them.  That
>doesn't leave one with a warm feeling about the reliability of the
>inner tracks.

I dont >think< this is it , I was led to beleive they were playing with the
intersector gap on the track.  Oh well, it works!

>All of my remarks are, I think, OS independent.

Correct.

>I finally chose to use a WD1006SRV2, which is RLL compatible, on my
>Maxtor.  It doesn't double your capacity, but it does raise it
>signifcantly, and with the track buffering, one gets around 500Kb/sec

What capacity do you get ?? And is that drive RLL rated ??? I would think
that the trick of running RLL on a non RLL drive is at least as risky ??



****************************************************************************
"Perfume and leather baby , you and me together baby,
  what good is living in paradise, if you don't let yourself once or twice."
 -Tiffany  
 
 Kenneth J. Jamieson ---- THE BOSS at Xanadu Enterprises Inc.
      UUCP: tron1@tronsbox.UUCP  BEST PATH ---> uunet!tronsbox!tron1 
      Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568 
****************************************************************************