Fwd: Re: Adaptec or Tekram

Autor: Przemysław Pawełczyk (warpman_at_friko5.onet.pl)
Data: Mon 29 Jun 1998 - 10:23:39 MET DST


Hi,

Szukałem i znalazłem. Rzecz tyczy SCSI i jego (jej?) meandrów. Myślę,
że dla OSmanów informacje z tego listu będą więcej niż przydatne.

Warpman

==================BEGIN FORWARDED MESSAGE==================
>Date: Mon, 29 Jun 1998 05:01:42 +0200
>Reply-To: IBM OS/2 Unedited Discussion List <OS2-L_at_NIC.SURFNET.NL>
>Sender: IBM OS/2 Unedited Discussion List <OS2-L_at_NIC.SURFNET.NL>
>From: ethical_at_IBM.NET
>Subject: Re: Adaptec or Tekram
>To: OS2-L_at_NIC.SURFNET.NL
>In-Reply-To: <199806271314.PAA27369_at_friko5.onet.pl>
>X-UIDL: 3935b876ebd966c531ef1d11731cb557
>

In <199806271314.PAA27369_at_friko5.onet.pl>, on 06/27/98 at 02:19 PM,
   Przemys aw Pawe czyk <warpman_at_FRIKO5.ONET.PL> said:

> Hi,

> Several days ago I asked some questions about Adaptec SCSI and
> Tekram SCSI cards. I have asked answering during ASUS SCSI header
> discussion. Perhaps my email warped to the other side of Mobius
> strip? ;-)

> I would like to get more information about differences between
> Adaptec and Symbios made SCSI cards. Why Tekram SCSI cards are
> better that Adaptec one's? Does it concern with threads in OS/2? If
> yes are Tekram cards also better in NT systems or Linux? Tekram
> DC-390 series is two to tree times cheaper than Adaptec's. What
> about other producers, do they make cards good for OS/2 too? Can
> Tekram cards work in overclocked systems like Adaptec's with 83 or
> even 100 MHz bus?

Your questions were based on a statement I made here some days ago.

Here are some URLs you may wish to explore:

http://www.europa.com/~diogenes/DSMFDSM/#CAMT

Read, mark, learn, and inwardly digest it.

There is also an excellent SCSI FAQ at

http://www.lionsgate.com/Home/Baden/public_html_index/SCSI/SCSIgame.txt

The remainder of this message (except for my sig) is a direct
quotation from the latter:

        SCSI - A Game With Many Rules and no Rulebook? Version 1.2
                Copyright Gary Field, 1994-1997 - All rights reserved.
        Special Internet edition - Freely distributable for
non-commercial
use. Author: Gary Field (gfield_at_grcelect.ultranet.com) - SCSI hacker
since 1985
        With a little help from my friends.

    <snip>

A little history of the game:

Whereas the SCSI hardware game has strict rules, the SCSI drivers game
has been pretty much a free-for-all. Once, there was total chaos in
the land of SCSI. Each vendor provided driver software for the
specific devices it decided to support. If a player later decided he
wanted to attach a device that was not deemed valuable by their chosen
vendor, tough! And to make sure that a player would not write his own
drivers, these vendors would not provide interface spec's for their
host adapters. All vendors supported hard disks, but attaching tapes,
or CDROMs was not for the faint of heart.

One wise vendor called Adaptec eventually heard the wailing cries of
its customers and decreed that henceforth SCSI drivers would talk to
their host adapters via a protocol to be known as ASPI (Adaptec SCSI
Programming Interface). Since ASPI was deemed by many to be too simple
for serious players, the ANSI committee came to the rescue with their
CAM (Common Access Method). (Unfortunately, they were a little slow in
arriving and most players had already learned to live with ASPI).

These driver interface definitions changed the SCSI software game
forever! Modern players in SCSI software are frequently heard
reverently speaking these acronyms. The ASPI definition covers MSDOS,
Windows, Win32 (95 and NT), OS/2, and Netware. CAM covers Unix in
addition to these.

Still, selection of one of these standards is something of a religious
act of faith. NCR (Now Symbios Logic) wisely chose to support both by
implementing CAM as their native interface and creating an ASPI
interface that goes down through CAM to the adapter. (CAM cannot be
implemented on top of ASPI since CAM is a super-set of ASPI.)

These days, in the MSDOS/Windows world, selection of SCSI software is
pretty much a matter of choosing ASPI or CAM and remaining true to
your selection. In the Unix world, make sure your Unix vendor supports
the devices you need or be prepared to write a driver yourself (lots
of fun for the whole family)! It is rather disappointing that out of
all the major Unix vendors, only DEC chose to implement CAM as their
SCSI environment. Even the Linux developers did their own thing.
(Particularly sad since CAM was available when Linux was being
developed).

        <snip>

End of quotation from Gary Fields.

If you are willing to accept the word of authors of articles in
Ziff-Davis publications, and if you are willing to accept that
articles written in 1993 may still have something to tell us, here is
a quotation for you:

        CAM permits several devices to multitask, or work
        simultaneously on a single SCSI bus, which ASPI cannot do.
        Since Windows [3.x] depends heavily on DOS access to devices,
        ASPI is currently more important to Windows 3.1 users. But
        as true multitasking operating systems, like Windows NT and
        OS/2, grow in popularity, expect to see either a shift from
        ASPI to CAM or more CAM-like capabilities added to ASPI.

                -Ben Myers. Copyright (c) 1993 Ziff-Davis Pub. Co.

[Ben Myers helped develop ZD Labs Windows benchmark tests and runs a
Massachusetts-based consulting firm, Spirit of Performance.
Incidentally, the quotation above came from a published ZD Labs test
report in the August 1993 issue of "Windows Sources" magazine, in
which test a 16-bit ISA bus controller, the Future Domain TMC-1680
with CAM firmware outperformed, sometimes by a significant margin, the
best ASPI-based controller (the Bus Logic BT-445S) on the 32-
bit-wide VESA Local Bus and the 32-bit-wide Adaptec 1742A EISA bus
controller.]

If you have access to a library with back issues of PC Magazine, you
will find an excellent aticle, one which also discusses the diferences
 between ASPI and CAM, in volume 12, no. 12, June 29, 1993, at pages
219-240.

--
-----------------------------------------------------------
ethical_at_ibm.net (T. Guilbert) sending e-mail to you from lovely
Portland, OR, USofA
-----------------------------------------------------------
===================END FORWARDED MESSAGE===================
=========================================== OS/2 WARP 4ever
Przemysław Pawełczyk  (Warpman)                         Niezależny dziennikarz
Mailto: warpman_at_friko5.onet.pl     WWW: http://friko5.onet.pl/kr/warpman/
Tel./faks: +48 12 642-13-00,                31-926 Kraków, os. Centrum B 1/89
===========================================================


To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:17:30 MET DST