Request for disk info

[Doug Urner]

In article <3239 at megatest.UUCP> palowoda at megatest.UUCP (Bob Palowoda) writes:
>From article <7715 at killer.Dallas.TX.US>, by larryd1 at killer.Dallas.TX.US (Larry Clark):
>> 
>>      My employeer has need of large, high reliable disk drives with high
>>      data transfer drives. The micropopolis esdi drives meet the data
>>      transfer rates nicely, but their mtbf falls short by some 10,000 hours.
>> 
>>      Can anyone recommend a manufactorer who makes drives that have a
>>      capacity of 150 megs or greater and a MTBF of 50,000 hours?  Price is
>>      not a factor, but data transfer rate is, so I suspect that ST506 is
>>      out and esdi or scsi is in.

According to the distributor that we are using CDC either just upped the MTBF
rating of their Wren drives to 50,000 hours, or is about to.  Currently they
are rated at 40,000 hours with a 5 year service life (whatever that is).

>  On the subject of disk transfer rates I have been reading some interesting
>  results of these benchmarks in MIPS magazine. The one that caught my  
>  attention is the Rupp 386 machine using a ESDI controller with cache for
>  the controller. Other ESDI setups transfered 100k/bytes/sec (1meg/1task)
>  and the Rupp controller did over 400k/bytes/sec(1meg/1task). 
>  Rupp Computer products advertise this disk controller as "PM3011 Caching
>  Controller". List for 1150.00. Does anyone know who manufactures this 
>  controller?

The PM3011 is made by DPT (Distributed Processing Technology) in Maitland, FL,
305/830-5522 (might be area 407 my Rolodex and the company propaganda differ,
I'm inclined to trust the Rolo since I used it to get the propaganda).  The
controller comes in ST506, RLL and ESDI versions.  The ESDI version (at least)
supports up to four drives.  The controller emulates a WD1003 so it supposedly
will co-exist with any OS that will run on a "standard" AT.

>  Another question is how do different ESDI device drivers affect the 
>  disk tranfer rate.

Some factors in how a driver will influence disk throughput are the interleave
that the driver supports and how efficently the driver manages the disk arm.
The early 386/ix drivers could not support 1:1 interleave and the disk 
throughput was terrible (and even worse if you set up your fancy 1:1 hardware
with a 1:1 interleave...).  The later 1.0.6 driver (the "High Performance
Disk Driver") did about 500 K per second for transfers up to 250 K where it
dropped off to about 40 K per second.  The 2.0.1 driver does about the same
on small transfers but holds up at around 100 K per second up through 1 MB.
I think the fall off on large files is due to running out of buffers (though
it is interesting to note that 2.0.1 uses less memory for buffers than 1.0.6).

>  And why or how did the caching controller override this limitation?

The controller can have up to 16 MB of memory.  For $1150 you get 512 K of
memory on the controller.  I would assume that part of what you were seeing
was the relatively low access time of the ram on the controller:-).

Also if the file system is not too fragmented the cache may be able to have
the next block(s) that you read in the controller's memory saving a disk
access.
--------------------------------------------------------------------------
Doug Urner, Uni-Ops Systems, Bellingham, WA  206/676-5759  dlu at wobble.UUCP