 VOICE Home Page: http://www.os2voice.org |
[Previous Page] [Next Page] [Features Index] |
|
VOICE Home Page: http://www.os2voice.org |
[Previous Page] [Next Page] [Features Index] |
By Thomas Klein December 2000Price: Approx. 199 German Marks (approx. 100,00 Euro / 97.00 US-$) |
During the past few years, I met a lot of people who have decided to use SCSI
systems at home due to their familiarity with them in their professional environment.
I have to admit that they are in a minority, but on the other hand they all believe
and trust in the advantages of the concepts behind SCSI.
But when talking to them about SCSI at home, it's usually all about one single
brand: Adaptec. I consider this to be a compliment regarding the outstanding quality
of their products and drivers (and their Marketing as well), but we should not forget
to point out the existence of other manufacturers as well, who provide alternate
and quite interesting solutions. Today, I would like to introduce one of those manufacturers
- Dawicontrol - by means of their UltraWide-SCSI3-PCI-Controller named DC-2976UW.
Made in Germany
Years ago (in the mid-80's I guess) there was a funny German TV show, that made
a joke of this slogan by presenting a sleek luxury car of a well-known German brand
(the one that merged with an American brand recently), wearing a fat banner "made
in Germany" across the windshield. But with the camera closing in more and
more, the audience could read a tiny "printed in Taiwan" on that banner.
Although I really loved that joke and I'm okay with the meaning behind it, I'm
always quite disappointed when people are surprised to hear Dawicontrol is a German
brand of SCSI controllers. Apparently "German hardware" nowadays means
cars, tanks, washing machines and at least some bulky high-priced PC stuff... Now,
Dawicontrol proves this to be wrong.
By chance
Actually it was due to the breakdown of an Adaptec AHA-2940, that my attention
focused on those products from Göttingen, and merely by chance that I encountered
a DC-2974, an incredibly inexpensive PCI-SCSI-Controller, that seemed to have everything
needed to replace the Adaptec model.
Now, as an OS/2 user, I always try to proceed carefully when there's a need for
hardware. At least about drivers, you know.... But to my surprise their homepage
stated that all products supported OS/2. I finally decided to give it a try and
was not disappointed. After plugging in, attaching cables and editing CONFIG.SYS
to use the new driver everything went as before (it really could have turned out
different...).
Some years have passed since those days. Now it's a DC-2975U running my server,
and the DC-2974 running my wife's workstation (at least until some weeks ago, when
I needed it as a spare part). So I found it to be a good occasion that my Adaptec
AHA-2940UW broke down just recently (why do they always simply do that?). Once more,
I decided the next family member should be of Göttingen breed.
On first sight
The OS/2 logo is shown on both the package and the
quick reference. Nice to see it is still around.
The ecological-minded ones among you will certainly appreciate the fact, that
no bubble-wrap, foam pads or other plastic material was used in the package - it
consist entirely of paper, with the exception of the antistatic protection bag (inevitable!)
and the shrink wrap around the box. I consider the latter to be necessary as some
kind of seal, showing that the box contents are intact and complete.
Once unpacked, we find the box contains the controller,
a printed quick reference, the driver disk and the two internal flat-ribbon cables
(50-pin and 68-pin type).
On second sight
The chip used on the DC-2976UW is a SYM53C875 by Symbios (who recently became
"LSI Logic"). This is quite important for it gives us some useful possibilities
regarding installation and operation as you'll see later in this article. The controller
provides three connector plugs: Internally both 50-pin and 68-pin and an external
68-pin high density (HD) plug. Only two of them can be used together - this
is due to the fact that the controller operates two buses and the principles of
SCSI, placing the controller "electrically" in the middle of the SCSI
chain. Attaching devices on each of the three connectors would result in a star-shaped
SCSI topology... which equals: Trouble. This limitation sometimes is some kind of
annoying but it's quite common on controllers of this class.
Each of the two cables that come
with the adapter provide three connectors. This means that you'll be able to attach
two devices to each the 8-Bit bus (50-pin cable) and the 16-Bit bus (68-pin cable),
as the third connector is used to be attached to the controller itself of course.
This should be sufficient for most private users - those who own more devices certainly
already own appropriate cables too. The DC-2976UW features two jumpers that are
used to determine the termination settings of each of its two buses. These jumpers
are factory-preset to Automatic, making the controller detect whether devices
are attached and enabling/disabling termination for each bus accordingly.
I don't want to go into the principles of SCSI too
deeply at this point. Just let me say that, yes, termination can be set to ON
or OFF manually, but as far as I am concerned, automatic always worked
for me until today, regardless of internal/external devices, configuration or manufacturer.
While reaching for the cordless screwdriver and
puzzling whether it's kid or cat who's to blame for the loss of the Phillips tip,
I happen to take a glance at the manual. Why did they change its name to "quick
reference" and how comes it is much thinner than before? A single look at the
contents page makes me know what has happened:
No sign of
OS/2 (and no sign of Linux or Novell either). Only Windows 95, 98, NT and
2000. Another look - now at the first page - clarifies the situation:
Fine but... too bad: There was no CD included in my box... and given the situation
my PC would lie in pieces to my feet: How to access the Internet in that case, well?
Okay, okay - the drivers are included on the disk and we all know what to do,
but troubles start here if you're new to SCSI or OS/2 (yes, I was told this still
happens). I really don't understand this - I always had the memory of Dawicontrol
being *the* example for good manuals... now look at this.
Well, I downloaded the PDF and it is as good as I remembered, but it would have
been even better if I had found it in front of me, right after opening that box...
like before... or on that cute CD which was not included (or even on a separate
floppy disk as the PDF only takes up 245K).
Talking of floppies reminds me to mention that a lot of inexperienced SCSI-users
consider their usage (instead of CD) as antiquated
. Okay, but how do you access the drivers on a
CD if you haven't got the drivers for that CD drive... any suggestions? Of course
[sigh] there are ways and means to access the data without an additional PC
and of course
there are people without a floppy drive, but
anyway: Floppies are best in this case. Hmm, this makes me think: What if *that*
is the reason for this missing CD? ;)
Hardware setup
The "Dawi" plugs into
the second PCI Slot, that already hosted it's predecessor - and fits perfectly.
Even tightening the screw doesn't make it pull out of the slot - well done. (My
computer's case apparently has proven to be some kind of reference device for this
purpose).
I don't worry about IRQ's. As I don't have any IDE
devices in that PC, I deactivated both on-board IDE controllers thus freeing their
IRQ's. I can't stand plug and play (for a personal reason, but that's another story)
so I manually assign resources. The AGP slot taken up by my Matrox G200 is assigned
IRQ14, the 2nd PCI slot (used by the SCSI-Controller) is assigned IRQ
15.
This leaves only the internal cables to be attached
to finish hardware stuff. I don't use a scanner with that PC. This allows me to
use both internal connectors - just as with an Adaptec's 2940UW. There's only the
ultra wide IBM disk attached to the 16Bit bus; all other devices connect to the
8Bit-cable: CD-Rom, CD-Writer, Streamer, Zip-Drive and second hard disk..
Termination was already correct
on both cables before, so was the SCSI ID assignment, and as I didn't change a single
thing of that I keep going on immediately...
First boot-up
Usually at boot time there's a moment after POST (power-on
self test) where the system scans for IDE devices - this is now replaced with the
messages from the SCSI controller appearing. Along with BIOS Version they contain
information on the resources assigned like "my" IRQ15 and the ROM- and
I/O-addresses which are set automatically. Like any other SCSI-Controller with a
built-in BIOS, the DC-2976UW also shows a message on how to enter it's BIOS setup.
While Adaptec prefers <ctrl-a> and Tekram uses <F2> or
<F6>, the folks from Dawicontrol decided to let their controllers behave
like the Phoenix' or AMI's BIOS and use the <del>-key instead.
If you don't enter BIOS setup, there's a 15 second
delay next. This is done at each "real" power-on (not reset or ctrl-alt-del)
and can be overridden by pressing the <esc>-key, as shown in the message
on screen. Some older SCSI devices need additional time to gain a specific initial
state (e.g. rotation speed), before they can be operated. Any activity before this
point (like a bus scan) might result in erratic behaviour of such devices, thus
leading to an increased duration of the scan or incomplete device list. This delay
(so-called Power-On Wait feature) can be enabled/disabled in the controller's BIOS
setup.
The bus scan doesn't quite provide a wealth of information
to the user. It consists of the controller's own SCSI ID and a list of all devices
having BIOS support at boot time. Each of these devices is displayed by SCSI ID,
manufacturer and model name. For hard disks, you'll find the drive letter assigned
by the controller's BIOS and the number of heads and sectors used by the controller
to access the disk - that's all.
I can't tell whether there's a need to display additional
information at this point, like for example about sync/async communication or maximal
transfer rate of a device, since these features can be influenced by specifying
appropriate device driver parameters at a later time - Dawicontrol doesn't provide
this information anyway. Another point is the drive letter "assigned".
I rather consider this to be some kind of visual representation whether a hard disk
is supported and in which sequence... I would prefer disk number
here, because as users of OS/2 we all know that
strange things can happen to drive letters, depending on the operating system being
loaded. ;)
Anyway - at this point it's the operating system being loaded. For me this means
that it's the OS/2 boot manager appearing - a good occasion to take a closer look
on one of the more important components of the controller: It's BIOS.
Controller BIOS
As I already mentioned, the controller's BIOS provides
a way of governing some of the controller's features. All hardware resources (IRQ,
I/O-address, ROM-address) are being assigned automatically by means of plug-and-play-negotiation
between the controller and the PC (between their BIOSes to be exactly). There's
no way of changing this - except that you might assign an IRQ for the controller's
slot manually in the PC's BIOS. One of the editable features is "Power-On Wait",
which can be enabled or disabled - it's delay time however is fixed to 15 seconds.
The boot device can be selected by specifying it's SCSI ID. This is preset to
SCSI-ID 0 which turns out to be the standard setting in SCSI world. You can also
choose the SCSI-ID to be assigned to the adapter itself. It's default setting is
"automatic" - in my case this turns out to be 7 - the "classic"
SCSI Controller ID.
The BIOS supports bootable CD's, but I have to admit that I didn't check for
that as I don't have such a CD. There's support to use removable disks as hard disks,
but I didn't check that either, as well as support for multiple LUN's (multiple
logical unit numbers - that's the case in a CD changer for example). So far the
settings of the controller itself.
Up to 15 devices are supported. This will give you
a maximum of 16 devices including the controller itself. Each device provides the
following settings on the single BIOS setup screen (the default value of each setting
is underlined):
|
BIOS support |
yes / no |
|
disconnect / reselect |
yes / no |
|
transfer method |
automatic / sync / async |
|
transfer width |
automatic / 16-Bit / 8-Bit |
|
maximum transfer rate (MB/sec.) |
40 / 32 / 26 / 22 / 20 / 16 / 13 / 11 / 10 / 8 / 7 / 6 / 5 / 4
/ 3 / 2 (> 20 if transfer with set to "automatic" or 16-Bit) |
Setting BIOS support to "no" will result in the specific
device being invisible to accesses through interrupt 13h at boot time of the operating
system. This changes when the controller's driver is being loaded, initially supporting
every device attached (with the exception that appropriate command-line parameters
were specified). Regarding the use of this behaviour, I must admit that I need some
extra time to figure it out... but I am sure that there can be some situation where
you don't want the booting operating system to have access to all devices attached.
Enabling Disconnect/Reselect will make the corresponding device disconnect from the SCSI-bus during process of a command, then reconnect when ready. This makes the SCSI bus available for other actions or commands. A document scan for example would completely take up your SCSI bus until the task is accomplished - thus preventing you from doing anything else. Fortunately this option is enabled for all devices. Unfortunately, there are a lot of scanner models out there, that don't support the disconnect/reselect feature - letting you drop back to the "hourglass" effect.
It's a mess that this screen doesn't make use of the device names but rather
their ID's only. Showing the names would require a scan for attached devices, which
is not possible from within the setup screen. In boot sequence, this scan actually
happens to take place after the BIOS setup .entry point.
I guess this was done to enable entering the setup immediately without having
to wait for a completion of the scan process that could take up a lot of time in
case that there's something wrong on the SCSI bus. I have to admit that I prefer
Adaptec's solution: The BIOS setup starts with a menu screen allowing you to choose
between the controller options and the device options. Latter option will automatically
invoke the scan. That's not the real McCoy either but it's more comfortable to the
user in my mind.
To conclude with the BIOS setup I can say that it's
okay with me, even if it seems a bit poor compared to other manufacturer's solutions
which sometimes even include low-level formatting or media verification (surface
analysis) of attached hard drives.
At Dawicontrol they decided to put these functions into a DOS utility program
contained on the (non-bootable) drivers disk. This program also handles flash upgrade
of the adapter's BIOS by the way.
Okay now, one can argue whether such functionality has to be part of a BIOS setup
or whether it's preferable to put them somewhere else, as they did at Dawicontrol.
Driver install - take one
Personally, I like to distinguish
between two ways of playing that game: First we have the install into a "running"
system (if you're changing from previously installed different adapter for example)
and second, an install within the OS installation process - that is to say, on a
naked system.
In the first case (OS/2 is already installed)
it would be possible to boot into a non-WPS OS/2 shell by pressing <AL
T-F1>, then <F2> thanks to the adapter's support for
INT13. There might be that message that the (previously installed) driver cannot
be loaded and yes, you won't be able to operate your CD drives - but who cares?
This would be sufficient to copy DC2976.ADD into the \OS2\BOOT directory,
make the appropriate changes to CONFIG.SYS and everything would be okay...
if you're lucky.
If you're not lucky, well, this would mean that the
algorithms used for formatting by the controller manufacturer's aren't compatible.
This can be noticed quite quickly - by a TRAP message. This will result in being
forced to do a format. At installation time there can be a problem with OS/2 accessing
the existing partition... frankly speaking: Prepare to have a hard night. If you
don't like low-level formatting because of your hard disk's size you should at least
consider to remove the target partition for install by using FDISK.
In general you can expect any Symbios-driven controller
to be able to "understand" hard disk geometries created by an Adaptec
controller. This is quite useful in case of not having a (current) backup of a specific
hard disks or when dealing with removable hard disks being used in different systems.
If you have the occasion to do a low-level format, you should give your controller
the chance of doing so - the native access methods are always faster than any kind
of emulation - regardless of how good they might be.
But let's stay with the facts - in my case everything
went okay.
Anyway - this would be too simple, wouldn't it? Fine - here we go:
Driver install - take two
Some weeks ago I already thought of doing a complete
reinstall of OS/2 - so I found it to be a good occasion to go for it. Only requirement:
A running system with a floppy disk drive.
I guess you know what's next: Adopting Disk 1 to make room for the driver(s)...okay.
First, make a copy of Disk 1, delete CDINST.EXE and the README, then
copy the driver onto it and edit CONFIG.SYS in the proper manner. (By the
way: I prefer to remove all other "ADD's" belonging to controllers and
all "FLT's" belonging to CD-ROMS by insertion of REM, making DC2976.ADD
the only driver being loaded. Removing the snooper stuff can be done as well of
course, but that's not the subject we're talking about right now).
Oh, yes: SET COPYFROMFLOPPY=1... whew, brother
- don't forget that one! ;)
Now put in that Warp CD and the install disk and let's see what's happening... hmm...
now that's cute... everything works. Oh come on - that's kinda boring...
;).
But anyway - it makes me notice,
that more information is displayed at driver load time (with option /V) than at
hardware boot. Along with the resource data (the same as at startup) it displays
the driver's version, the power save mode selected (only configurable via the driver,
default: disabled) and within the device list an additional column showing whether
a device operates in sync or async mode.
The first glitch of the drivers
is the absence of a presence checker for the controller (or chip at least). This
can be noticed after the text-based part of the install process, when the install
program's up: The selection list "support for SCSI-Adapters" shows "none".
Well, to make this work, there's a lot more to do than the install process allows
you to do. The SCSI.TBL must be edited and the presence checker program has to be
included on the driver disk. Facing the efforts necessary for making a suitable
"disk 1", they could have documented the (optional) steps required to
enable automatic detection as well. But this would go too far - asking manufacturers
to do some enhancements to IBM's tightened install process... anyway: I can't figure
out, why there is a presence checker publicly available at the chipset manufacturer,
but it has not found it's way onto the Dawicontrol disk.
After checking out if ZIP, CD
and Streamer are functioning, there's really nothing to complain: The controller
performs absolutely comparable to an Adaptec 2940UW and runs stable.
That's all I want. Now we'll take a look on FixPaks, as we're still running Warp
4 GA. Everything works as expected, except...
FP14 (and kernel fixes)
This will lead us to the second
"glitch" of the Dawi drivers: TRAP C at load time. This looks bad.
I take a look into the FAQs on
Dawicontrol's web pages... nope. There's nothing about OS/2. I search for the e-mail-address
of technical support... none. What - no mail, just phone?
This makes me prepare for the unpredictable and expecting the worst. But - hey
- what's that? No service prefix of 0190 nor 0180-5 - just a 'usual' phone number.
Phew.
(These prefixes in Germany indicate
special service offerings which might cost you up to two Marks per minute or even
more...)
So I pick up the phone, call them,
and start to complain immediately. In details. The lady who patiently listened to
all this stuff apologizes and tells me that she is "only" the operator
and that I'll be passed to a support desk now. Oops. Quite quickly after that, there's
a Sir asking what he can do for me. Having refined my speech, it takes me only a
fraction of that amount of time to tell him the whole story. He feels sorry about
their OS/2 specialist currently being out to lunch (that's right, it's about noon)
but promises to take care of my problem. As an OS/2 user I secretly prepare to be
abandoned for the next decades and that there'll be certainly no calls from Göttingen
ever... saying "fine - see you." and hanging up.
Some hours later, there's the
phone ringing. That from Dawicontrol is back. Incredible. He tells me that there
are some problems with that new kernel from Aurora (WSeB), that's being implemented
within FP14. (Well, anyone disagree out there...?). The developers who are only
a few people can't take care of that for the moment, because they all had to team
up for the release of a U160+-controller and it's drivers.
But as I checked it up in the meanwhile it's a Symbios chip they used on their
board, so I ask him whether to use Symbios (LSI Logic) drivers and if that might
solve the problem. He agrees, telling me that it's a good idea 'cause those Symbios
drivers can be used in general, but he can't tell if the problem will be solved
with that.
To sum up the whole story: Yep,
it works. Symbios drivers for SYM53C875 makes FixPak 14 function perfectly.
Actually this would have been the end of my review,
but as I am curious, I absolutely wanted to know if there were any differences between
Dawicontrol's drivers and those from Symbios and what kind of differences that would
be.
"Test driven"
Up to the WseB-kernel both the
Symbios drivers run on the DC-2976UW, as well as those from Dawicontrol. I decide
to compare via Sysbench (V 0.9.3).
No matter what test I did, there
are only minor differences between the competitors. Sometimes there appear to be
minor advantages for Symbios drivers in matters of hard disk access, sometimes it's
Dawicontrol's drivers who seem to have the advantage in matters of CD-ROM-access.
From a general point of view those differences are so minor, that it's due to the
way of benchmarking that they exist. This makes it even more interesting to take
a close look at the functional differences, as for example: Symbios drivers, FixPak
12 and Device Driver Fixpak 2.
Strange thing. Everything went well up to this point, now the system already
has trouble coming up: There's SCSI bus resetting and scanning for devices all the
way, coming in sequence again and again. The boot process takes almost three minutes.
Finally the WPS is up. I try to access the CD-ROM drive and there we are: Again:
reset, scan, reset, scan... what the heck is he doing?
Having almost lost my patience, I'll try to watch
for it after rebooting with
Well, buddy - here I am back: Everything's fine now
again. (In the meantime, I was told that OS2CDROM.DMD that comes with Device Driver
Fixpak 2 appears to have problems with various CD-ROM-drives.)
Result of the driver tests:
Up to the Aurora kernel, the drivers
from Dawicontrol are preferable because of their flawless work regarding all versions
of OS2CDROM.DMD. From Aurora (WSeB-) kernel onwards, there's no way out of
the need for Symbios drivers (at least for the moment).
This might cause you troubles with OS2CDROM.DMD
according to the FixPak level applied, but it's worth it anyway, for those problems
can easily be circumvented by using JJSCDROM.DMD (freeware). It's mandatory
for me anyway, as I can't do DAE out of the box with my Teac CD-532S under OS/2,
as I already said above.
I have to admit that this test lacks a view on CD-writer and scanners, as I did not attach them to my PC. The scanner stuff is a subject to be discussed separately, as these kind of devices require special attention (especially when used with OS/2). Regarding CD-writers, I am sorry to only have checked CD-ROM-functions under OS/2. I discovered, that there are quite a few people out there having troubles using the Dawicontrol drivers - especially when dealing with CD writers and scanners. I can't tell if this is due (maybe in part) to the devices themselves or even the hosting PC itself. All I can say, is that these troubles seem to be circumvented by the use of Symbios drivers.
As a nice side-effect of their drivers, a presence
checker for the SYM53C875 chipset is delivered with them - I already mentioned that
subject, didn't I? By editing SCSI.TBL appropriately, specifying SYM8XXPC.EXE,
the controller will be recognized and preselected automatically by the OS/2 install
program.
In addition, the Symbios drivers provide extended
device information when being loaded compared to their Dawi counterparts: It's the
firmware version of each attached device. This turned out to be quite useful for
me, as it gave me the chance to comfortably verify for firmware updates at Teac,
enabling my CD-R56S writer to cope with that CD-Text feature. Okay, I might not
absolutely depend on that one, as I don't have (nor know anyone who has) a CD player
with CD-Text, but who cares? Ain't it nice to show off with that?...;)
Finally I would like to take the occasion to promise
to do an additional review on "drivers in matter of scanning and CD-writing".
My e-mail address is contained in this article's heading. So, if you can contribute
to these subjects in matters of DC-2976UW (and OS/2 !), don't hesitate to give me
your hints, trouble reports or any other kind of information. If you have any comments
or questions regarding this review, you're welcome to do so as well.
Conclusion:
The Dawicontrol DC-2976UW offers good performance
and quality at a very affordable price.
(Approx. 100 Euro / 97 US$ which equals to 1/3 of the cost of a comparable Adaptec
model around here - I did not find information on pricing and distribution outside
Germany, sorry.)
Thomas Klein is IT consultant at Systor
GmbH & Co. KG and is currently involved in software quality control in a
large-scale project at IBM. He's been using OS/2 since version 2.11.