DPT ( http://www.dpt.com) builds a complete line of SCSI
raid controllers. This review is of the PM3334UW Smart Raid IV
(note: even at the time this was written, DPT had already announced
a new generation of SmartRaid V conrollers).
The controller was installed in a clone box using an Asus
motherboard with a 350 MHZ Pentium II, 128 MB memory, and 4 (four)
IBM DDRS 34560 SCSI (40 MB/second) drives. The controller itself
was configured with 8 MB of cache memory.
The physical configuration of the machine was done by the
customer's Windows hardware supplier. These kinds of suppliers
usually don't understand SCSI at all, so I didn't expect much. In
this particular case they came close: they terminated the right
drive, and only one drive, and actually even understood that an
external DAT tape drive meant that the controller needed to be set
for HIGH termination only. They even took the trouble to label each
drive with what they thought the SCSI ID's would be; unfortunately
that was all completely wrong because these drives use 4 bit
addresses, and what they thought was a spare jumper is actually the
jumper that controls the high (ID 8-15) addresses. Further, none of
the drives had id 0, so that isn't a good setup under normal
conditions.Still, I've had Windows vars do much worse, so I didn't
They didn't even attempt to configure the array, explaining that
they had no knowledge of such things and that I'd probably want to
set it up "my way" anyway. Fine by me.
The DPT board comes with a pretty good manual. I've installed a
few of these in the past, so I just gave it a quick look to see if
anything had seriously changed, and it hadn't. The first thing you
need is a bootable floppy disk. After booting with that, you can
use the DPT DOS installation disk to configure the array.
The first thing it asks is if you want to make OS installation
disks. Of course you do, and it brings up a colorful display of the
various OS's it supports, which of course includes SCO, Linux, NT
and just about everything else. For SCO, you are creating a BTLD
that will be used later.
After creating the specific OS disks, it's time to configure the
array. I forgot to make the floppy disk know anything about mice,
so I couldn't take advantage of the full GUI nature of the array
configuration utility, but using it without a mouse is fairly
intuitive: arrows move you around, space bar is equivalent to
The DPT supports mirroring or RAID 5; for this configuration I
put all four drives into one RAID 5 array. I could have designated
one drive as a hot spare, but we needed the drive space, so I used
them all. That ends up with about 12 gig of usable space. You begin
that process by choosing "Create Array", which lets you choose what
type of array, and asks you to choose drives for it. One mistake I
made using the tool is that after you say you are done selecting
drives (which you signify by clicking "Done"), you have to
specifically include them in an array by choosing "Include". If you
miss that as I did, you haven't created anything.
Once you either "set" the configuration (a menu choice) or save
it and exit, the controller begins building the array. If you
simply choose "Set", you can remain in the GUI and watch the
progress. It took about 20 minutes to complete on this machine.
After completion, it was time to load SCO. The BTLD called for
is "dptr5", and this needs to replace a dptr driver built into
OSR5. Unfortunately, the instructions for this could lead someone
astray: it tells you to answer the driver conflict by typing "25".
This apparently was the address of the dpt driver in some release
of SCO, but in the 5.0.5 I loaded it's now at 20. Those
instructions need to be made more generic.
The installation was very quick, requiring only twenty minutes
of actual time after all questions were answered. It probably would
have been even faster if the CDROM were SCSI instead of IDE.
It was the testing after installation that proved the
performance of this controller. Before installing other software
(RS505a, Visionfs and SCO Proxy Server, Microlite Edge), I fired
off 10 foreground tasks (one on each of tty03-tty12) that
continuously ran "lr" on the root and redirected the output to a
differently named file in /tmp. I then fired off two background
jobs doing the same thing on tty01, and two Unix windows on tty02
with the same kind of job. I modified the "sys" crontab to run sar
more frequently (every five minutes), and enabled sar. I then
proceeded to install the software.
I can honestly say I did not notice the other jobs at all. My
installation seemed normal, keyboard response was snappy, I really
wouldn't have known anything was going on if I couldn't have heard
the disks running, and they were running hard. The run queue was
well over 7.8 regularly, and of course was 100% occupied. The "sar
-d" showed the drive (actually 4 drives, but it looks like 1 drive
to the OS) as 100% busy, transferring over 700 blocks per second,
yet avserv remained just over 5 ms throughout, and avwait never
System cpu time ran about 70%, user 26 to 28, but wio never
exceeded 2. That's impressive performance for an inexpensive
Of course, such artificial tests really don't prove anything. It
will be a few weeks before this box gets to serve up the real data
it was purchased for, but we'll get the true test of it's strength
then. The current machine handles 25 users in a very disk intensive
program on an IDE drive. It's a good IDE drive, but it is often
brought to it's knees by the load. This box should provide a