(Where you see reference to [Editor(GF)] that means me.)
Last updated: September 18, 2001
Note: Please allow the whole
file to load before clicking on any links. If you click on a link before
the portion of the page it points to has loaded, you just get sent to the
top of the document.
What is the SCSI FAQ: The SCSI FAQ is a living document that attempts to serve as a reference
for people who are trying to learn about SCSI
and/or troubleshooting a SCSI system. I don't look at the FAQ as a
standards document. There are many topics for which I could simply regurgitate
the SCSI standards documents, but instead, I generally choose to describe
a useful, "practical" answer instead of an obtuse, detailed, answer which
would only further confuse a newcomer to SCSI. I feel more people are served
by this method. I will NEVER knowingly include wrong information in the
interest of simplicity however. Believe me, when I put something in
that's incorrect (it has happened on rare occasions), I get plenty of email
pointing out the error to me. Sometimes my opinion even plays into an answer
(Oh well, you get what you pay for).
Occasionally, something I have written strikes controversy, usually
either due to a gray area in one of the standards or due to a misintrepretation
of what I wrote or included. When I get notified of the disagreement, I
research the topic, listen to reasonable arguments, and make the corrections
or not as I see fit.
Articles get into the FAQ in several ways:
1) I see a question appear a number of times and write an
answer for that topic and put it in.
2) Someone else writes up an answer for a question they feel
needs answering and sends it to me. I edit it for accuracy
if necessary,
correct the grammar/spelling somewhat, edit the text into a consistent
format, and put it in.
3) I see what I feel is a well written response to a question
posted in comp.periphs.scsi and ask the author if I can include it.
Submitting articles for the FAQ:
If you feel the urge to write up an article for the SCSI FAQ that you
feel qualified to answer, please format it the way the existing articles
are and send it to me, (preferrably in HTML format, but .txt or .doc is
OK too).
FAQ history: Created by Johnathan Vail (vail@prepress.pps.com)
from articles submitted to him by comp.periph.scsi readers.
Maintained by Johnathan Vail until November 1993.
Maintained by Gary Field from November 1993 to the present.
About the editor: My credentials in SCSI technology are pretty substantial. I've been
working with this stuff on a daily basis, continuously since 1985 on both
PCs and various UNIX platforms. I write and enhance SCSI device drivers
for a living. All of my own computers use all SCSI I/O.
I also wrote/re-wrote "The Book of SCSI: I/O
for the New Millennium", and wrote the UNIX chapter in Brian Sawert's
book "The Programmer's Guide to SCSI".
There are areas of SCSI which I am not expert on, and when a question
of fact comes up in one of those areas, I research the issue using the
SCSI standards documents, or, ask my colleagues who are expert in that
area, about it.
In general I get nothing but compliments about the FAQ. The most common
complaint is that it's not always up to date on certain topics. I try my
best to keep it updated, but SCSI marches on...
"Who pays for the "SCSI Info Central" Web site where the FAQ is distributed
from"? you ask.
is my own personal web site that I've registered as scsifaq.org, connected
to the Internet via AT&T(formerly MediaOne) cable modem. I spend a
considerable amount of my own time and money maintaining the site, and
I hope people benefit from it.
Acknowledgements Thanks to David Sanderson and Roland Bauer for helping me improve the
quality and compatibility of the HTML in this document. I would also like
to thank the denizens of comp.periphs.scsi for their stimulating banter
which triggered the writing of many of the articles in the FAQ.
The Eternal Question Should I buy SCSI or just go with EIDE/ATA?
This has to be the most commonly asked question regarding SCSI!
I hope this will summarize my thoughts on that issue:
For someone to who doesn't need a real multi-tasking workstation or
server, the only reason for paying the extra money for SCSI is flexibility.
EIDE/ATA is strictly for "inside the case" peripherals. SCSI allows you
to attach a large collection of add-ons like scanners, CD recorders, tape
drives (or even devices not conceived of yet), either inside or outside
the CPU case in whatever manner suits your needs or wishes.
If you like non-technical analogies:
SCSI is like a palace, with an architecture that was well thought out
from the beginning and built upon over a period of time to make it even
greater than originally envisioned.
IDE/ATA is like a log cabin, with a dirt floor, built from whatever
was found lying around in late Fall just before the snow came. It can't
be expanded because it has no foundation and would collapse under its own
weight.
Both provide shelter. SCSI costs more (but not as much as a palace :-)).
Take your pick.
If automobile analogies are more to your liking:
A Ford Escort will get you to work just as fast as a Volvo station wagon.
Which would you rather go on vacation in? Which would you rather be in
if an accident occurs?
If your computer is nothing more than a machine that's only purpose
is to perform a certain set of tasks, and you don't expect to want any
more out of it, IDE is probably for you.
On the other hand, if you enjoy computing and are always looking for
more things your computer can do for you, SCSI will help enhance the experience
for you. You won't regret the investment.
Just as with a palace however, you need to learn your way around. That's
where this FAQ comes in!
If you just can't get enough SCSI, you might also want
to look at: SCSI
Info Central where you will also find The
SCSI Game Rules
Attention SCSI vendors: There are a few articles in this FAQ
where vendor contact information, and in a few cases, part numbers, are
listed. This is not an attempt to steer business to any particular vendor
but only to provide possible sources of certain "hard to find" SCSI accessories
(particularly special cables, adapters and terminators). If you want to
be listed in one or more articles please send your contact info and which
items you can provide to the FAQ editor.
I will not include pointers for devices like hard disks, tapes, CDROMs
etc., which I consider readily available.
SCSI stands for Small Computer System Interface. It's a standard for
connecting peripherals to your computer via a standard hardware interface,
which uses standard SCSI commands. The SCSI standard can be divided into
SCSI (SCSI1) and SCSI2 (SCSI wide and SCSI wide and fast) and now SCSI-3
which is made up of at least 14 separate standards documents.
SCSI2 is the most popular version of the SCSI command specification
and allows for scanners, hard disk drives, CD-ROM players, tapes [and many
other devices]. SCSI-3 resolves many long time "gray areas" and adds much
new functionality and performance improvements. It also adds new types
of SCSI busses like fibre channel which uses a 4 pin copper connection
or a pair of glass fibre optic cables instead of the familiar ribbon cable
connection.
In order to put together a PC with SCSI I/O you'll need:
A SCSI host adapter (also called a SCSI controller by sales types)
A SCSI cable (either WIDE, 68 pin, or narrow, 50 pin, external or internal)
A SCSI device of some sort (disk, tape, CD-ROM, CD-RW, DVD-ROM, scanner)
The SCSI device will most likely have a built in terminator that can be
enabled or disabled. If it doesn't you'll also need a terminator (active
terminator perferably). You'll find that there is quite a variety of SCSI
cables out there. This is due to the fact that SCSI is so flexible. You
are not limited to one SCSI device of course, that's just a minimum.
In order for most SCSI problems to be resolved, one needs to provide
at least the following:
Type of system (PC, SPARC or Alpha Workstation, etc.)
If PC, what type of motherboard?
Operating System (DOS, Windows 3.x, Win 95/98, Win NT 4/5, Linux, other
UNIX)
Specific SCSI host adapter (Symbios xxxx, Adaptec xxxx, etc)
List of attached devices (and for disks, whether they're WIDE or NARROW)
Which connectors on the host adapter the cables are connected to
Length of SCSI bus
Where the terminators are located (90% of all SCSI problems result from
mis-placed terminators).
Whether the configuration is new, or was working before.
It may seem like a lot of information to provide, but unless you have some
SCSI experience, you may not realize how many factors can affect whether
the system works properly or not.
If you don't know what some of these things mean, read the rest of this
document until you do. You'll get much more help if you appear to have
made an effort to find the answer on your own before asking for help.
Asking a question like "My scanner doesn't work, how come?" may not
even get you a response.
PLEASE DO NOT ASK "Which is better IDE or SCSI"?
Please spare us all the aggravation of the week long tirade that will
result from asking this seemingly innocent question!
Also called a Host Bus Adapter or HBA. The card that connects your computer
to the SCSI-bus. Usually called SCSI-controller by marketing droids. An
example would be a PCI SCSI host adapter like the Adaptec 2940UW.
Terminators (passive)
A group of resistors on the physical ends of a single ended SCSI-bus (and
only on these ends) that dampens reflected signals from the ends of the
bus. Each terminated signal is connected by:
220 Ohm to +5 volt (TERMPWR)
330 Ohm to ground.
For NARROW SCSI the 18 signals that are terminated are:
For WIDE SCSI there are 9 more signals; DB(p1), DB(8) ... DB(15)
Terminators (active)
Rather than passive terminators that use TERMPWR which may not be exactly
+5v, active terminators use a voltage regulator. Basically it is a set
of 110 Ohm resistors from each signal to a 2.8 Volt regulated Voltage source.
Single ended
"Normal" electrical signals. Uses open collector drivers to drive the SCSI
bus.
[usually] survives wrong cable insertion.
DIFFSENSE signal is used to detect connection of differential devices and
prevent damage.
The max. length for SCSI-1 is a 6 meter cable with stubs of max 10cm allowed
to connect a device to the main cable. Most devices are single ended.
Differential (Now called High Voltage Differential to distinguish it
from LVD)
Uses two wires to drive one signal.
Max. cable length of 25 meters.
Electrically incompatible with single ended devices!
Much more expensive than single ended.
Used from SCSI-1 upwards.
Apple kludge
The single ended 50 pins cable has been reduced to 25 pins by tying most
grounds together. DB25 connector (like a parallel port). Often used as
the external SCSI connector. Unfortunately, this abomination is being perpetuated
by being used on devices like the Zip drive!
Asynchronous SCSI:
A way of sending data over the SCSI-bus.
The initiator sends a command or data over the bus and then waits until
it receives a reply (e.g. an ACKnowledge). All commands are sent asynchronously
over the 8 bit part of the SCSI-bus.
Synchronous SCSI
Rather than waiting for an ACK, devices that both support synchronous SCSI
can send multiple bytes over the bus in the following way:
This improves throughput, especially if you use long cables. (The time
that a signal travels from one end of the cable to the other end of the
cable IS relevant.)
Fast SCSI
Fast SCSI allows faster timing on the bus. ( 10MHz instead of 5MHz )
On a 8 bit SCSI-bus this increases the *theoretical* maximum speed from
5MB/s to 10MB/s.
Ultra SCSI
Synchronous data transfer option which allows up to 20MHz data clocking
on the bus. Also called FAST20.
Ultra2 SCSI
Synchronous data transfer option which allows up to 40MHz data clocking
on the bus. Also called FAST40.
Use of this option also requires the use of LVD
bus drivers.
Ultra3 SCSI
Synchronous data transfer option which allows up to 80MHz data clocking
on the bus. Also called Ultra160. Use of this option also requires the
use of LVD bus drivers.
Wide SCSI
Uses an extra cable (or more commonly a 68 pin P cable) to send the data
16 or 32 bits wide. This allows for double or quadruple speed over the
SCSI-bus.
RAID [Added by Editor(GF) Corrected by Fredrik Bjork (ace@varberg.se)]
A Redundant Array of Independent Disks is a set of disk drives connected
in such a way as to allow certain types of access optimization, or data
security. This can be accomplished in hardware using a special dual ported
SCSI adapter, or completely in software in a special device driver.
A RAID 0 array stripes the data across multiple drives to decrease data
latency. A RAID 1 array mirrors the data on multiple drives for increased
data integrity. A RAID 5 array uses extra drives in a distributed manner
to store parity information that can be used to apply data correction and
recover any data in the event of any individual disk failure. This provides
high reliability.
The following was submitted by RAIDER@ultrafast.net:
The minimum number of drives required for each RAID level is:
This feature of the SCSI protocol allows a device to temporarily give up
control of the SCSI bus. This is typically done when the device is performing
an operation which will take some time. For example, it is very important
for tape drives which would otherwise lock out other devices during long
operations such as rewind.
Addition by: Editor GF (scsifaq@engineer.com)
Bus Segment
A portion of a SCSI bus isolated by a signal conditioner chip. A bus segment
is logically part of a single SCSI bus (e.g. SCSI IDs must be unique) but
electrically separated such that reflections on the segment do not affect
other segments. Using bus segments allows longer busses because the signals
get cleaned up (edges re-clocked etc) by going through the signal conditioner
chips. Each segment must have its own terminations; One at the signal conditioner
chip, and one at the far end of the segment.
Logical Unit Number (LUN)
A LUN is a sub-unit of a target. Most of the time, the LUN is just 0 since
most types of target devices don't have sub-units. One example of where
you might use LUNs is with multi-disc CDROM changers. Many of these units
refer to each disc in the changer as a LUN. e.g. with the CDROM drive set
as target ID 4, the first CD disc would be ID 4, LUN 0, the next would
be ID 4, LUN 1 and so forth.
Another example is a optical disk jukebox where the optical drive might
be LUN 0 and the changer might be LUN 1.
Some host adapters ignore LUNs unless the "Enable LUNs" option is set in
the host adapter BIOS or operating system driver config. They default to
not using LUNs because it speeds up the bus scan process and most targets
don't support LUNs anyway.
LUN numbers are generally defined by the manufacturer and can't be changed
by the user.
The Adaptec 2940 series BIOS has changed the place in the BIOS that LUN
support is controlled several times.
A sketchy history:
AHA-2940U BIOS ver 1.11 = No LUN support
AHA-2940UW BIOS ver 1.25 = Under Advanced Config, "Multiple LUN support
(enable/disable)"
ASUS P2B-LS* Adaptec AIC-7890 BIOS = Under SCSI device config, "Support
Multiple LUNs (on/off)" on a per device basis.
* Note: The built-in SCSI adapter on this motherboard is quite similar
to the Adaptec 2940U2W.
The disk drive manufacturer Shugart begin working on a new drive interface
with logical rather than physical adressing. It used 6 byte commands.
Shugart Associates Systems Interface (20 pages long) made public.
A few SASI drives are developed
1980
Attempt to make SASI an ANSI standard failed.
1981
Shugart and NCR request an ANSI committee be formed for SASI.
1982
ANSI committee X3T9.2 is formed.
SCSI adds the ATN signal to the bus and creates the message protocol.
1983
Development of SCSI drives and ST-506 to SCSI bridges begins.
1985
CCS (Common Command Set) used in most disk drives.
Only disk and tape commands were adequately specified.
1986
Work begins on SCSI-2.
SCSI-1 becomes official as ANSI X3.131-1986 (yes, after the work had begun
on SCSI-2)
6 and 10 byte commands.
SCSI-2 specifies CDROM commands.
1988
Production of SCSI-2 devices begins.
1993
Work begins on SCSI-3.
1994
SCSI-2 becomes official as X3.131-1994.
SCSI-2 is backward compatible with SCSI-1 and adds the following:
Fast SCSI-2. Optional bus speed of 10MHz instead of 5MHz.
Wide Optional 16 or 32 bit cable instead of 8 bits.
more commands defined, many optional (I'm not going to type the entire
list here)
broader support for non-disk devices (tape.CDROM,Scanners....)
SCSI-2 devices can talk to the host adapter on their own inititive. (e.g.
to set in which mode they should operate, FAST or not, wide, extra wide
or normal ...) This can confuse some older SCSI-1 HA.
1995
Production of drives that have some SCSI-3 enhancements.
Ultra SCSI: Bus speed of 20MHz?
1996
SCSI-3 proposals include:
Support for graphical commands.
Fibre channel protocol (fibre channel) (FCP)
Serial packet protocol (IEEE 1394) (SBP)
SCSI-3 general packet protocol (almost all serial interfaces) and of course
the old SCSI-2 commands and more.
Low Voltage Differential Parallel interface (SPI-2)
CD-R command set and algorithms (MMC)
1998
Ultra2: Bus Speed of 40 MHz. LVD only.
1999
Ultra3: Bus Speed of 80 MHz. LVD only.
Future (after 1998):
SCSI-3 becomes official
SCSI becomes a more network-like environment where devices can be physically
distributed and shared more easily.
Table of Contents
QUESTION: Can
I access SASI drive with SCSI controller?
Well, the answer is a definite maybe, but very unlikely. Old low performance
SCSI adapters and drivers that use only a minimal subset of the SCSI commands
may work with SASI devices that happen to support the INQUIRY command.
Newer adapters and drivers expect to be able to use messages and will get
very upset with a SASI device that doesn't understand them.
In reality, there is no practical reason to do this. Any SASI device
is so obsolete that is has no real value in a system being used in 1990
or later.
QUESTION:How should
I lay out my SCSI bus? What should I avoid? QUESTION: Where do I put the terminators? QUESTION: Where should the adapter card be
placed?
Answers From: Nick Kralevich <nickkral@cory.eecs.berkeley.edu>
One confusing thing about SCSI is what the SCSI bus is supposed to
look like, and how devices should be placed on the bus.
The SCSI bus MUST run continuously from one device to another, like
this:
DEVICE A --------- DEVICE B --------- DEVICE C -------- DEVICE D
Where device A, B, C, and D can either be internal or external devices.
The devices on the SCSI bus should have at least 4 to 6 inches of cable
between devices. This is to satisfy the SCSI-2 requirement that "stubs"
be placed at least .1 meters apart. Some devices that have a lot of internal
wiring between the connector and the SCSI chip can look like a "stub" or
bus discontinuity. The reason for all these requirements is that a SCSI
bus is really 18 "transmission lines" in the wave theory sense. A pulse
propagating along it will "reflect" from any part of the transmission line
that is different from the rest of it. These reflections add and subtract
in odd combinations and cause the original pulse to be distorted and corrupted.
The terminators "absorb" the energy from the pulses and prevent reflections
from the ends of the bus. They do this because they (hopefully) have the
same impedance as the rest of the transmission line.
The SCSI bus must not have any "Y" shape cabling. For example, setting
up a cable that looks like this is NOT allowed:
DEVICE B
\
\
\
>------------- DEVICE C ----------- DEVICE D
/
/
/
DEVICE A
Where do I put the terminators?
Termination must be present at two and ONLY two positions on the SCSI
bus, at the beginning of the SCSI bus, and at the end of the SCSI bus.
There MUST be no more than two, and no less than two, terminators on the
bus.
Termination must occur within 4 inches (.1 meter) of the ends of the
SCSI bus.
The following ARE acceptable:
+------------+----------+-----------+-----------+---------+
| | | | | |
DEVICE A Unconnected Unconnected DEVICE B DEVICE C Adapter
Terminated Terminated
+------------+----------+-----------+-----------+---------+
| | | | | |
DEVICE A Unconnected DEVICE B Unconnected Adapter DEVICE C
Terminated Terminated
+------------+----------+-----------+-----------+---------+
| | | | | |
Adapter DEVICE A DEVICE B Unconnected Unconnected DEVICE C
Terminated Terminated
+------------+----------+-----------+-----------+---------+
| | | | | |
Adapter DEVICE A DEVICE B Unconnected Unconnected Termination
Terminated
The following ARE NOT allowed:
+------------+----------+-----------+-------------------+
| | | | |
DEVICE A DEVICE B Adapter Unconnected Unconnected Dangling cable end
Terminated Terminated
+------------+----------+-----------+-----------+
| | | | |
Termination DEVICE A DEVICE B DEVICE C Adapter Termination in middle of bus
Terminated
[Editor GF]
Helpful hint:
I have found that it is much better in the long run to always disable the
internal terminators in all of your devices and place a terminator block
at the end of the cable itself. I'll grant you that this costs a little
more because you need to buy a separate terminator. But, you never need
to be concerned in the future when you re-arrange devices in your system,
which device had its terminator enabled (none of them do). With the arrival
of LVD and SCA, devices are starting to be shipped which don't even have
internal terminators anyway, so getting used to the idea of terminating
the cable end and not the device is a good practice. This is just my two
cents worth... (backed by 15 years of tinkering with SCSI...).
Old wive's tale:
I still hear people say "If you put a terminator part way down your SCSI
bus, the devices beyond it won't be seen". This is a total misconception
of what terminators do. Putting a termination part way down the bus is
incorrect and does cause problems, but it is quite unpredictable what the
effect will be. It's not simply a matter of making the devices beyond the
terminator invisible to the host adapter. Many people believe this myth
and it will probably never go away, but I hope to convince at least a few
people that this is not a valid way to envision how termination works.
Where Should I place the SCSI host adapter
on the SCSI bus?
The placement of the SCSI adapter card can be on the end, at the beginning,
or somewhere in the middle of the SCSI bus.
Quite frankly, placement of the controller card isn't special.
The adapter card is just another device on the SCSI bus.
As long as the rules above and in other sections of this FAQ are followed,
there should be no problem placing the adapter card anywhere on the SCSI
bus.
However, if you place the adapter card somewhere in the middle of the
SCSI bus, you must be sure to disable termination on the adapter card.
As noted previously, a SCSI device is only allowed to have termination
if it's at the end of the bus. Only two terminators are allowed to terminate
the SCSI bus, one at each end.
One last note: It doesn't make any difference where each SCSI ID is
placed along the bus. It only matters that no two devices have the same
ID. Don't forget that the adapter has an ID too. (Usually ID 7).
A SCSI bus is a transmission line. To prevent reflections from the ends
of the bus, you need a device which makes the transmission line appear
to be of infinite length. This is done by attaching resistors, which have
the same resistance as the characteristic impedance of the transmission
line, to the ends of the bus. Also, since SCSI line drivers are open-collector
(which can only pull a signal low), a pull-up resistor is needed to pull
the signal high when it's not asserted.
If the ends of the bus are not terminated, the signal pulses will reflect
off these open ends and travel back along the bus in the other direction.
The resultant adding and cancelling of signal amplitudes distorts and corrupts
the SCSI signals.
There are two basic types of terminators, active and passive:
Passive terminators consist of pairs of resistors. A 220 Ohm pulling each
signal up to TERMPWR and a 330 Ohm pulling each signal down to GROUND.
Passive terminators were considered adequate in SCSI-1 when the bus only
ran at 5 MHz. In SCSI-2, passive terminators were given the name "Alternative
1".
Active terminators consist of 110 Ohm resistors connected from each signal
line to a common 2.85 Volt regulated power supply. Active terminators both
terminate the bus better (less reflection), and supply cleaner pull-up
current (due to their Voltage regulation). They were first defined
in SCSI-2 and were given the name "Alternative 2" to distinguish them from
passive terminators.
Recommendations and requirements:
In SCSI-2 when the fastest defined speed was 10 MHz, passive terminators
were allowed, but active terminators were recommended.
In SCSI-3, the "alternative X" terminology has been discarded, and
the SPI-2 standard only allows active termination for single-ended buses
regardless of speed.
My personal recommendation is not to buy any new passive terminators.
If you want to use up the old ones you have lying around, on older systems,
with short buses and no more than 4 devices, that don't have any devices
faster than 10 MHz, I can't argue with that, but ONLY BUY ACTIVE (or preferrably
LVD) terminators for any new systems. If you run into problems, switching
to an active terminator might well solve them.
Other people will tell you that only active terminators are ever acceptable
at any speed. I leave the choice up to the individual at Fast10 and below,
above that, active is absolutely the only acceptable choice.
I often hear the whine "It seems to be working, why should I bother
with the terminators?"
The following appropriate analogy was given to me by Kevin Kilzer:
"It only seems to work fine because you have not seen an error.
It's like having mice in your house. If you never see one,
you don't realize they are there."
Suddenly a problem will arise and you won't even realize it's associated
with the fact that you added a device to your SCSI bus two weeks ago. Termination
problems can manifest themselves in many ways. The best solution is to
avoid them by following the rules to the letter.
A final nit to pick:
As I was reminded in looking back at the standards, technically SCSI-2
did not sanction Fast10 on single ended buses. It was only spec'd for differential.
However, as was the case with WIDE SCSI using the 68 pin P cable, the industry
latched onto it and it later became standardized in SCSI-3 SPI.
QUESTION: What
is terminator power (TERMPWR)? Why do I need it? Where does it come from?
ANSWER From: Roger J. Hamlett (Roger@ttelmah.demon.co.uk) Updated: November, 1999
TERMPWR is the power source for the SCSI terminators. Terminators (both
active and passive) require power because in addition to providing the
correct impedance to prevent reflections on the SCSI bus, they source pull-up
current to the SCSI signals.
The SCSI spec. allows for multiple devices to supply power, but also
limits the maximum current that should be available. The "rule" is that
"initiators shall supply TERMPWR". Hence a SCSI controller (host adapter)
should supply TERMPWR, and on longer buses it is worth having a device
near the end to also supply it. However, no more than about four devices
should supply it, because in the event of a failure (shorted cable etc),
there could be dangerous currents available. Not all devices are
designed to be able to supply TERMPWR, but many can. Usually this is done
by setting one or two jumpers to select where TERMPWR will go. For example:
TERMPWR to on drive terminator only
TERMPWR to SCSI bus
On drive terminator gets its TERMPWR from SCSI bus
Addition by: [EditorGF] Even though the spec. says that host adapters should
supply TERMPWR, PCMCIA type host adapters do NOT do it. This is because
PCMCIA cards are generally plugged into laptop computers that run on batteries
and can't afford the extra current drain. Another reason is because the
contacts in a PCMCIA connector are so tiny that the 1 Amp TERMPWR current
load is beyond their ratings. This being the case, at least one of the
devices that you wish to attach to a PCMCIA host adapter needs to be able
to supply TERMPWR, or you must provide a special terminator that has a
power connection for this purpose.
The ANSI SCSI spec's say that "stubs" on a SCSI bus must not be any
more than .1 meters (4 in.) long. In SCSI-2 there are also guidelines that
say you shouldn't place "stubs" any closer than .3 meters (12 in.) apart.
Since each device attached acts as a "stub", you really shouldn't place
connectors any closer than this. This gets to be more important as your
bus performance goes up. i.e. with Fast20 it is very important, but with
SCSI-1 it doesn't really matter much. Since Fast20 also limits your overall
bus length to 1.5 meters (for single ended) this also means you shouldn't
really connect more than 5 devices for best reliability.
Another minor enhancement involves altering the spacing of adjacent
connectors to prevent reflection resonance.
e.g. place connectors at one end, then .3m, then .56m then .86m then
1.12m
Overall, the cable impedance and configuration (straight vs. twisted
pair) are probably more significant factors than connector spacing. However,
if there is room for the extra cable, I recommend spacing the connectors
as described above for best reliability.
Excess cable length is also a bad thing, so basically all these factors
must traded off against each other to build the best SCSI cable for a given
situation.
I recommend no more than 1.5 meters. The SCSI-3
SPI spec. gives a much more complicated reommendation.
25 meters
12 meters
40 MHz (Ultra2 or Fast40)
Not recommended
12 meters
12 meters
80 MHz (Ultra160)
Not recommended
Not recommended
12 meters
These limits assume the use of good quality cable, and the use
of active terminators or LVD/SE terminators at each end of the bus.
Notice that I used the term MHz to specify speed since MB/sec. changes
with the bus width.
Note: Bus width doesn't change the maximum allowable length. The bus
width is independent of bus length or speed.
The above table assumes that you know the max. speed of your devices
(usually by looking in the manuals). Some software (like Adaptec EZ-SCSI)
provides a driver status monitor which will tell you what mode the devices
are actually in. This is important, since any synchronous speed must be
negotiated by either the device, or the adapter. The speed actually used
will be the least common denominator between the two.
For example, if a Fast20 disk is attached to a "SCSI2" host adapter
that only goes up to Fast10, the device will only run at 10 MHz.
In systems with high performance disks and external peripherals which
require long cables (i.e. external scanners, tapes or CDROM changers),
you may want to put the external devices on their own bus to avoid having
to slow down the fast disks. There are dual channel host adapters to make
this simpler (avoids using multiple IRQs etc).
The SCSI Trade Association also has a handy
table.
The main rule of SCSI IDs is that they all need to be unique on a per
bus basis. Each device on a particular bus must be set to a different ID
so that they can address each other without confusion. Some devices have
a sticker on the drive which shows the ID pins, but if your does not, you'll
need the data sheet for the device. The pins to jumper are obvious if you
know how to count in binary, if not there is usually a table of jumper
combinations on the data sheet for each ID setting.
There is a secondary consideration in setting IDs though; Higher ID
numbers have a higher priority on the bus.
The overall ID priority order on a WIDE bus is as follows (highest
to lowest): 7, 6, 5, 4, 3, 2, 1, 0, 15, 14, 13, 12, 11, 10, 9, 8.
There are at least two philosophies on how to use the device priorities
to best advantage:
Method 1:
Set the host adapter's ID to 7. The next lower IDs (6, 5, 4 ...) would
then be used for any time critical devices you may have such as streaming
tape drives or CD-RW drives. Your hard disks would be set to lower priority
IDs because they are generally the fastest devices on the bus and if given
too high a priority will hog all the bus bandwidth and "starve out" the
slower but time critical devices.
Method 2:
This philosophy maintains that devices that create the load should
be given low priorities and devices that relieve the load should be given
higher priorities. In this view, the host adapter creates the load (I/O
to be done), therefore, set the host adapter's ID to 0(or even 15 if no
narrow devices will be attached). The time critical devices (streaming
tape and CD-RW) would then be assigned highest priorities. Everything else
(including disks) would be assigned IDs in between. The placement of the
load creator at low priority pretty much prevents the "starvation" scenario.
To my knowledge no benchmarks have been published that show one method
to be superior to the other. I would appreciate it if anyone would run
some good tests to prove what the best method is or point to existing published
results supporting one of these methods (or even another method).
Method 1 is apparently supported by Adaptec since they set all their
host adapters to ID 7 by default.
I personally doubt that it makes very much difference which method
you choose except on very heavily loaded systems where the drivers take
full advantage of tagged command queueing etc.
Special consideration for older host adapters: Many older host adapters make the assumption that the boot disk will
be at ID 0. Most newer ones however, allow the user to specify which ID
to boot from.
The ID switches in external SCSI cases are designed to be as flexible
as possible because there is no standard for how ID pins on SCSI devices
are to be layed out. This flexibility however means that the user has to
be creative!
Usually there are 4 wires coming from the switch (five if it's WIDE).
They are:
ID bit 0 (value of 1)
ID bit 1 (value of 2)
ID bit 2 (value of 4)
ID bit 3 (if WIDE) (value of 8)
Common ground
The ID pins are usually specified pretty clearly on the documentation that
came with the drive, but they rarely show which pins are grounds. To find
the common ground pins (without guessing) you need an Ohmeter. Find which
side of the pin pairs is connected to the drive chassis and to each other.
Connect the common ground lead from the switch to any one of these pins.
Inexpensive due to high volume of production and simplified firmwar development
and testing requirements.
Supported directly by system BIOS in most cases. (unless you want DMA support)
Less overhead per command
Cons of IDE/ATA:
Very limited device attachment (two drives (including CDROMs) per channel,
and two channels per system max.) (Recent versions of Linux (and I hear
Win NT) support four or more ATA adapters)
Single threaded (commands do not overlap even with a second drive)
CPU is tied up transferring all data (actually newer EIDE controllers can
do DMA as well if special drivers are loaded)
IDE/ATA and ATAPI evolved from the ancient ST-506 interface as one kludge
on top of another
Cannot handle scatter/gather operations well (important in good Virtual
Memory operating systems)
Maximum disk drive capacity of 128 GB
Pros of SCSI:
Flexible device attachment (up to 7 or 15 devices per SCSI bus) (inside
or outside of case)
Longer cable lengths allowed (up to 12 meters using LVD)
Support for almost any peripheral type (disks, tape, CDROM, optical, scanner
etc)
All commands can overlap with commands on other devices. Usually uses DMA
to transfer data (which frees CPU for other tasks)
Interface and protocol is carefully specified by ANSI.
Largest, highest performance devices are available in SCSI before IDE
Most adapters can do scatter/gather DMA which is a necessity in virtual
memory systems (Like Unix, NT, 2000) (Win 95/98 ?)
Max drive capacity of 2048 GB
Cons of SCSI:
Generally more expensive than IDE/ATA, due to more complex firmware and
extra testing required. (not to mention greater performance commanding
a higher price).
Slightly more complicated to install than IDE/ATA, due to termination requirements.
Seems scary to novice users because of amount of terminology and connector/protocol
options.
Some people point to the need to set IDs in SCSI as making it more
complicated, but it's really no more complicated than choosing master/slave
jumpers in IDE.
---------------
Now that I've said that, here's an article to show that there's more
than one opinion on this subject:
From: Ed Schernau <mithrandir@ids.net>
Subject: FYI: EIDE and DMA/Scatter-Gather
The Western Digital Caviar EIDE drive that came in what is now the file
server in our office came with a Win3.x 32 BDA driver which allowed the
user to select DMA type (B or F) and to implement scatter-gather.
Also, the Intel Triton chipset implements 2 EIDE controllers, and I
know that at least the 1 on the PCI bus supports bus-mastering, as well
as DMA. However, PIO transfers can be faster, the infamous Mode 4 can in
theory, do 16.6 MB/sec and I've heard of a Mode 5 which can do 22 MB/sec.
Which [PIO] is only a benefit in single-tasking systems like DOS or Win3.x.
Sounds like Intel is trying to make EIDE into SCSI, eh?
QUESTION:Should
I spend the extra money on SCSI or just get IDE?
ANSWER From: Andrew Korn (korn@eik.bme.hu)
For home users this is a difficult question to answer in general. It
totally depends on how you use your system, what operating systems are
installed, and whether you will add more I/O devices in the future.
For server systems in a corporate environment the only sensible answer
is to go with SCSI peripherals.
IDE has been improved a lot in the past few years, so in most cases
it will be an acceptable choice for home users. You should consider the
following
(we are mostly talking PC hardware from now on):
1. Your motherboard probably has an integrated EIDE controller capable
of supporting up to four devices. (Older motherboards may not have a dual-channel
IDE controller, in which case only two drives can be connected; even older
motherboards may not be equipped with an IDE controller at all.) If not,
an IDE controller for your system should cost less than $30, which is about
half
of what a decent SCSI host adapter (Symbios 53C810 based) would cost you.
On the other hand, some high-end motherboards come with integrated SCSI
host adapters.
2. EIDE is a single threaded architecture. This means that of the two
drives connected to an IDE channel, one will always be idle while the other
is executing a command. If you only want a hard disk and a CD-ROM drive,
you can install the CD-ROM on the secondary IDE channel (the hard disk
will probably be the primary 'master' drive); in this case, the aforementioned
limitation does not affect you. Also, if you only plan on using single-tasking
operating systems such as DOS, you needn't be concerned about this single-threadedness.
SCSI devices share the bus bandwidth efficiently by allowing one device
to transfer data while another is seeking or rewinding its media. This
will, however, only gain you performance if you use a proper multi-tasking
operating system (such as Linux/UNIX [Editor(GF): or Windows NT/2000]).
3. By default, IDE devices use PIO (Programmed I/O) to communicate with
the rest of the system. This has the drawback of consuming a lot of CPU
time. However, most newer EIDE controllers support bus-mastering and most
drives support DMA or even UDMA transfer modes. Using bus-master DMA decreases
CPU consumption to almost zero. (It may not be easy to activate the DMA
transfer mode under DOS, however.)
Early SCSI host adapters had much the same problem, but all newer ones
support DMA transfers.
4. If you plan to use only two drives (one per IDE channel), IDE will
probably be slightly faster and definitely less expensive than SCSI.
If you think you need more than two drives, plan to use a multi-tasking
environment (such as Unix, OS/2, Netware or Windows 95/98/NT/2000), and
think that performance is more important than cost, SCSI is the way to
go.
Anything bigger than a small low-cost Linux-based server should probably
use SCSI.
5. IDE tapes are not as cool as SCSI tapes. They tend to be slower,
less reliable and less compatible with each other than SCSI tape drives.
SCSI tapes are more expensive, however.
6. IDE is probably slightly easier to install. Termination is not an
issue, and it will probably require no effort on your part to make the
system aware of any new devices you add. In some increasingly rare cases
this may not be true for SCSI. (You know what SCSI stands for? "System
Can't See It." :))
Especially with older systems it may not be trivial (or, in rare cases,
even possible) to make the computer boot from a SCSI drive.
7. It is problematic to add more than four IDE drives to a system. If
you think you will need more than that, SCSI is probably the choice for
you.
If your motherboard came with an integrated EIDE controller, however,
there is no need to ignore that feature; you can have a mixed system with
both IDE and SCSI devices. (Remember to buy SCSI where performance and
parallelism is an issue; but there is no need to buy an expensive SCSI
CD-ROM drive if an IDE drive would suit your needs.)
8. If you need high reliability, you want to buy a RAID
capable SCSI host adapter. Be aware, however, that it is possible to emulate
RAID from software; Linux can do RAID 0, 1, 4 and 5 with any mixture of
SCSI and IDE disks. This software-based solution is probably less reliable
and slower than a true RAID controller, but certainly also much less expensive.
[Editor(GF): You can't boot from a software RAID set either].
[Editor(GF): ATA and IDE are basically the same thing, and the terms
are used interchangably in this document.]
Here's a discussion that shows some of the advantages of SCSI in more
detail:
from: Greg Smith (GREGS@lss-chq.mhs.compuserve.com)
Under DOS (and DOS/win3.1), there is very little useful work the host
can do while waiting for a disk operation to complete. So handing off some
work from a 66 MHz 486 to, say, an 8 MHz Z80 (on the controller) does result
in a performance loss. Under EVERY other OS worth discussing (Unix, Netware,
NT, OS/2, Win95/98 etc) the processor can go off and do something else
while the access is in progress, so the work done by the other CPU can
result in a performance increase. In such systems, due to virtual memory,
a 64K byte 'contiguous' read requested by a process may be spread to 16
separate physical pages. A good SCSI controller, given a single request,
can perform this 'scatter/gather' operation autonomously. ATA requires
significant interrupt service overhead from the host to handle this.
Another big issue: ATA does not allow more than one I/O request to be
outstanding on a single cable, even to different drives. SCSI allows multiple
I/O requests to be outstanding, and they may be completed out of order.
For instance, process 'A' needs to read a block. The request is sent to
the drive, the disk head starts to move, and process 'A' blocks waiting
for it. Then, process 'B' is allowed to run; it also reads a block from
the disk. Process B's block may be sitting in a RAM cache on the SCSI controller,
or on the drive itself. Or the block may be closer to the head than process
A's block, or on a different drive on the same cable. SCSI allows process
B's request to be completed ahead of process A's, which means that process
B can be running sooner, so that the most expensive chip - the system CPU
- tends to spend less time twiddling its thumbs. Under ATA, the process
B request cannot even be sent to the drive until the process A request
is complete. These SCSI capabilities are very valuable in a true multi-tasking
environment, especialy important in a busy file server, and useless under
DOS, which cannot take advantage of them.
I tend to hear from people, 'Well, I never use multitasking' because
they never actively run two programs at once - all but one are 'just sitting
there'. Consider what happens though, when you minimize a window which
uncovers parts of four other application windows. Each of those applications
is sent a message telling it to update part of its window; under win95,
they will all run concurrently to perform the update. If they need to access
disk (usually because of virtual memory) the smoothness of the update can
depend a lot on the disk system's ability to respond to multiple independent
read requests and finish them all as quickly as possible; SCSI is better
at this.
So, yes, ATA can be faster under DOS; but SCSI provides advantages which
are inaccessible to DOS. They will benefit Win95 however. The cost of intelligent,
fast SCSI controllers and drives should decrease as people discover these
advantages and start buying them.
I should add that many of SCSI's advantages are NOT available with some
of the simpler SCSI controllers which were targeted only to the DOS market
or part of cheap CDROM add-on kits.
Furthermore, SCSI allows far greater flexibility of interconnect. I
concede that for the mass market, which likes to buy pre-configured machines,
this is but a small advantage.
The increased cost of SCSI disks is primarily due to four factors:
SCSI drives are developed first for the high performance market (servers
and high end workstations). After the drive technology matures, they
slap an IDE controller card onto it and start shipping high volume. That's
why IDE/ATA drives are mostly 5400 and 7200 RPM when SCSI drives are mostly
10k and 15k RPM.
SCSI drive firmware is far more complicated than IDE firmware. This is
because SCSI supports multiple initiators, disconnect/reconnect and tagged
command queueing. SCSI protocol also has many more commands. So,
it costs more to develop, debug and test the firmware.
The drive manufacturers know that for high end systems SCSI is required
and IDE isn't really even a choice, so they tack on a premium to
pay for the above two factors (charge what the traffic will bear).
Because SCSI drives are produced in lower volume they cost more to produce.
Conversely, since SCSI drives cost more, people buy IDE instead and SCSI
drives never get the advantage of high volume production.
Interestingly, with other types of SCSI devices, the price difference
isn't as great. SCSI CD-RW drives for example are usually only a little
more expensive than IDE/ATAPI ones of similar ratings.
The short answer is YES. There are a few issues to consider however.
The main issue is which device will be used for booting the system.
Under MSDOS, The system BIOS determined this completely. A couple third
party BIOSes (like MRBIOS) allowed the user to choose the boot source,
but most conventional BIOSes just booted from the IDE if it was present.
If no IDE was present then the standard option card BIOS scan would find
the SCSI card's BIOS and use it to boot.
Under Windows 95 and Windows NT, there are more options. Since the motherboard
BIOS is used to load the boot sector that will still happen according to
the same rules as under MSDOS described above. After the boot sector is
loaded, the O/S's device drivers take over and those can be unloaded or
drive letters re-ordered via the O/S configuration tools.
Update: As of 1999, this issue has largeley been solved. Most BIOSes
allow the user sufficient control to boot from whatever device they want
to (either SCSI or IDE).
QUESTION: Is
it possible for two computers to access/share the same SCSI devices?
ANSWER From: Gary Field (scsifaq@engineer.com)
with input from Michael Burke and Cees de Groot and Sheldon E Smith. Updated: Jan, 2001
Yes, two (or more) hosts can be on the same SCSI bus as other SCSI devices.
As long as all the SCSI hardware requirements are met, multiple hosts can
share the SCSI bus. With that said, let's look at what you're getting yourself
into.
This discussion refers primarily to PCs. There are high end systems
that do allow full of sharing SCSI devices. Usually, this is to allow
fault tolerance. Two systems are connected to the same set of SCSI storage
devices and when one of them fails, the other takes control. AIX with HACMP,
Compaq Tru64 UNIX with TruClusters, and Compaq VMS clusters are examples
of systems that allow this. The combined group of systems with shared
storage is often referred to as a cluster. Open VMS and Tru64 V5.x and
newer also have a feature called the Ditributed Lock Manager which allows
multiple hosts to actually share the filesystems on shared disks locking
individual records as needed.
I am told Windows 2000 server now supports host fail-over for fault
tolerant support of shared disks/RAIDs.
Some basic things you need to watch out for:
Each host's device drivers must use SCSI RESERVE/RELEASE commands to lock
access. This locks the drive for access by only one host adapter. The conflicting
host gets a RESERVATION CONFLICT status until the controlling host sends
a RELEASE cmd or a bus reset is issued. The bus reset is necessary when
the controlling host has failed and left the shared device reserved.
The host adapters on each host as well as each device on the shared bus
must have unique IDs. Some host adapters may not let you set their ID.
Good and common electrical grounding of both systems and the devices.
SCSI length limits are not violated. For practical bus lengths you may
need differential (either HVD or LVD but not mixed).
Make sure both hosts select the same data transfer mode (synch or asynch).
Only shareable devices can be on the shared bus.
Neither host adapter resets the SCSI bus except when needing to break stuck
reservations.
Depending on the type of SCSI devices you want to share, there are different
different issues. We'll discuss them class by class:
For Disks: It would not make sense for two hosts to go about treating shared disks
as if they each owned the device. Data would be destroyed pretty quickly.
Even if the user tries to only access the shared disk from one host at
a time, each host retains a cache of filesystem meta-data(directories etc)
and neither host can know what the other host is changing on the disk.
Therefore, unless one of the hosts restricts itself to read-only access,
the filesystem will get corrupted.
Another way of letting multiple hosts share a disk is to break up the
disk into partitions that are reserved for each host. Each host "owning"
its own file system. Some provision needs to be made to prevent either
host from using the wrong partition however. I'm not aware of a good way
to do this.
For CD-ROMs and scanners: CD-ROM drives and scanners can be shared (for data access) pretty easily
because they are by definition READ-ONLY, but you can't be reading data
from one host and playing music on the same drive from another. With scanners,
discipline will be required to avoid attempting to access the scanner from
both hosts simultaneously.
For Tapes: Sharing tape devices is straightforward unless you need to handle failing-over
from one host to another. If you want to do this the tape backup application
needs to be written to know how to determine the position on the tape where
writing was last successful and take up from there. If the RESERVE/RELEASE
mechanism is used to reserve the tape drive, a bus reset will need to be
used to break the reservation upon host fail-over. The reset will start
the tape drive rewinding, so the application will need to find where it
left off before it starts writing again, or start the backup over again.
For host to host communication: Some people get the bright idea that it would be cool to transfer data
directly from one host to another via the SCSI bus. While this might be
cool indeed, you'll have your work cut out for you to get it to work! In
order to do this one of the host adapters needs to flip into "target mode".
In this mode the "target mode" host is made to appear like a disk or tape
to the other host and data can be written/read to/from it in the usual
manner. The snag is that software that does this is very rare and only
works on specific host adapters. See here for
more info on target mode and vendors that supply software.
Conclusions: Before considering implementing a shared SCSI bus configuration, you
should examine your motives for wanting to do this. If you simply want
to transfer data between the systems, a network (10/100 base T) is a MUCH
simpler solution. A pair of ethernet cards costs about $50 and all the
software you need is built into both Win95/98/NT/ME/2000 or Linux.
If you need fault tolerance, maybe you really do need a shared bus,
but be prepared for lots of expense or years of painful software
development.
Table of Contents
QUESTION:What
is the problem with the Adaptec 1542C and external cables?
ANSWER From: Scot Stelter, Adaptec (Product
Manager for the AHA-1540)
Several articles lately have cited the importance of SCSI-2-compliant
cables when cabling SCSI bus subsystems. Perhaps the most accurate and
technically detailed one was published in Computer Technology Review in
March '93 (Volume XIII, No. 3. PP. 6). In short, it explains the double-clocking
mechanism that can occur due to cables whose impedance falls below the
90-Ohm SCSI-2 spec. Steep edge speeds on the REQ and ACK lines of the SCSI
bus exacerbate the problem, but non-compliant cables are the root cause.
Both LAN TIMES in the US (5/24/93, page 115) and CT Magazine in Germany
(7/93, page 18) cite this cable problem.
In an extensive survey of cables available in the US and Europe, we
found that more than half of the cables available have single-ended impedances
in the 65 to 80 Ohm range -- below the 90 to 132 Ohms specified in the
SCSI-2 spec. It seems that some (not all) cable vendors do not understand
the specification, describing their cables as SCSI-2 compliant when they
are not. A common misconception is that SCSI-2 means a high-density connector.
In fact, there are several connector options. I have published a technical
bulletin that summarizes the critical requirements (TB 001, April 1993).
An artifact of its faster design left the AHA-1540C with faster edge-speeds
than its predecessor, the AHA-1540B. As I have said, this can exacerbate
the effect of bad cables. This explains why some users could get their
AHA-1540B to work when an early AHA-1540C might not.
Essentially, the 1540B was more forgiving than the early 1540Cs. Good
cables fixed the problem, but unfortunately for the user, good cables are
hard to find.
After surveying the cable market and many of our customers, we decided
that bad cables were going to be here for a while, and we had to make the
1540C as forgiving as the 1540B was. At the end of April '93 we made a
change to the AHA-1540C that involved using a passive filter to reduce
the slew rate of the ACK line, the signal that the host adapter drives
during normal data transfers. Extensive testing with many intentionally
illegal configurations confirms that we succeeded. Prior to release, we
tested the AHA-1540C with over 200 peripherals, systems and demanding software
programs with no failures. Then, a second team retested the AHA-1540C across
a wild combination of temperatures, humidities and other stresses. This
testing gives me confidence that the AHA-1540 line continues to serve as
the gold standard for SCSI compatibility.
QUESTION: What
is the difference between the Adaptec 1542A and 1542B?
ANSWER From: fishman@panix.com (Harvey Fishman)
The AHA-1542A is obsolete and no longer supported by Adaptec. They stopped
providing firmware upgrades at some level prior to the equivalence to the
3.10 level of the AHA-1542B firmware. I am not sure just where though.
The present latest AHA-1542B firmware is version 3.20, and supports drives
up to 8GB under MS-DOS.
QUESTION:What
are the differences between the Adaptec 1542B and the 1542C?
ANSWER from: Terry Kennedy (terry@spcvxa.spc.edu)
The 1542C is an an updated model which replaces the 1542B. The 1542C
features jumperless setup, having only 8 DIP switches. All other configuration
options are set using the 1542C's built-in BIOS configuration utility.
Configurable features not found on the 1542B are:
Ability to enable/disable sync negotiation on a per-ID basis (the 1542B
could only do it for all ID's on the SCSI bus)
Ability to send "start unit" commands on a per-ID basis
BIOS works with alternate I/O port settings on the adapter.
Ability to boot from ID's other than 0
Software-selectable termination
Software-selectable geometry translation
Additional DMA speeds of 3.3 and 10 MB/sec
Additionally, the 1542C uses a Z80 CPU and 8Kb buffer instead of an 8085
and 2Kb buffer as on the 1542B.
QUESTION: What
are the differences between the 1542C and the 1542CF?
ANSWER from: Terry Kennedy (terry@spcvxa.spc.edu)
The 1542CF includes all of the 1542C features, and adds "Fast" SCSI
operation, providing SCSI data rates of up to 10MB/sec (compared with an
upper limit of 5MB/sec on the 1542C). This is unrelated to the host DMA
rate. It also has a software configurable address for the floppy controller
and a "self-healing" fuse for termination power.
QUESTION:What
kinds of optical drives are available? ANSWER From: Psycho Bob <honge@creighton.edu>[Editor(GF)]
UPDATE: November 1999
Optical storage has good points going for it; Immunity to stray
magnetic fields; Potential for higher storage capacity per unit area; and
relatively low media cost.
Current optical storage solution offers two different types of storage
--rewritable and non-rewritable. The non-rewritable represents storage
method in which the data becomes permanent after being written onto the
disc. Rewritables, on the other hand, allows you to alter the data after
it has been written -- just like the magnetic storage devices. And for
rewritables, two different technologies are available -- magneto-optical
("MO") and phase-change ("PD").
Magneto-Optical
As the name implies, MO uses both magnetic and optical technology to
store data on the disc. The disc itself is rare earth metal substrate.
When data is to be written, the particular spot is first heated by the
laser to the Curie point, and the magnetic field is generated while the
spot cools. By varying the magnetic field angle, the substrate is polarized
in a certain way that it will reflect back the laser beam differently depending
on the magnetic field angle present when the particular spot was cooling
down.
MO comes in many sizes and capacities. Consumers were first exposed
to MO in Steve Jobs' NeXT computer in the mid-1980s. Although 5.25" had
a slow start due to initial high cost, it has been evolving quite nicely.
The more popular ISO capacities for 5.25" MO are 4.8GB/5.2GB, 2.4GB/2.6GB,
and 1.2GB/1.3GB. In 3.5" form, MO is available in 540MB/640MB, 230MB,and
the 128MB. There are also some 12" MO, 14" MO, and other odd sizes in odd
capacities -- particularly the hybrid 3.5" 1.3GB MO/PD drive. But they
are limited to niche markets due to high cost and rarity.
Sony MiniDisc-Data is derived from the Mini-Disc (MD) audio format cartridge
introduced earlier. MD-Data is to MD as CD-ROM is to digital audio compact
disc (CD-DA). MD-Data (and digital audio MD) is based on the same magneto-optical
technology, which partially explains the initial high-cost of the consumer
MD audio recordable units. Fow now, MD-Data is the smallest of the MO family.
With 2.5" form factor, it can store either 140MB or 650MB of uncompressed
data.
Sony pushed the original MD-Data in the mid-'90s, but it did not catch
on due to high cost (for the capacity offered) and Sony's decision to separate
MD audio function from MD-Data. And for few years, MD format has lagged
behind the capacity and speed of fellow MO breathens. In November 1999,
Sony announced the MD-Data-2 format and has gotten the format up-to-date.
It now has 650MB storage capacity with equal increase in transfer speed.
The MD-Data-2 debuts with Sony's MPEG-2 camcorder in the Japanese market
in December of 1999. The most important technical advancement MD-Data brought
for MO in general is the one-pass recording. Prior to 5.25" 2.4GB/2.6GB
MO and 3.5" 540MB/640MB MO, practically all MO used two passes to write
data onto the disc -- one pass to erase the whole track, and a follow-up
pass to write the updated data. MD's one pass recording, called light intensity
modulation, direct over-write (LIM-DOW, ISO 14517) has been incorporated
into several later-generation MO formats to speed up the writing speed.
Anyway, what's the limit of erase/write cycle can MO endure? Well, it
doesn't look like anyone is really sure about it. Few years past, it is
guessed to be around 1 million times with 30 years of archival stability.
Today, Maxoptix says MO can sustain "greater than 1 trillion" cycles with
greater than 50 years of archival storage life.
Today, the popular MO formats are 3.5" and 5.25" that follow the ISO
standard. (Yes, there are others. But they're far and few in between...)
The drives and medias are available from Fujitsu, IBM, Maxoptix, Pinnacle
Micro, Pioneer Sony, Toshiba, and others.
Panasonic phase-change double-function (PD)
In around mid-'95, Panasonic released a proprietary optical storage
format called phase-change double-function (PD) drive. The PD uses substrate
that will reflect the light differently when heated to different temperatures
(and then cooled). Write-once-read-multiple (WORM) medias were actually
the first phase-change formats, but PD is the first *reversible* (that
is, "re-writable") phase-change format. Panasonic PD stores 650MB per PD
cartridge. Panasonic's own PD drive has also gone away with Sony's MD-Data,
but the technology lives on in forms of CD-RW and DVD-RAM. The PD media
is said to take approximately 1,000 erase/write cycles. After about 1,000
cycles, the substrate will be fatigued to the point where the two different
states of the crystalline structure will become difficult to differentiate
reliably.
WORM
Write-once-read-multiple (WORM) format is a *write once* format -- once
you have written the data to the disc, the written data cannot be changed.
Put it another way, the data recorded on the disc media is *permanent*.
WORM was the first popular format for optical storage, before being
eclipsed by MO. WORM is still used by big companies and the government
for archival purposes since it has the characteristic of not being able
to be altered without damaging the media (good audit trail).
The new WORM formats being introduced are tending to be proprietary.
There is rarely any interchangability between different vendor's drives
and media. During the WORM to MO transition period, a curious format called
continuous composite write-once (CCW) appeared. CCW cartridges function
as WORM cartridges, writable using the installed base of WORM drives. But
put it into MO drive, CCW cartridges becomes rewritable. Simply put, CCW
is MO in WORM's clothing. Many of today's 5.25" MO drives still have the
capability to read CCW cartridges. And practically all WORM cartridges
sold today are CCW variety.
Sony-Philips Compact Disc (CD-R/CD-RW)...
WORM (in "MO" form) was once limited to niche market, but made one heck
of a come-back with form of CD-R. CD-R is based on the Sony-Philips' proprietary
CD-DA, commonly referred as "CD" (you know, those shiny disc things that
America-On-Line sends you). CD-R offers standard capacity of 650MB of data
per disc, and can be used to store data or record music (and be played
in common CD players). But here, only the data-storage facet of the CD-R/CD-RW
is discussed.
As far as data storage is concerned, the specifications are written
in the "Orange Book." The Orange Book established three physical format
for recordable CDs -- CD-MO, CD-R (previously known as "CD-WO"), and CD-RW
(previously known as "CD-E").
CD-MO is a MO medium in CD format. As far as I know, this format only
exists only on paper. The popular formats to come out of it are CD-R and
CD-RW.
CD-R/CD-RW Incompatibility
Sony and Philips finally agreed on a standard for compact disc re-writable
(CD-RW), together with HP, Matsushita, etc. Long story short, the CD-RW
uses phase-change media -- same as Panasonic proprietary PD format. Not
only that, it also stores 650MB like PD. And also like the PD, the CD-RW
media cannot be read in existing CD-ROM drives! CD-ROM drives manufactured
in 1997 and after will read CD-RW discs though.
CD-R and CD-RW are known for their incompatibilities. There are combinations
of CD-R media, CD-R recorder, and CD-ROM player that simply wouldn't work.
CD-RW is worse -- virtually no audio CD players will play CD-RW disc. The
problem stems from the fact that reflectivity of the CD-R is less than
a factory-pressed CD-ROM. And CD-RW is worse in that respect than the CD-R.
As such, only the very recent CD-ROM player labled "Multi-Read" can read
the CD-RW discs.
DVD
Possibly the most soap-operatic of all data-storage formats. With convergence
of computers and audio/video equipment, DVD was the most talked about format
for years as several companies fighting for what "DVD" format should be.
Writable DVD formats:
For now, DVD-RAM is not made to be playable in DVD-ROM players that
are so popular for its good pictures. If you've looked at it, you'll notice
DVD-RAM is encased in a carriage case (a la MO-style) but "video" DVDs
aren't. Although I think it may be possible to take the DVD-RAM media out
of the case and stick it into computer DVD-ROM to read the recorded data.
What's the difference between DVD-RAM, DVD-RW, and DVD+RW? (March 2000)
The names differ depending on whose specification the DVD storage is
based on. If it's Matsushita (Panasonic), then it's DVD-RAM; if it's Sony/Philips,
then it's DVD+RW; or if it's Pioneer, then the name becomes DVD-RW. The
majority of current DVD storage devices follow Matsushita's DVD-RAM standard.
Pioneer currently has its DVD-RW in the form of a DVD video recorder in
Japan. Each has slightly different storage capacities. It's still unknown
whether they'll be truly compatible with each other. But all three specs
have been submitted and all are regarded as DVD re-writable "standards."
The Future?
Future optical storage will likely get bigger and bigger capacities,
and faster and faster transfer rates.
Anyway, MO is here to stay, so are CD and the DVD family of formats.
As for DVD... The competitions should prove to be entertaining (not). DVD
is not much about technology but more about politics. But since so many
electronic and entertianment giants are backing the DVD, you probably won't
go wrong if you buy one. (Just hope the one you buy will not be orphaned
at the turn of the hat by DVD consortium.) Some form(s) of DVD recordable
will eventually standardized, but don't expect it to have more storage/speed
than what MO/PD/WORM formats offer.
Standards for storage are set by many organizations. International Standards
Organization (ISO), European Computer Manufacturers Association (ECMA),
Deutsche Institut fur Normung (DIN), Japanese Industrial Standards Committee
(JISC), and American National Standards Institute (ANSI) set the main optical
disc storage standards. The ISO standards take precedence over all other
standards.
In the above table, the heading defines one standard -- e.g. 5.25" MO
1.2GB/1.3GB has both ISO 13549 and ECMA 184 listed for it. IT IS NOT THAT
1.2GB FOLLOWS ISO 13549 AND 1.3GB FOLLOWS ECMA 184.
Of CD standards...
Funny as it seems, CD is actually considered as a proprietary format
made by Sony and Phillips. The physical format for derivatives like CD-ROM
and CD-R are "written in mutual agreement" in form of Red Book, Yellow
Book, Orange Book, etc.
Of bytes/sector and usability...
As many of you might notice (especially on 5.25" MOs), there are different
sized sectors. Many O/Ses assume one sector to contain 512 bytes. If you
buy any of the media that use different than 512 byte/sector, you will
need a software driver of some sort to use the media.
In optical media, the sectors are "hard sectored" at factory -- in other
words, you cannot change the number of sectors by reformatting (low-level
formatting) them. Take the 5.25" 1.2GB/1.3GB MO for example again. The
1.3GB media is sectored at 1024 bytes per sector. So the 1.3GB media has
total of 637,041 sectors (per side) on it. If you do not use a software
driver and your operating system does not properly recognize it, the 1.3GB
media will become a 650MB cartridge (~325MB per side)!!
The safest bet is to use the 512 bytes/sector media. That should make
the drive and media usable on most operating systems.
QUESTION: Where
can I get various SCSI documentation? QUESTION: How
can I find out about the emerging SCSI standards? Updated: August, 2000
Thanks to John Lohmeyer of LSI Logic (formerly Symbios Logic, AT&T
GIS, NCR Microelectronics), a number of SCSI related files are freely available.
This is the place to find more information about I/O Interfaces, especially
SCSI, SCSI-2, and SCSI-3 including SPI, Fast-20 (Ultra
SCSI), Fast-40 (Ultra2 SCSI), Low Voltage Differential (LVD), SPI-3
(Ultra3 SCSI or Ultra160), SPI-4 (Ultra320), CAM, and much more. There
are also pointers here to other web sites on Fibre Channel, ATA (IDE),
and ATAPI.
Small Form Factor (SFF) Committee documents (like the SCA spec's) are
available by FaxAccess at:
(408) 741-1600 You will be asked to order documents by number.
For example: to get information on the Single Connector Attach spec.
The SCA-1 spec. is document #8015
The SCA-2 spec. is document #8046 (8451?)
document #8000 is an index to the other documents.
SCA-2 pinout data can also be found in the SCSI3 SPI-4 document referred
to as "Alternative 4".
This FaxAccess service is available to all, but please keep in mind
that unless you have engineering-level understanding of peripheral interfaces,
you _will_not_ be able to understand any of it and you are wasting your
own time and the bandwidth of these resources. If you are trying to learn
more about SCSI, you are better off reading the magazine articles and books
listed elsewhere in this FAQ.
The SCSI, SFF, SSA, and Fibre Channel reflectors:
A list of these is available on the T10 site.
"The SCSI, SFF, SSA, and Fibre Channel reflectors are for review and
commentary on the respective specifications, not for asking questions about
the interfaces (unless related to a specific ambiguity in a specification)
nor for recruiting nor for technical support nor any purpose other than
what is stated. The reflectors _are_ available for public review and commentary
as required by ANSI and ISO."
Any spec on the reflectors or on the BBS or on the ftp sites are **proposed**
or **preliminary** and are often subject to major substantive changes during
the committee process. Actual, released, final specs are *only* available
from Global Engineering Documents.
The Book of SCSI : I/O for the New Millennium,
by Gary Field, Peter Ridge et al
Published by No Starch Press, San Francisco, CA
ISBN # 1-886411-10-7 , List Price $49.95.
A very complete reference and tutorial on almost all aspects of SCSI,
including all the latest advances like Ultra2WIDE/LVD, and all the previous
standard SCSI features. It addresses everything you need to know to install
and debug SCSI I/O on a PC running Windows 95/98/NT and information
on Linux as well. Also includes a CD-ROM with useful SCSI utilities and
information.
The technical editor was none other than John Lohmeyer (chairman of
the ANSI SCSI committee since the beginning of SCSI), so you know the facts
are straight!
IN-DEPTH EXPLORATION OF SCSI can be obtained
from Solution Technology, Attn: SCSI Publications, POB 104, Boulder Creek,
CA 95006, (408)338-4285, FAX (408)338-4374
THE SCSI ENCYLOPEDIA and the SCSI BENCH REFERENCE can be obtained from
ENDL Publishing, 14426 Black Walnut Ct., Saratoga, CA 95090,
(408)867-6642, FAX (408)867-2115
SCSI: UNDERSTANDING THE SMALL COMPUTER SYSTEM INTERFACE was published
by Prentice-Hall, ISBN 0-13-796855-8 (Seems to be out of print)
A neat little book called "Basics of SCSI" second edition, was sent
to me free of charge by Ancot Corporation, Menlo Park, CA (415) 322-5322.
It gives a simplified description of how most aspects of the SCSI bus work
and includes some discussion of SCSI-2 issues.
"Programmer's Guide to SCSI" with
CDROM - by Brian Sawert.
Published by Addison Wesley, Reading, MA. SRP $39.95
ISBN # 0-201-18538-5
Includes a chapter on UNIX SCSI subsystems written by Gary Field.
'The SCSI Bus and IDE Interface' 2nd edition by Friedhelm
Scmidt,
Addison-Wesley Publishing, $34.95 (I think). It includes a diskette
with examples of source code to handle SCSI and IDE devices from a low-level
programmer's perspective, and it has very detailed technical descriptions
of both subsystems.
Not a book for beginners, but I heartily recommend it for anyone who's
serious about learning the technical ropes.
THEREF(tm) is a comprehensive Directory of Hard Drives, Floppy Drives,
Optical Drives, and Drive Controllers & Host Adapters. It is designed
to help the novice and pro alike with integration problems and system setups.
Information is provided in two handy formats; Portrait mode, for those
who prefer a normal book-binding type print format, and(or) do not have
a printer with Landscape capability, and Landscape mode, for those who
pre-fer a computer-printout type format.
For printing, a Laserjet is preferred, but not necessary, and setup
info is provided. For viewing, LIST(tm) by Vernon Buerg, will provide an
excellent result, and allow text searches for finding specific models.
By F. Robert Falbo
Due many reports about the unavailablity of this file/archive I made
sure that the file does exist at the following site:
(In that directory-path there is also a sub-directory Seagate, where
you also can find info/files about Seagate-drives).
Before you actually get this file, be sure to get/read the file /README.FILETYPES
since it explains the used file-extension and which (de-)archiver should
be used (and where to find/get them!).
Note: In the archive there are files containing Extended ASCII or ANSI
characters (mostly used with IBM- and compatible PC's), so it may be a
bit unreadable when reading it on non-PC systems, or without using a proper
Characterset/Font!
Also: Future Domain, Corel CD Creator, Trantor,
Incat systems.
ANSWER From: jcaples@netcom.com (Jon D Caples)
408 945-8600 Main number
800 959 7274 tech support
800 442 7274 orders, doc, new bios, etc.
408 945-7727 BBS
Adaptec's general inquiry number, 800-959-7274, affords access to a
FAX-based information retrieval system. In order to preserve the accuracy
of this information, I won't go into details about how to use it (since
Adaptec may change things without telling me :) ).
For those outside the CAN-US area, or local to Adaptec the direct FAX
info number is (408) 957-7150.
There are three general topics as of this writing:
General Information
Sales Information
Technical Information
Give it a call and request the directory! As of this writing there are
over 130 documents available. You need a touchtone phone and the fax number.
You'll also be asked for an extension number to stamp on the FAX which
will be used to identify the recipient.
[Editor(GF): As of July 1993 Adaptec bought Trantor.
[(from: Andrew Lockhart (andrew@interact.manawatu.planet.co.nz) ]
You can address Adaptec support by email. The address is support@adaptec.com.
An auto-responder will bounce a message back acknowledging receipt of your
email. This message will also detail other current forms of Adaptec Technical
support. They promise a, no more than, 5 day turn-around. We have found
the response brief, but satisfactory to our needs. We should add, we mention
we are dealers in our email (which may improve Adaptec's response).
ANSWER From: Ken Porter (72420.2436@compuserve.com)
Fujitsu FactsLine FAX Back service (408) 428-0456
A six page catalog of available documents can be ordered.
ANSWER From: Mike Henry (anonymous)
A while back, Fujitsu created a product called Fujitsu Knowledge System
(FKS) (long available on Compuserve (GO FUJITSU)). It is a Windows Help
File (.HLP) listing of many Fujitsu disk, tape, and optical products. It
includes drive switch/jumper settings and meanings. It is available via
anonymous ftp from ftp.intellistor.com in the /pub/fks directory, filename:
fks.exe
It is self-extracting and mostly self-documenting.
Quantum Corporation
500 McCarthy Blvd.
Milpitas, CA
95035
Technical Support Telephone Numbers:
800 826-8022 Main Technical Support Number
408 894-3282 Technical Support Fax
408 894-3214 Technical Support BBS V.32 8N1
408 434-9262 Technical Support for Plus Development Products
408 894-4000 Main Quantum Phone number
800 4DISKFAX FAX on demand (From Thanh Ma tma@encore.com)
WWW: http://www.quantum.com/
Note: In October, 2000 Maxtor merged
with Quantum.
ANSWER From: John McDonald (John_McDonald@notes.seagate.com)
Technical Support Services
Online Services
Using a modem, you can obtain troubleshooting tips, free utility programs,
drive specifications, and jumper settings for Seagate's entire product
line. You can also download software for installing and analyzing your
drive.
SeaBOARD is a computer bulletin board system that contains information
about Seagate disc and tape drive products and is available 24 hours daily.
Set your communications software to eight data bits, no parity and one
stop bit (8-N-1).
Location Phone number
Australia 61-2-9756-2359
France 33 1-48 25 35 95
Germany 49-89-1409331
Taiwan 886-2-2719-6075
Thailand 662-531-8111
UK 44-1628-478011
USA Disc: 405-936-1600
Tape: 405-936-1630
FAX Services
SeaFAX
You can use a touch-tone telephone to access Seagate's automated FAX
system to receive technical support information by return FAX. This service
is available 24 hours daily.
Location Phone number
Australia 61-2-9756-5170
Germany 49-89-14305102
UK 44-1628-894084
USA 1-800-SEAGATE or
Disc: 405-936-1620
Tape: 405-936-1640
Seagate Technical Support FAX
You can FAX questions or comments to technical support specialists
24 hours daily. Responses are sent during business hours.
Location Phone number
Australia 61-2-9725-4052
France 33 1-46 04 42 50
Germany 49-89-14305100
Hong Kong 852-2368 7173
Japan 81-3-5462-2979
Korea 82-2-556-7395
82-2-556-4251
Singapore 65-488-7528
Taiwan 886-2-2715-2923
UK 44-1628-890660
USA Disc: 405-936-1685
Tape: 405-936-1683
Telephone Services
SeaFONE
1-800-SEAGATE
Seagate's 800 number (1-800-732-4283) allows toll-free access to automated
self-help services that provide answers to commonly asked questions, troubleshooting
tips, and specifications for disc drives and tape drives. This service
is available 24 hours daily and requires a touch-tone phone. International
callers can reach this automated self-help service by calling 405-936-1234.
Seagate Telephone Technical Support
For one-on-one help, you can talk to a technical support specialist
during local business hours. Before calling, note your system configuration
and drive model number (STnnnn).
[Editor(GF)]: In Feb., 1998, Adaptec attempted to purchase Symbios Logic.
The Federal Trade Commission told them they couldn't and subsequently,
Symbios was sold to LSI Logic. In 2014 LSI was acquired by Broadcom Limited.
For literature on any Symbios Logic product please contact:
There are 2 handshaking modes on the SCSI bus, used for transferring
data:
ASYNCHRONOUS and SYNCHRONOUS.
ASYNCHRONOUS is a classic Req/Ack handshake.
SYNCHRONOUS is "sort of" Req/Ack, only it allows you to issue multiple
Req's before receiving Ack's. What this means in practice is that SYNCHRONOUS
transfers are approx 3 times faster than ASYNCHRONOUS.
SCSI1 allowed asynchronous transfers at up to 1.5 Mbytes/Sec and synchronous
transfers at up to 5.0 Mbytes/Sec.
SCSI2 had some of the timing margins "shaved" in order that faster handshaking
could occur. The result is that asynchronous transfers can run at up to
3.0 Mbytes/Sec and synchronous transfers at up to 10.0 Mbytes/Sec.
The term "FAST" is generally applied to a SCSI device which can do syncrhonous
transfers at speeds in excess of 5.0 Mbytes/Sec. This term can only be
applied to SCSI2 devices since SCSI1 didn't have the timing margins that
allow for FAST transfers.
The terminator contains 18 220-ohm resistors from signals to TERMPWR,
and 18 330-ohm resistors from those signals to GROUND. I've drawn that
below:
TERMPWR
--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | | | | | | | | | | | | | | | | |
R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1
| | | | | | | | | | | | | | | | | |
sig o o o o o o o o o o o o o o o o o o
| | | | | | | | | | | | | | | | | |
R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2
| | | | | | | | | | | | | | | | | |
--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
GROUND
R1 = 220 Ohms, R2 = 330 Ohms
When you measure from any one signal to termpower, you aren't measuring
that resistor in isolation, you are measuring that resistor IN PARALLEL
with the combination of the corresponding 330 ohm resistor plus 17 220+330
ohm resistor pairs in series.
I've redrawn the schematic to
make this easier to see:
TERMPWR
/+---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | | | | | | | | | | | | | | | | |
| R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1 R1
| | | | | | | | | | | | | | | | | |
| o o o o o o o o o o o o o o o o o
| | | | | | | | | | | | | | | | | |
| R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2 R2
| | | | | | | | | | | | | | | | | |
| --+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| / GROUND
R1 |
| |
| R2
| /
o <--------- 17 other pairs in parallel ---------->
sig
We're trying to measure that one resistor from a signal to TERMPWR, but
there's a ton of other stuff in parallel. The resistance of that "stuff"
is 330 + 550/17 ohms (the 330 ohm resistor, in series with a parallel combination
of 17 550 ohm resistors). The general formula for the equivalent of two
resistances in parallel is R1*R2/(R1+R2).
Whipping out my trusty spreadsheet, I find that the "stuff" has a resistance
of about 362 ohms, and that, in parallel with 220 ohms is about 137 ohms.
QUESTION:Can someone
explain to me the difference between 'normal' SCSI and differential SCSI?
ANSWER From: ralf@wpi.WPI.EDU (Ralph Valentino)
"Normal" SCSI is also called "Single-ended" SCSI. For each signal that
needs to be sent across the bus, there exists a wire to carry it. With
differential SCSI, for each signal that needs to be sent across the bus,
there exists a pair of wires to carry it. The first in this pair carries
the same type of signal the single-ended SCSI carries. The second in this
pair, however, carries its logical inversion. The receiver takes the difference
of the pair (thus the name differential), which makes it less susceptible
to noise and allows for greater cable length.
Most times the model number of the drive will end with "D".
Use an Ohm meter to check the resistance between pins 21 & 22.
On a single ended system, they should both be tied together and tied
to GND.
On the differential drive, they should be open or have a significant
resistance between them. Differential drives are less common than single-ended
ones, because they are mainly used only where longer cable runs are necessary,
and they are not generally used in PCs, but state of the art drives are
available with differential interfaces. Generally only the higher performance
drives have a differential option because of the added cost.
SCA stands for "Single Connector Attachment". It is a standard being
worked on by the ANSI Small Form Factor (SFF) committee. It combines WIDE
SCSI signals, Power connections and ID switch connections onto one connector.
The main reason for creating this standard was to make it easier to
connect drives in a hot-swappable RAID configuration.
SCSI vendors sell adapters that bring out the three sets of signals
to conventional connectors.
SCA adapters for LVD drives:
If your SCA drive is an Ultra2 WIDE or LVD type drive, you need to
make sure to get an SCA adapter designed to work with LVD drives. Some
SCA adapters don't connect the DIFFSENS signal through which prevents proper
sensing of whether single ended devices are on the bus. So if your drive
is LVD, be sure to ask the vendor for an adapter that's compatible with
LVD.
The connector families described by the drawings have standard pin numberings
which are described the same way by all vendors that I have encountered.
The SCSI-2 specification identifies the standard numbering, using that
convention. It happened to be documented by AMP, but all the vendors use
the same convention.
The following diagrams have the outline drawings of connector sockets
at the bottom. This is really for reference only, because the connector
sockets and plugs are both specified as to their numbering and usually
are labeled.
There are some minor problems in naming the microconnector conductor pairs,
which I have corrected in the enclosed diagram. All the conductor pairs
of the Mini-Micro (High Density) connector are in fact passed through on
the cables. SCSI-2 defines the RSR (Reserved) lines as may be ground or
may be open, but they are still passed through the cable. Most present
standard SCSI devices will ground those lines.
Note that this connector is NON COMPLIANT WITH ANY SCSI STANDARD!
The grounding is insufficient and does not allow for proper twisted-pair
transmission line implementation. It is recommended that a short adapter
cable
be used to convert to the more common Centronics style 50 pin connection,
rather than extend the 25 pin connection any further than necessary.
The Macintosh Plus used a NCR 5380 SCSI chip controlled by the MC68000
processor.
___________________
| SCSI DB-25S |
| SIGNAL pin(s) |
+------------------+ DB-25S (female)
| -DB(0) | 8 | _____________________________
| -DB(1) | 21 | 13\ o o o o o o o o o o o o o /1
| -DB(2) | 22 | 25\ o o o o o o o o o o o o /14
| -DB(3) | 10 | ------------------------
| -DB(4) | 23 | View from rear of computer.
| -DB(5) | 11 |
| -DB(6) | 12 |
| -DB(7) | 13 |
| -DB(P) | 20 |
| GND | 7,9,14 |
| GND |16,18,24 |
| -ATN | 17 |
| BSY | 6 |
| -ACK | 5 |
| -RST | 4 |
| -MSG | 2 |
| -SEL | 19 |
| -C/D | 15 |
| -REQ | 1 |
| -I/O | 3 |
+------------------+
Pin 25 is NOT CONNECTED in the Mac Plus implementation. Newer Macs connect
TERMPWR to pin 25, but are otherwise the same.
Future Domain 25 pin connector pinout
Used on TMC-830/845 and TMC-850/860/885.
Note:
Use the Macintosh pinout above for TMC-850M, TMC-1610M, TMC-1650/1670
or MCS-600
___________________
| SCSI | DB-25S |
| SIGNAL| pin(s) |
+-----------------+ DB-25S (female)
| -DB(0)| 14 | _____________________________
| -DB(1)| 2 | 13\ o o o o o o o o o o o o o /1
| -DB(2)| 15 | 25\ o o o o o o o o o o o o /14
| -DB(3)| 3 | ------------------------
| -DB(4)| 16 | View from rear of computer.
| -DB(5)| 4 |
| -DB(6)| 17 |
| -DB(7)| 5 |
| -DB(P)| 18 |
| GND |1,6,8,13 |
| GND |13,19,25 |
| -ATN | 20 |
| BSY | 23 |
| -ACK | 22 |
| -RST | 10 |
| -MSG | 21 |
| -SEL | 7 |
| -C/D | 11 |
| -REQ | 24 |
| -I/O | 12 |
+-----------------+
Pin 9 is NOT CONNECTED
QUESTION: Where
can I find pictures of the various SCSI connectors? ANSWER From: Charlie (MotahCity@netzero.net)
It isn't easy for a newcomer to identify the multitude of SCSI connectors
by name alone.
This URL
will show diagrams and photos to help with identifying them:
QUESTION:What
is the difference between SCSI-1 and SCSI-2?
ANSWER From Dal Allen:
SCSI-1_versus_SCSI-2
In 1985, when the first SCSI standard was being finalized as an American
National Standard, the X3T9.2 Task Group was approached by a group of manufacturers.
The group wanted to increase the mandatory requirements of SCSI and to
define further features for direct-access devices. Rather than delay the
SCSI standard, X3T9.2 formed an ad hoc group to develop a working paper
that was eventually called the Common Command Set (CCS). Many products
were designed to this working paper.
In parallel with the development of the CCS working paper, X3T9.2 sought
permission to begin working on an enhanced SCSI standard, to be called
SCSI-2. SCSI-2 would include the results of the CCS working paper, caching
commands, performance enhancement features, and whatever else X3T9.2 deemed
worthwhile.
While SCSI-2 was to go beyond the original SCSI standard (now referred
to as SCSI-1), it was to retain a high degree of compatibility with SCSI-1
devices.
How is SCSI-2 different from SCSI-1?
1. Several options were removed from SCSI-1:
a. Single initiator option was removed.
b. Non-arbitrating Systems option was removed.
c. Non-extended sense data option was removed.
d. Reservation queuing option was removed.
e. The read-only device command set was replaced by the CD-ROM command
set.
f. The alternative 1 shielded connector was dropped.
2. There are several new low-level requirements in SCSI-2:
a. Parity must be implemented.
b. Initiators must provide TERMPWR -- Targets may provide TERMPWR.
c. The arbitration delay was extended to 2.4 us from 2.2 us.
d. Message support is now required.
3. Many options significantly enhancing SCSI were added:
a. Wide SCSI (up to 32 bits wide using a second cable)
b. Fast SCSI (synchronous data transfers of up to 10 Mega-transfers
per second -- up to 40 MegaBytes per second when combined with wide SCSI)
c. Command queuing (up to 256 commands per initiator on each logical
unit)
d. High-density connector alternatives were added for both shielded
and non- shielded connectors.
e. Improved termination for single-ended buses (Alternative 2)
f. Asynchronous event notification
g. Extended contingent allegiance
h. Terminate I/O Process messaging for time-critical process termination.
4. New command sets were added to SCSI-2 including:
a. CD-ROM (replaces read-only devices)
b. Scanner devices
c. Optical memory devices (provides for write-once, read-only, and
erasable media)
d. Medium changer devices
e. Communications devices
5. All command sets were enhanced:
a. Device Models were added
b. Extended sense was expanded to add:
+ Additional sense codes
+ Additional sense code qualifiers
+ Field replaceable unit code
+ Sense key specific bytes
c. INQUIRY DATA was expanded to add:
+ An implemented options byte
+ Vendor identification field
+ Product identification field
+ Product revision level field
+ Vital product data (more extensive product reporting)
d. The MODE SELECT and MODE SENSE commands were paged for all device
types
e. The following commands were added for all device types:
+ CHANGE DEFINITION
+ LOG SELECT
+ LOG SENSE
+ READ BUFFER
+ WRITE BUFFER
f. The COPY command definition was expanded to include information on
how to handle inexact block sizes and to include an image copy option.
g. The direct-access device command set was enhanced as follows:
+ The FORMAT UNIT command provides more control over defect management
+ Cache management was added:
- LOCK/UNLOCK CACHE command
- PREFETCH command
- SYNCHRONIZE CACHE command
- Force unit access bit
- Disable page out bit
+ Several new commands were added:
- READ DEFECT DATA
- READ LONG
- WRITE LONG
- WRITE SAME
+ The sequential-access device command set was enhanced as follows:
- Partitioned media concept was added:
* LOCATE command
* READ POSITION command
- Several mode pages were added
- Buffered mode 2 was added
- An immediate bit was added to the WRITE FILEMARKS command
+ The printer device command set was enhanced as follows:
- Several mode pages defined:
* Disconnect/reconnect
* Parallel printer
* Serial printer
* Printer options
+ The write-once (optical) device command set was enhanced by:
- Several new commands were added:
* MEDIUM SCAN
* READ UPDATED BLOCK
* UPDATE BLOCK
- Twelve-byte command descriptor blocks were defined for several
The following article was written by Dal Allan of ENDL in April 1990.
It was published nine months later in the January 1991 issue of "Computer
Technology Review". While it appeared in the Tape Storage Technology Section
of CTR, the article is general in nature and tape-specific. In spite of
the less than timely publication, most of the information is still valid.
It is reprinted here with the permission of the author. If you copy
this article, please include this notice giving "Computer Technology Review"
credit for first publication.
What's New in SCSI-2
Scuzzy is the pronunciation and SCSI (Small Computer System Interface)
is the acronym, for the best known and most widely used ANSI (American
National Standards Institute) interface.
Despite use of the term "Small" in its name, everyone has to agree that
Scuzzy is large - in use, in market impact, in influence, and unfortunately,
in documentation. The standards effort that began with a 20-page specification
in 1980 has grown to a 600 page extravaganza of technical information.
Even before ANSI (American National Standards Institute) published the
first run of SCSI as a standards document in 1986, ASC (Accredited Standards
Committee) X3T9.2 was hard at work on SCSI-2.
No technical rationale can be offered as to why SCSI-1 ended and SCSI-2
began, or as to why SCSI-2 ended and SCSI-3 began. The justification
is much more simple - you have to stop sometime and get a standard printed.
Popular interfaces never stop evolving, adapting, and expanding to meet
more uses than originally envisaged.
Interfaces even live far beyond their technological lifespan. SMD (Storage
Module Drive) has been called technically obsolete for 5 years but every
year there are more megabytes shipped on the SMD interface than the year
before. This will probably continue for another year or so before the high
point is reached, and it will be at least a decade before SMD is considered
to be insignificant.
If SCSI enhancements are cut off at an arbitrary point, what initiates
the decision? Impatience is as good an answer as any. The committee and
the market get sick of promises that the revision process will "end soon,"
and assert pressure to "do it now."
The SCSI-3 effort is actively under way right now, and the workload
of the committee seems to be no less than it was a year ago. What is pleasant,
is that the political pressures have eased.
There is a major difference between the standards for SCSI in 1986 and
SCSI-2 in 1990. The stated goal of compatibility between manufacturers
had not been achieved in SCSI in 1986 due to a proliferation of undocumented
"features."
Each implementation was different enough that new software drivers had
to be written for each device. OEMs defined variations in hardware that
required custom development programs and unique microcode. Out of this
diversity arose a cry for commonality that turned into CCS (Common Command
Set), and became so popular that it took on an identity of its own.
CCS defined the data structures of Mode Select and Mode Sense commands,
defect management on the Format command, and error recovery procedures.
CCS succeeded because the goals were limited, the objectives clear and
the time was right.
CCS was the beginning of SCSI-2, but it was only for disks. Tape and
optical disks suffered from diversity, and so it was that the first working
group efforts on SCSI-2 were focused on tapes and optical disks. However,
opening up a new standards effort is like lifting the lid on Pandora's
Box - it's hard to stay focused on a single task. SCSI-2 went far beyond
extending and consolidating CCS for multiple device types.
SCSI-2 represents three years of creative thought by some of the best
minds in the business. Many of the new features will be useful only in
advanced systems; a few will find their way into the average user's system.
Some may never appear in any useful form and will atrophy, as did some
original SCSI features like Extended Identify.
Before beginning coverage of "what's new in SCSI-2," it might be well
to list some of the things that aren't new. The silicon chips designed
for SCSI are still usable. No new features were introduced which obsolete
chips. The cause of silicon obsolescence has been rapid market shifts in
integrating functions to provide higher performance.
Similarly, initiators which were designed properly, according to SCSI
in 1986, will successfully support SCSI-2 peripherals. However, it should
be pointed out that not all the initiators sold over the last few years
behaved according to the standard, and they can be "blown away "by SCSI-2
targets.
The 1986 standard allows either initiators or targets to begin negotiation
for synchronous transfers, and requires that both initiators and targets
properly handle the sequence. A surprisingly large percentage of SCSI initiators
will fail if the target begins negotiation. This has not been as much of
a problem to date as it will become in the future, and you know as well
as I do, that these non-compliant initiators are going to blame the SCSI-2
targets for being "incompatible."
Quirks in the 1986 standard, like 4 bytes being transferred on Request
Sense, even if the requested length was zero have been corrected in
SCSI-2. Initiators which relied on this quirk instead of requesting 4 bytes
will get into trouble with a SCSI-2 target.
A sincere effort has been made to ensure that a 1986-compliant initiator
does not fail or have problems with a SCSI-2 target. If problems occur,
look for a non-compliant initiator before you blame the SCSI-2 standard.
After that little lecture, let us turn to the features you will find
in
SCSI-2 which include:
o Wide SCSI: SCSI may now transfer data at bus widths of 16 and 32 bits.
Commands, status, messages and arbitration are still 8 bits, and the
B-Cable has 68 pins for data bits. Cabling was a confusing issue in the
closing days of SCSI-2, because the first project of SCSI-3 was the definition
of a 16-bit wide P-Cable which supported 16-bit arbitration as well as
16-bit data transfers. Although SCSI-2 does not contain a definition of
the P-Cable, it is quite possible that within the year, the P-Cable will
be most popular non-SCSI-2 feature on SCSI-2 products. The market responds
to what it wants, not the arbitrary cutoffs of standards committees.
o Fast SCSI: A 10 MHz transfer rate for SCSI came out of a joint effort
with the IPI (Intelligent Peripheral Interface) committee in ASC X3T9.3.
Fast SCSI achieves 10 Megabytes/second on the A-Cable and with wider
data paths of 16- and 32-bits can rise to 20 Megabytes/second and even
40 Megabytes/second. However, by the time the market starts demanding 40
Megabytes/second it is likely that the effort to serialize the physical
interface for SCSI-3 will attract high-performance SCSI users to the Fiber
Channel.
A word of caution. At this time the fast parameters cannot be met by
the Single Ended electrical class, and is only suitable for Differential.
One of the goals in SCSI-3 is to identify the improvements needed to achieve
10 MHz operation with Single Ended components.
o Termination: The Single Ended electrical class depends on very tight
termination tolerances, but the passive 132 ohm termination defined
in 1986 is mismatched with the cable impedance (typically below 100 ohms).
Although not a problem at low speeds when only a few devices are connected,
reflections can cause errors when transfer rates increase and/or more devices
are added. In SCSI-2, an active terminator has been defined which lowers
termination to 110 ohms and is a major boost to system integrity.
o Bus Arbitration, Parity and the Identify Message were options of SCSI,
but are required in SCSI-2. All but the earliest and most primitive SCSI
implementations had these features anyway, so SCSI-2 only legitimizes the
de facto market choices. The Identify message has been enhanced to allow
the target to execute processes, so that commands can be issued to the
target and not just the LUNs.
o Connectors: The tab and receptacle microconnectors chosen for SCSI-2
are available from several sources. A smaller connector was seen as essential
for the shrinking form factor of disk drives and other peripherals. This
selection was one of the most argued over and contentious decisions made
during SCSI-2 development.
o Rotational Position Locking: A rose by any other name, this feature
defines synchronized spindles, so than an initiator can manage disk
targets which have their spindles locked in a known relative position to
each other.
Synchronized disks do not all have to be at Index, they can be set to
an offset in time relative to the master drive. By arraying banks of
synchronized disks, faster transfer rates can be achieved.
o Contingent Allegiance: This existed in SCSI-1, even though it was
not
defined, and is required to prevent the corruption of error sense data.
Targets in the Contingent Allegiance state reject all commands from
other initiators until the error status is cleared by the initiator that
received the Check Condition when the error occurred.
Deferred errors were a problem in the original SCSI but were not described.
A deferred error occurs in buffered systems when the target advises Good
Status when it accepts written data into a buffer. Some time later, if
anything goes wrong when the buffer contents are being written to the media,
you have a deferred error.
o Extended Contingent Allegiance (ECA): This extends the utility of
the
Contingent Allegiance state for an indefinite period during which the
initiator that received the error can perform advanced recovery algorithms.
o Asynchronous Event Notification (AEN): This function compensates for
a deficiency in the original SCSI which did not permit a target to advise
the initiator of asynchronous events such as a cartridge being loaded into
a tape drive.
o Mandatory Messages: The list of mandated messages has grown:
o Optional messages have been added to negotiate wide transfers and Tags
to support command queueing. A last-minute inclusion in SCSI-2 was the
ability to Terminate I/O and receive the residue information in Check Condition
status (so that only the incomplete part of the command need be re-started
by the initiator).
o Command Queueing: In SCSI-1, initiators were limited to one command
per LUN e.g. a disk drive. Now up to 256 commands can be outstanding to
one LUN.
The target is allowed to re-sequence the order of command execution
to optimize seek motions. Queued commands require Tag messages which follow
the Identify.
o Disk Cacheing: Two control bits are used in the CDB (Command descriptor
Block) to control whether the cache is accessed on a Read or Write command,
and some commands have been added to control pre-fetching and locking of
data into the cache. Users do not have to change their software to take
advantage of cacheing, however, as the Mode Select/Mode Sense Cache page
allows parameters to be set which optimize the algorithms used in the target
to maximize cache performance. Here is another area in which improvements
have already been proposed in SCSI-3, and will turn up in SCSI-2 products
shipping later this year.
o Sense Keys and Sense Codes have been formalized and extended. A subscript
byte to the Sense Code has been added to provide specifics on the type
of error being reported. Although of little value to error recovery, the
additional information about error causes is useful to the engineer who
has to analyze failures in the field, and can be used by host systems as
input to prognostic analysis to anticipate fault conditions.
o Commands: Many old commands have been reworked and several new commands
have been added.
o Pages: Some method had to be found to pass parameters between host
and target, and the technique used is known as pages. The concept was introduced
in CCS and has been expanded mightily in SCSI-2.
A number of new Common Commands have been added, and the opcode space
for 10-byte CDBs has been doubled.
o Change Definition allows a SCSI-2 initiator to instruct a SCSI-2 target
to stop executing according to the 1986 standard, and provide advanced
SCSI-2 features. Most SCSI-2 targets will power on and operate according
to the 1986 standard (so that there is no risk of "disturbing" the installed
initiators), and will only begin operating in SCSI-2 mode, offering access
to the advanced SCSI-2 capabilities, after being instructed to do so by
the initiator using the Change Definition command.
o The Mode Select and Mode Sense pages which describe parameters for
operation have been greatly expanded, from practically nothing in 1986
to hundreds of items in SCSI-2. Whenever you hear of something being described
as powerful and flexible tool, think complicated. Integrators are advised
to be judicious in their selection of the pages they decide to support.
o The Inquiry command now provides all sorts of interesting data about
the target and its LUNs. Some of this is fixed by the standard, but the
main benefit may be in the Vendor Unique data segregated into the special
designation of Vital Product Data, which can be used by integrators as
a tool to manage the system environment.
o Select Log and Sense Log have been added so that the initiator can
gather both historical (e.g. all Check Conditions) and statistical (e.g.
number of soft errors requiring ECC) data from the target.
o Diagnostic capabilities have been extended on the Read/Write Buffer
and Read/Write Long commands. The ways in which the target can manage bad
blocks in the user data space have been defined further and regulated to
reduce inconsistencies in the 1986 standard. A companion capability to
Read Defect Data permits the initiator to use a standard method to be advised
of drive defect lists.
o A new group of 12-byte command blocks has been defined for all optical
devices to support the large volume sizes and potentially large transfer
lengths. The Erase command has been added for rewritable optical disks
so that areas on the media can be pre-erased for subsequent recording.
Write Once disks need Media Scan, so that the user can find blank areas
on the media.
o New command sets have been added for Scanners, Medium Changers, and
CDROMs.
All of this technical detail can get boring, so how about some "goodies"
in SCSI-2 which benefit the common man and help the struggling engineer?
First, and probably the best feature in SCSI-2 is that the document has
been alphabetized. No longer do you have to embark on a hunt for the Read
command because you cannot remember the opcode.
In the 1986 standard, everything was in numeric sequence, and the only
engineers who could find things easily were the microprogrammers who
had memorized all the message and opcode tables. Now, ordinary people can
find the Read command because it is in alphabetic sequence. This reorganization
may sound like a small matter but it wasn't, it required a considerable
amount of effort on the part of the SCSI-2 editors. It was well worth it.
Another boon is the introduction for each device class of models which
describe the device class characteristics. The tape model was the most
needed, because various tape devices use the same acronym but with different
meanings or different acronyms for the same meaning.
The SCSI-2 tape model defines the terms used by SCSI-2, and how they
correspond to the acronyms of the different tapes. For example, on a 9-track
reel, End of Tape is a warning, and there is sufficient media beyond the
reflective spot to record more data and a trailer. Not so on a 1/4" tape
cartridge. End of Tape means out of media and no more data can be written.
This sort of difference in terms causes nightmares for standardization
efforts.
So there it is; a summary of what is in SCSI-2. It's not scary, although
it is daunting to imagine plowing through a 600-page document. Time for
a commercial here. The "SCSI Bench Reference" available from ENDL Publications
(408-867-6642), is a compaction of the standard. It takes the 10% of SCSI-2
which is constantly referenced by any implementor, and puts it in an easy-to-use
reference format in a small handbook. The author is Jeff Stai, one of the
earliest engineers to become involved with SCSI implementation, and a significant
contributor to the development of both the 1986 standard and SCSI-2.
SCSI-2 is not yet published as a standard, but it will be available
later this year. Until then, the latest revision can be purchased from
Global Engineering (800-854-7179).
Biography
Consultant and analyst I. Dal Allan is the founder of ENDL and publisher
of the ENDL Letter and the "SCSI Bench Reference." A pioneer and activist
in the development and use of standard interfaces, he is Vice Chairman
of ASC X3T9.2 (SCSI) and Chairman of the SCSI-2 Common Access Method Committee.
QUESTION: What
is the difference between SCSI-2 and SCSI-3?
ANSWER From: excerpts of postings by Jeff Stai
and others:
(Mohit K Goyall - goyall@utdallas.edu)
Are SCSI-3 hard drives and/or controllers
available yet?
Allegedly, Previous postings have said "I heard that SCSI-3 has been
standardized," but I haven't seen anything firm about it. I've seen controllers
advertised by JDR Microdevices and some cheap clones; the Quantum "Empire"
drives are also advertised as SCSI-3 by some mail order vendors. Seagate
and IBM call their fastest drives (probably comparable in speed to the
Quantums, if not faster) "Wide SCSI-2."
That's a misnomer. See below.
What is the difference between SCSI-3 and Fast & Wide SCSI-2?
Wide SCSI-2 required two cables to do 16 bit wide transfers. SCSI-3
defined a single cable, single REQ/ACK 16 bit, WIDE transfer. The reason
you are hearing 16-bit single cable being called SCSI-3 is that they CAN.
The fact that single cable 16-bit has been around for a while just shows
you how much the standardization process lags behind the real world.
SCSI-3 is really a family of standards. SCSI was broken up from a single
document into different layers and command sets. This was done to allow
for different physical transport layers (like fibre channel and SSA) to
be defined, and to allow for smaller "bite-sized" projects that maybe get
done a little faster ;-)
The family includes the following members with TLAs:
- SCSI-3 Parallel Interface (SPI): Defines the mechanical, timing, phases,
and electrical parameters of the parallel cable we all know and love. Some
of the electrical and cable parameters are tightened/improved over SCSI-2.
- SCSI-3 Interlock Protocol (SIP): Defines the messages and how the
phases are invoked. No real change from SCSI-2, except for some new messages.
- SCSI-3 Architectural Model (SAM): In a nutshell, defines a common
set of functions and services and definitions for how a physical transport
properly gets commands, data, and status exchanged between two devices,
complete with error handling and queueing.
- SCSI-3 Primary Commands (SPC): All of the commands executed by any
and all SCSI devices, like REQUEST SENSE and INQUIRY, etc.
=== QUESTION: After perusing the latest
issue of Computer Shopper, I came away with the impression that companies
are calling F&W SCSI-2 HD's SCSI-3. Is this an incorrect assumption,
or is F&W SCSI-2 known as SCSI-3?
Is this really mostly marketing hype?
Actually, there is something to that. TECHNICALLY, what is out there
is often a hybrid: SCSI-3 "SPI" silicon with some other hodgepodge of SCSI-3
proposals, all mixed in with SCSI-2 stuff.
An earlier posting said that the Quantum Empire ("SCSI-3") drives contain
some commands from the SCSI-3 command set, and Adaptec suggested a specific
setting on its 2940W controller to work properly with the drive.
I understand there are some drives with proposed SCSI-3 command features.
These are mostly in the MODE SELECT and in error codes, as I recall. Perhaps
someone who knows more about this could elaborate?
Note also that the major players (like DC Drives) don't have any "SCSI-3"
stuff advertised; only JDR and some cheap clones are promoting it.
Besides, Wide SCSI-2 has yet to really catch on (mostly because only
a few drives are fast enough to take advantage of it).
There is no "wide SCSI-2" because that would mean two cables. Single
cable wide SCSI has always been SCSI-3, it just took too d*** long to get
into a standard! :-)
Yes, the asynchronous transfer option waits for each byte to be transferred
before it is acknowledged. With synchronous protocol, the device sending
the data is allowed to get ahead of the device receiving the data by a
number of bytes (called the offset). The offset is negotiated between the
initiator and the target some time prior to the transfer beginning. The
synchronous protocol is considerably more efficient and therefore faster
than asynchronous.
I've seen a few comments about our 54C90 being faster than spec. While
I doubt the author was really complaining (I got twice as much as I paid
for - sure makes me mad ;) I'd like to explain the situation. Along the
way, I'll also show that asynchronous is faster on short cables, while
synchronous is faster on long cables. The cross-over point occurs somewhere
around six feet--assuming that you have our 53C90 family devices at both
ends of the cable. The reason has to do with the propagation delay of the
cable; the turn around time of the silicon; and the interlocked nature
of the asynchronous handshake.
1) We have measured propagation delays from various cables and found
an average of 1.7 nanoseconds per foot, which is roughly 5.25 ns per meter.
2) The turn-around time is the amount of time the SCSI chip takes to change
an output in response to an input. If REQ is an input then ACK is an output.
Or if ACK is an input then REQ is an output. Typical turn-around time for
the 53C90 is 40 nanoseconds.
3)The asynchronous transfer uses an interlocked
handshake where a device cannot do the next thing until it receives positive
acknowledgment that the other device received the last thing.
First REQ goes true /* driven by Target */
then ACK is permitted to go true /* driven by Initiator */
then REQ is permitted to go false
then ACK is permitted to go false
Thus we have four "edges" propagating down the cable plus 4 turn-around
delays. Asynchronous transfer requires 55 ns setup and no hold time (paragraph
in 5.1.5.1 in SCSI-1 or SCSI-2) which gives an upper speed limit around
18 MB/s. A detailed analysis (assuming 53C90 family) shows that the setup
time subtracts out. This is mostly because we are running at one-third
the max rate, but also because setup for the next byte can begin anytime
after ACK is received true or REQ is received false, depending on who is
receiving. You can either take my word for it or draw the waveforms yourself.
Thus, the asynchronous transfer reduces to:
note: cables longer than 6 meters require external differential transceivers
which add delay and degrade the performance even more than indicated here.
Our simulations say that under very best conditions (fast silicon, low
temperature, high voltage, zero length cable) we can expect more than 8
MB/s asynchronously. In the lab, I routinely measure 5 MB/s on 8 foot cables.
So, if you were writing the data manual for this, how would YOU spec it?
The framers of the SCSI spec threw in synchronous mode to boost the
performance on long cables. In synchronous mode, the sending device is
permitted to send the next byte without receiving acknowledgment that the
receiver actually received the last byte. Kind of a ship and pray method.
The acknowledgment is required to come back sometime, but we just don't
have to wait for it (handwave the offset stuff and the ending boundary
conditions). In this mode any external transceivers add a time shift, but
not a delay. So if you negotiate for 5 MB/s, you get 5MB/s regardless how
long the cable is and regardless whether you are single-ended or differential.
But you can't go faster than 5.5 MB/s, except in SCSI-2.
Synchronous mode does have a hold time (unlike asynch) but again, setup
and hold times subtract out. In SCSI-1 synchronous mode, the speed limit
comes from the combined ASSERTION PERIOD + NEGATION PERIOD which is 90ns
+ 90ns = 180ns = 5.5 MB/s. Our 53C90 family doesn't quite hit the max,
but we do guarentee 5.0 MB/s. In SCSI-2, anything above 5.0 MB/s is considered
to be FAST. Here the maximum transfer rate is explicitly limited to 100
ns or 10MB/s; you don't have to read between the lines to deduce it.
Interesting tid-bit: given a SCSI-2 FAST period of 100 ns and a cable
delay of 131 ns on a 25 meter cable, you can actually stack 1.31 bytes
in the 8-bit cable. In FAST and WIDE SCSI you can stack 5.24 bytes in this
copper FIFO.
ASPI stands for Advanced SCSI Programming Interface. It was developed
by Adaptec (and the "A" originally stood for Adaptec). It is a calling
convention and set of commands that can be used to send SCSI commands via
any SCSI host adapter that supports it. It is strictly for use with
machines running MSDOS, Windows( 3.1x, 95/98/NT/2000), Netware, or OS/2.
There is no UNIX version of ASPI. The error reporting and recovery mechanisms
are much more limited than in CAM, but ASPI gained much wider acceptance
because it was available earlier.
The ASPI subsystem is divided into layers:
ASPI Manager Driver (the layer closest to the host adapter)
ASPI peripheral Driver (the code which knows the details of the SCSI peripheral,
e.g. DISK, CD-ROM, scanner etc)
ASPI applications (utilities like SCSITool, or
CD Recording packages)
ASPI peripheral drivers are fairly portable and may handle many different
drives of the same type. These would be supplied by the peripheral manufacturers,
or in some cases in a general purpose utility package like Adaptec EZ-SCSI.
ASPI manager drivers are available from the manufacturers of most SCSI
host adapters.
FPT stands for Forced Perfect Termination. FPT is actually really simple,
I wish I had thought of it. What it does is use diode clamps to eliminate
over and undershoot. The "trick" is that instead of clamping to +5 and
GND they clamp to the output of two regulated voltages. This allows the
clamping diodes to turn on earlier and is therefore better at eliminating
overshoot and undershoot. The block diagram for a FPTed signal is below.
The resistor value is probably in the 110 Ohm range. The actual output
voltages of the regulators may not be exaclty as I have shown them but
ideally they are matched to the diode characteristics so that conduction
occurs when the signal voltage is greater than 3.0 V or less than 0.2 V.
The diagram shows the circuit for terminating one signal. In a complete
FPT there would be 36 diodes and 18 110 Ohm resistors plus the regulator
chips.
Using the values shown, transients would be clamped at 0.2V and 3.0V.
[Editor(GF)]:
Some errors in the above diagram were corrected as suggested by
An active terminator actually has one or more voltage regulators to
produce the termination voltage, rather than using resistor voltage dividers.
This is a passive terminator:
TERMPWR ------/\/\/\/------+------/\/\/\/----- GND
|
|
SCSI signal
Notice that the termination voltage varies with the voltage on the TERMPWR
line. One voltage divider (two resistors) is used for each SCSI signal.
An active terminator looks more like this (supply filter caps omitted):
2.85 Volt Regulator
+-----------+ +2.85V 110 Ohms
TERMPWR -----| in out |------+------/\/\/\/-------SCSI signal
| gnd | |
+-----------+ |
| +------/\/\/\/-------SCSI signal
| |
GND ---------------+ |
+------/\/\/\/-------SCSI signal
|
etc.
Assuming that the TERMPWR voltage doesn't drop below the desired termination
voltage (plus the regulator's minimum drop), the SCSI signals will always
be terminated to the correct voltage level.
Several vendors have started making SCSI active terminator chips, which
contain the regulator and the resistors including Dallas Semiconductor,
Unitrode Integrated Circuits and Motorola.
[Editor(GF): Another nice feature of active termination is that it can
be disabled by a single jumper instead of needing to unplug resistor arrays.]
Typical passive terminators (resistors) allow signals to fluctuate directly
in relation to the TERM Power Voltage. Usually terminating resistors will
suffice over short distances, like 2-3 feet, but for longer distances active
termination is a real advantage.
Active termination provide the following advantages:
- Helps reduce noise.
- A logic bit can be used to effectively disconnect the termination.
- Regulated termination voltage.
- SCSI-2 spec. recommends active termination on both ends of the scsi
bus.
- Improved resistance tolerances (from 1% to about 3%)
[Editor(GF):
- Reduces current drawn from TERMPWR line.
In FPT form:
- Provides signal overshoot/undershoot clamping on all signal lines.
]
If you have an Ohm-meter of one kind or another, measure the resistance
from the TERMPWR pin to an adjacent GROUND pin. Reverse the probes and
take another reading.
If the reading is about 30.5 Ohms, with the probes both ways, you have
a passive single-ended terminator.
If the reading is about 45 Ohms, with the probes both ways, you have
a passive differential terminator.
Active terminators should read much higher and give very different readings
with the probes interchanged.
Another method: (Suggested by Rico Tudor)
If you measure the resistance from one signal pin to another, a reading
of 264 Ohms indicates a passive terminator.
A reading of 220 Ohms indicates an active terminator. This will be
true for either 50 or 68 pin terminators.
If you measure the resistance from a signal pin to a GROUND pin on a
50 pin terminator, a reading of 143 Ohms indicates a passive terminator.
The value would be closer to 139 Ohms on a 68 pin passive terminator. A
reading of greater than 400 Ohms indicates an active terminator.
For those geeks who must know how these values were arrived at:
For passive terminators Signal to Signal formula: 1 / ((220 +
220) * (330 + 330) ) = 264 Ohms
Signal to Ground formula: 1 / ( (1/330) + ( 1/(220+((1/(N-1))
* 550) ) ) )= 153 Ohms (for N=18) or 145 (for N=27)
For active terminators Signal to Signal formula: 110 + 110 = 220 Ohms
Signal to Ground formula: It is not practical to guess what the
output circuit of a 2.85 Volt regulator might look like and attempt to
derive an exact formula for it. Actual measurements indicate that it will
generally be high resistance.
(Update - March 2000)
The following information is outdated but I'm leaving it here for now
just for historical purposes. My current opinion is that these cards are
totally obsolete and should be replaced. The only support for these cards
I know of is under Linux and FreeBSD.
Western Digital stopped producing WD7000 FASST2 cards some time in 1990.
Future Domain bought the rights to produce them. Future Domain was later
bought out by Adaptec and the boards are no longer produced. Columbia Data
Products Inc. of Altamonte Springs, Florida still provides driver support
for the card. Their SST IV driver package provides support for many types
of SCSI devices including disks, tapes, and CDROM. Also included in this
package is an ASPI manager driver (equivalent to the Adaptec ASPI4DOS.SYS).
I have personally tested this ASPI manager and it works with GNU tar w/ASPI
and the Corel CDROM driver, so most other ASPI stuff should work too. Versions
of SSTASPI.SYS prior to Oct 1993 do NOT work with the above mentioned programs
so be sure to check the file date. There are other useful programs in the
package as well. For instance I find the TAPEUTIL program very handy for
duplicating tapes. The price of this package is $99 or $85 as an upgrade
of a previous version.
A pre-requisite to run this software is that the adapter card must have
a BIOS ROM version of 3.36 or newer. I don't think cards manufactured before
1989 or so are compatible.
Columbia Data Products Inc.
1070 B Rainer Dr
Altamonte Springs, FL 32714 (407) 869-6700 (main number)
Subject: Western Digital 7000-Fasst SCSI Cards and CDP's SST software
Alan L. Welsh, President
Columbia Data Products, Inc.
We don't usually recommend that users purchase the upgrade for the 7000
software today. Development has ceased, Windows 95 is not supported except
in DOS mode, and today I would rather recommend a popular currently manufactured
Local-bus SCSI board and not an ISA 7000 board. However, there are still
some companies that we do support that have standardized on 7000s and need
to keep them in service for years to come. So please buy the software,
sell the board, use it as-is, or buy a new board.
HISTORY OF THE WD-7000 SCSI HOST ADAPTER AND COLUMBIA DATA PRODUCTS,
INC.
Starting in early 1987, Western Digital (WD) manufactured virtually
all of the 100,000+ 7000 SCSI boards, except for a few hundred that were
made by Future Domain. The first few thousand, known as 7000-ASC boards
went out with no software and only a ROMBIOS that was actually written
by John Sponger of WD. In the summer of 1987, Columbia Data Products (CDP)
completed and shipped its first ROMBIOS for the card that enabled it to
boot and operate in DOS. At that same time, CDP also completed a DOS ram-resident
driver, so that DOS would recognize and operate the card without the slowness
of the ROMBIOS, a DASD driver so that DOS could access additional drive
letters, and to break the (then) 32 meg barrier, and partitioning software
to perform the FDISK function for SCSI.
It was CDP's goal at that time to develop and provide SCSI software
that would enable: any SCSI host adapter, to run any SCSI peripheral, on
any operating system, in any PC-based bus. Since at that time WD had 80%
of the hard drive controller market, CDP chose WD as the most logical choice
to strategically market with, and so CDP supported their cards almost exclusively.
During that following year, CDP continued to develop the software for the
7000 host adapters, enabling it to run faster than any other board of its
time, including Adaptec's new 1540, whose hardware was actually faster.
In the fall of 1988, CDP exclusively licensed its SCSI software suite,
called SST to WD. The WD 7000-asc SCSI host adapter was renamed 7000-FASST.
WD was the first OEM to ship software with all SCSI boards distributed
as part of the package. CDP's SST software was well received, even though
SCSI was still a relatively small market. CDP was paid a royalty for each
card shipped and CDP provided complete software support and limited hardware
support throughout the world.
By 1991 CDP had developed support for all SCSI peripherals known, all
PC operating systems such as Unix, Xenix, Windows, Dos, Netware, and even
AIX, although never officially released, and a SCSI toolkit utility package.
All of the 7000-FASST's shipped had multiboot capability that allowed
all of these operating systems to simultaneously coexist on a single hard
drive so that one OS can be selectively booted each session.
CDP's exclusive was ending with WD, and CDP was porting the software
to 25 of the most popular SCSI host adapters. Unfortunately, most of software
had to be re-architected and rewritten to embrace not only all the new
adapters but also the new SCSI software standards such as CAM, LADDR, ASPI,
INT-4b, as well as CDP's own standard since 1987, SDLP. During the next
few years WD was losing a considerable amount of money and sold many of
their product lines, which included selling the SCSI board business to
Future Domain. Future Domain did very little sales of the 7000 as they
had competing product lines and didn't understand the value of a bus mastering
SCSI board. (Bus mastering gives the card the ability to move data to and
from the card and system memory directly without the CPU's involvement,
making it as fast as the peripherals driving it, even on an old slow 80286!)
The bus mastering 1542 product line from Adaptec is still being produced
today, very popular, and is based on the same basic design as the 7000.
From a pricing standpoint, the prices for this class of product has declined
less than 50% in ten years. This is only amazing if you compare the price
of 1MB of memory at $300 in 1987 to that of today.
CDP has continued to develop and support for the 7000-FASST continuously,
even though the board hasn't been manufactured for quite a number of years.
Our last major revision of our SST-IV software was done in late 1993,
although there have been some minor revisions since then. To enable CDP
to continue to develop software and support the board, CDP has been selling
upgrades to the large installed user base for years. Without this revenue,
development and support would have ceased long ago. There are no plans
to continue development at this time, as SCSI is moving from the ISA bus
to Local Bus. Although Window-95 development and support was considered,
the potential upgrade business wouldn't have covered the cost of development.
In 1994 CDP entered the server backup software market, shipping the
first version of Snapback in March of that year. Many of our customers
for years had been begging us to write our own backup software and were
complaining that "restoring" their servers sometimes took days with the
current backup products. For SCSI software development purposes only, CDP
had been backing up and restoring hard drives containing multiple operating
systems for years. CDP adapted and then rewrote this software in this first
release to provide the ability to backup and restore any hard drive that
contained any operating system, from DOS. CDP later wrote a device driver
in Netware, that could make the backup tape look, act and perform like
a hard drive from a Netware workstation. This enabled direct file retrieval
and use through Netware from the backup tape, making it appear to a workstation
to be just another drive letter. Since all the directories and FATs are
cached, the tape is almost as fast as a hard drive. Another feature, resize,
allows a Netware server's hard drive to be replaced with a larger one in
an hour instead of a day's labor.
At fall COMDEX 1996, CDP released its latest version, Snapback Live!
That backs up a live image of a Netware file server's hard drive, capturing
all open files in the process, without impacting system performance. Watch
your Computer magazine for Snapback reviews in 1997, as well as a version
for NT. Innovating backup software has now become CDP's new life--from
an innovative SCSI software company.
The IBM PC/AT BIOS Int 13h disk interface was specified in about 1986
when a large disk drive was about 60 MB. IBM decided that disks wouldn't
have more than 1024 cylinders and only allocated 10 bits for the CYL parameter
to the INT 13h interface. By 1989, this was already a problem. When vendors
began to support SCSI drives under INT 13h, they needed to come up with
a translation algorithm between the CYL, HEAD, SECT parameters of INT 13h
and the linear block numbers used by SCSI devices. Various vendors chose
to map the two such that each INT 13h "cylinder" contained 1 MB.
In other words they emulated a drive with 32 heads and 63 sectors per
track.
At the time, large drives were at about 300 MB, so this worked OK. Once
drives larger than 1024 MB arrived, a problem developed. They couldn't
provide cylinder values greater than 1023! Changing algorithms became necessary.
This is painful since any disk formatted with the old algorithm can't
be read using the new algorithm.
By the way, different vendors chose different mappings, so drives formatted
with one adapter can't necessarily be moved to a different one.
Adaptec's newer adapters (e.g. the 154xC and the 154xCF) provide a BIOS
control to select the old algorithm or the new one, and they also provide
BIOS PROMs for the 154xB that will use the new algorithm.
There is an absolute limit of 16 M sectors which means 8 GB assuming
512 byte sectors. Also DOS (actually the FAT 16 filesystem) only
allows 2 GB per partition.
The day when this presents another problem is not too far away (1995?)
Hopefully, we'll all be running more sophisticated O/Ses that bypass
this limitation by then.
If you still have problems after you're sure that you have all the ID
and termination and cable issues resolved, it's time to dig a little deeper
(Voltmeter and Oscilloscope required).
If you get your SCSI bus to the point where it basically works, but
it isn't reliable I have found that the gremlin can be the TERMPWR Voltage.
With your system fully powered up, and both terminators attached, measure
the TERMPWR Voltage at the far end of your bus. It needs to be between
4.25 and 5.25 Volts. Many vendors start with the system's +5 VDC and add
a regular silicon rectifier diode and fuse in series. Silicon rectifiers
have an inherent voltage drop of .6 to 1.0 Volts depending on the current
through them.
Schottky barrier rectifiers are much better for this application. I
always use a 1N5817 myself. If the diode on the host adapter is a 1N400x
type, change it to a 1N5817. If you add up the drop across the diode and
the fuse and 15 feet of ribbon cable and the connector contact resistances,
many times you'll find yourself below 4.0 Volts. When using passive terminators,
this can shift the signal threshold and decrease the signal to noise ratio
on the bus.
If you aren't able to get relief with these methods, sometimes you can
solve the problem by having several devices supply TERMPWR to the bus.
Sometimes the Voltage is high enough, but there is too much noise on
the TERMPWR line. This can cause really strange problems! If you can see
more than about 200 mV of noise on TERMPWR, add a .1 uF and 10 uF capacitor
from TERMPWR to one of the adjacent GROUND lines. You need to have the
bus as active as you can get it when measuring the noise. I have actually
seen over 1 Volt of noise in some severe cases.
Another way you can help to solve TERMPWR problems is to use active
terminators. These don't draw as much current from the TERMPWR source and
they also have a built in regulator, which can operate on lower voltage
than the standard passive terminators. The regulator also tends to reduce
the noise.
Dr Dobb's Journal March 1994 issue pg 154, has an article called "The Advanced
SCSI Programming Interface" by Brian Sawert. Example code in C and x86
assembly language is included. The code can be obtained via anonymous ftp
from: Dr Dobb's Journal
archive web site.
Target mode refers to the ability of some SCSI host adapters to respond
on the SCSI bus as if they were a SCSI target (device) instead of an initiator
(host) which is the usual behavior. Using target mode two hosts can communicate
with each other over the SCSI bus at high speeds.
Although most SCSI chips can be used in target mode, not all host adapters
support it. Here are some that do:
Adaptec 2940UW (http://www.adaptec.com/)
The documents that describe how target mode works for the 2940/2944
are called:
Designer Book
AIC-7880 SCSI Chip Specification
Adaptec TARGET mode firmware programming guide
(I don't think any of these is available anymore)
QUESTION: How
do I replace Macintosh internal HD and terminate the SCSI chain properly?
ANSWER From: Jie Yuan PhD (Jie.Yuan@UC.Edu)
The factory installed Macintosh internal HD should be terminated. Make
sure the terminator/resitor-package is installed in the drive before using
it. Most vendors will install the terminator for you if you tell them it
is for use in Macintosh as the system disk. Manufacturers usually have
toll free numbers for SCSI termination, ID, and such. If you don't already
have the terminator, they may send you one for free. BTW, Macintosh SCSI
chain starts at the system disk (ID=0), and ends at the control board (ID=7).
ID numbers from 1-6 should be used for any other devices on the chain.
Attaching a SCSI-1 device to a system with a SCSI-2 host adapter and
several SCSI-2 devices already attached will not hurt over-all performance
significantly unless it doesn't handle disconnect/reconnect well. This
assumes that the host adapter keeps track of protocol options separately
for each target device. Some people have the idea that attaching a SCSI-1
device to a SCSI-2 bus will cause the entire bus to run at SCSI-1 speeds.
This is not true.
Questions of this nature really cannot be answered in a useful way.
There are so many aspects and options to each of the SCSI standards, you
need to be much more specific about what devices and adapters you're interested
in connecting. Most of the time the best thing to do is just try it! Most
combinations will work, but if you're considering a purchase and looking
for a guarantee from "The Net", forget it.
The issue is further complicated by the fact that vendors like to latch
onto the latest acronyms before they even know what's involved. For example
SCSI3 is not approved yet, but vendors are already saying their devices
are SCSI3 compatible. Since there is no standards compliance testing organization,
they can pretty much say what they want.
If you buy a high end host adapter (probably called SCSI3 :-) ) from
a reputable vendor, and it has enough control over the various options
(like synch xfer rate 5,10,20,40 mega xfers/sec and the ability to disable
WIDE or FAST/Ultra negotiation), and you carefully think out what devices
you connect to it (all WIDE devices nearest the host adapter end of the
bus etc.), and you are careful to properly terminate not only both ends,
but both halves (upper byte and lower byte) of the bus, and none of the
older devices you might already have (like a Panasonic CDROM) do anything
stupid (like not handle the WIDE negotiation message without hanging) then
it will all work fine. :-)
Even though a host adapter may be called SCSI3 doesn't mean it can enable
or disable each optional feature, yet this is vital for supporting older
devices.
To make matters worse, you won't know which older devices do some of
the stupid things unless you know someone who's been bitten already. Your
best bet is to look for good deals on name brand devices and adapters and
before you buy, ask in comp.periphs.scsi whether anyone has tried the combination
you're considering. It's also important to buy from a well known vendor
with reasonable return policies.
If you're looking at buying a Vendorxyz spiffydisk which claims to be
SCSI-3 compatible and you have a Seagate ST-01 host adapter and you want
to know if anyone else has tried this combination, then that's exactly
what you should ask.
In general, most SCSI devices and adapters made less than 4 years apart
will probably work together, but without specific information about exactly
which devices there's no assurance of it. There's also the potential for
poor performance even if it does work.
Yes, you just need an appropriate adapter. Most WIDE devices use the
68 pin "P" connector so you need a 68 pin to 50 pin adapter. You do need
to make sure that both the upper byte and lower byte of the bus will be
properly terminated though. Some adapters provide Hi-9 terminators,
others do not. If the wiring adapter is placed right at the SCSI host adapter,
you can usually configure the host adapter's on-board terminators to only
terminate the high byte. You need to be clear on what type of connectors
are present where you want to do the conversion. You also need to plan
your bus so that there won't be any narrow cable between any of the WIDE
devices.
Certain host adapters with auto-termination make the assumption that
when the low byte is terminated the high byte is also. When using WIDE/narrow
adapters this assumption is not valid. Another purpose served by the hi-9
terminator is supplying pull-up current to the upper data lines which would
otherwise be left floating.
Special note for LVD drives:
It is recommended that if you connect a WIDE LVD drive to a narrow
bus that you use a 68 to 50 pin adapter which has high byte termination.
It may seem that the termination wouldn't be needed in this case because
the bus is narrow. However, the drive needs to have those signals "pulled
up" (logically negated), to avoid the floating signals from confusing it.
If for some reason you attach a WIDE device to a WIDE host adapter using
a narrow cable, you must be sure to disable WIDE negotiation in the host
adapter BIOS or the device will hang when it is accessed.
One further caveat is that if narrow devices are attached to a WIDE
adapter, the adapter's ID must be between 0 and 7 because narrow devices
would not be able to see it if the ID was any higher than 7.
Warning: Some 68 pin to 50 adapters have
TERMPWR wired incorrectly.
It seems that the manufacturers of many of these adapters (even ones
with a good reputation) have designed their adapters visually rather than
by signal description/function. I say this because I have taken a couple
apart and I can see where they went wrong. If you look at the layout of
a circuit board which makes the connections between a HD 68 pin and
a HD 50 pin you see a nice symetrical fan-like pattern, and for the most
part following this pattern gives you the correct wiring. HOWEVER; there
are 3 signals that must NOT follow the obvious pattern or TERMPWR can end
up shorted to GROUND. This is NOT a good thing. The pins in question are:
17,18 and 51 on the HD 68 connector. These are TERMPWR. If you follow
the obvious pattern:
- HD68 pin 17 connects to HD50 pin 12 (which is RESERVED in SCSI-2)
- HD68 pin 18 connects to HD50 pin 13 (which should be OPEN)
- HD68 pin 51 connects to HD50 pin 37 (which is RESERVED in SCSI-2)
To make things worse HD50 pins 12 and 37 were originally defined as
GROUND
in SCSI-1.
Also, the Pioneer DVD-U02 DVD drive neglected to leave pin 25 (which
turns into HD50 pin 13) open. Which also causes the shorted condition.
Unfortunately, most of these adapters are molded in plastic so that
you can't easily open it up and cut those connections. In order to fix
them you need to break off the pins in question on the HD68 connector.
Narrow SCSI devices can only use IDs 0 through 7. WIDE SCSI devices
on a SCSI-3 system with 68 pin P cables, can use IDs 0 through 15. It is
generally wise to reserve 0-7 for narrow devices though. SCSI-2 only specified
the use of IDs 0-7 even for WIDE devices, but SCSI-3 allows 0-15 for WIDE
devices. All devices on one bus must have unique IDs of course.
The arbitration priorities are as follows:
highest
ID 7
...
ID 0
ID 15
...
ID 8
ID 23
...
ID 16
ID 31
...
ID 24
lowest
(I doubt you'll ever see a system using WIDE 32 which is required for
use of IDs 16 thru 24)
A WIDE device that is set to ID 10 knows not to respond to selection
for ID 2 because the parity bit P1 (for bits 8-15) will not be set by the
initiator. During a selection of ID 10, the P parity bit (for bits 0-7)
will not be set by the initiator, but the P1 bit will be.
To use both WIDE and narrow devices on the same bus, the host adapter
must be set to ID 7 (or less) so that the narrow devices can talk to it.
QUESTION: What
is spindle-sync and why would I want it?
ANSWER From: Roger J. Hamlett (Roger@ttelmah.demon.co.uk)
It fundamentally affects just one aspect of performance, the 'latency'.
With a single drive, if you are waiting for a sector to 'arrive' round
a track, you have (on average) to wait for approximately one half the rotational
time of the drive for it to arrive. So you might arrive at the track just
as the sector has gone by, and have to wait one whole rotation at the worst,
or the sector might arrive just as you want it, and latency would be zero.
This average time, is the minimum latency achievable. There are two methods
of reducing this time. The first is to increase the rotational rate of
the drive. This is why for certain types of application a 7200RPM drive,
will still outperform a 5400RPM drive that has the same data rate off the
drive. The other method is to have multiple copies of the required data
on unsynchronized drives, and take whichever copy arrives first. This can
be done with mirrored drives, and gives a small improvement in the latency
time. However the 'down side' of multiple drives comes when we have to
wait for all the data parts to arrive. So (for instance) on a striped array,
if the drives are synchronized, the latency will remain the same as for
the single drives with both data 'parts' arriving together. However, if
the drives are unsynchronized, the 'total' latency goes up, to 33% 'worse'
than the single drive, as we now have to wait for both parts to arrive.
Similar 'extensions' take place with other RAID
configurations, unless the drives are synchronized. Basically, in RAID
arrays, the drives should be synchronized, _unless_ the total required
data can be assembled from a small fraction of the drives.
RAID 1, and RAID 1,0, are the most common configurations where synchronization
is NOT advised.
This description assumes an Adaptec host adapter, but other types should
involve about the same procedure.
Let me start from scratch and describe one by one all necessary steps:
Prepare a bootable MS-DOS floppy (SYS A: ) containing, in addition to the
system files, the FDISK.EXE and FORMAT.COM programs. (Preferably the ones
that came with your Win95 distribution). Make sure there isn't anything
in the AUTOEXEC.BAT or CONFIG.SYS files that could make trouble later.
Better still, delete these two files. Do not insert the floppy yet.
Reset your computer and enter the BIOS setup, (not the SCSI setup) and
make sure that the "disk type" is set to 'none' or 'not installed' or something
similar. Verify that the boot sequence is A: first.
Exit and reset
(If your host adapter is new, you can probably skip the next step, but
if you want to avoid mysteries later, it's not a bad idea to do it.)
Enter the SCSI setup (CTRL-A) and go to the setup menu. Press F6 to restore
all the default settings.
Exit and reset
Enter the SCSI setup (CTRL-A) and go to the utilities menu. Make sure you
see your disk in the list of devices, and the name and model look OK.
Select the proper disk and run the "Format"
Choose "Verify media" to build your confidence that the drive is really
working right.
If these two steps work ok, your disk and controller are fine and they
are communicating correctly. If not, you have a hardware problem. (check
cables?, terminators?, TERMPWR?, disk itself?)
(It is not necessary to wait for the verify function to finish, although
it is a good idea to do it with a new disk.)
Exit and reset.
Boot from the floppy this time. While the system is coming up, a message
on the screen will show up saying something like "your disk model C: 80H
BIOS Installed." This means that the SCSI host adapter recognized the disk,
and since there is not an IDE C: disk, it installed the necessary BIOS
functions to use the SCSI disk as 'C:' It does NOT mean that the C: drive
is ready for DOS/Windows. If you don't get that message check that the
SCSI disk is installed as device ID 0. (With newer host adapters you can
use IDs other than 0)
After getting the A:> prompt, run FDISK. Create a primary DOS partition.
(2 GB max except for Win 95 OSR2 w/FAT32). Make that partition active.
Exit and reboot from the floppy.
At this point you already have a C: drive, but you can not use it because
it has no file system. (Typing DIR C:, for example, will produce the error
message 'Invalid media type', different from the 'Invalid drive specification'
you got before)
To make a file system run FORMAT C: /S /U. The /S tells the format program
to copy the system files to C: at the end of the formatting. This will
make C a bootable disk. (Assuming the partition was made active above )
When the FORMAT program ends, you should be able to switch to C:, do a
DIR, etc.
Remove the floppy, reset and (hopefully) reboot from the hard disk.
Notes for mixing IDE and SCSI disks on the same system?
The IDE disk must be defined properly in the BIOS setup ("disk type= number"
or "autodetect" instead of "not installed" as above).
If you will only boot from the IDE disk, the SCSI disk doesn't need to
be made bootable. (Some modern BIOSes let you choose to boot from SCSI
even if an IDE disk is installed)
The BIOS in the SCSI controller will install a maximum of two disks. If
you have an IDE disk installed, the SCSI BIOS will still install the (first)
SCSI disk. If you have 2 IDE disks
You'll have to install SCSI drivers in the boot disk to access the SCSI
disk or disks. If you have a system with 4 SCSI disks (no IDE) the controller's
BIOS will install only the first two;
Again you'll have to install drivers to access the rest, etc.
Table of Contents
QUESTION: My
SCSI CDROM only works when Windows 95 is installed. How can I get Windows
95 installed? Is this a catch 22?
The retail version of Windows 95 is limited to 2 GB per partition by
the use of the FAT16 filesystem. Since you're getting more than 2 GB, you
must be using a FAT32 filesystem.
Using FAT32 with drives larger than 8 GB requires a host adapter that
supports the "INT 13 extensions". If your host adapter was built before
about 1996, you may not have this feature. For example Adaptec 2940W Host
adapters did not support this. Even the early 2940UW didn't have it. As
of BIOS ver. 1.2x the support is present. Check with your host adapter
manufacturer for an updated BIOS.
Default cluster size of 4k bytes for drives up to 8 GB.
Supports drives up to 2 Terrabytes (2048 GB).
Will only install on drives > 512 MB.
Can use the "backup" copy of the FAT if needed.
Is ONLY accessible from Windows 95 OSR2. (Not supported by Windows NT)
CDFS (ISO-9660) enhancements.
Drive Power Management.
120 MB floptical support.
The mini-port driver for the Adaptec 2940xx
(\windows\system\iosubsys\aic78xx.mpd) is updated. In the retail version
of Windows 95 there are problems with the Microsoft supplied driver. If
the above mentioned file is older than April '96, you need a new one. The
updated driver is also available from http://www.adaptec.com/.
Each manufacturer chooses their own algorithm for converting cylinder,
head and sector to a SCSI logical block number. If you run into this, you
need to back up your system to tape or CD-R using the old host adapter,
switch host adapters, Low Level Format (LLF)the
disk (using the host adapter's BIOS), re-partition (using FDISK), and re-initialize
the filesystem (using FORMAT), then restore all the data from the backup
media.
Caveat: The following description assumes the use of Microsoft's FDISK.
The use of tools like Linux fdisk or Partition Magic changes a lot of the
rules.)
Microsoft uses the following strange algorithm to map drive letters
to disk partitions:
Look at the partition tables on BOTH PHYSICAL DISKS.
First PRIMARY partition becomes Drive C:
If there is a second PRIMARY partition it becomes Drive D:
If there are no more PRIMARY partitions, look for EXTENDED partitions.
The first logical drive in the first EXTENDED partition becomes drive
E:, the next logical drive in that EXTENDED partition becomes F: etc.
If there is another EXTENDED partition, the first logical drive in it
becomes drive G:, the next logical drive in it becomes drive H: etc.
Then, as device drivers are loaded, any disk drives they support will
be assigned consecutive drive letters. CDROMs and other "Network drives"
can be assigned specific drive letters if desired, leaving holes in the
lettering scheme.
Under MSDOS, Win 3.x and Windows 95 this behavior can't be changed.
Under Windows NT all drive letters can be re-mapped to whatever you want.
If you don't want D: on your second disk, don't create a PRIMARY partition
on it!
An example of this mapping which often confuses newbies:
If we're talking about USB 1.0 or 1.1 devices, then absolutely not!
USB 1.0 and 1.1 ports, are designed to connect miscellaneous low
speed peripherals external to a PC. It operates at 12 Mbits/sec.. It will
handle things like keyboards, mice, modems, PDAs, digital cameras, scanners,
printers etc. Some low to medium performance CD recorders also have USB
interfaces. It is NOT intended for general purpose mass storage devices
and is NOT a serious replacement for IDE or SCSI.
USB 2.0 is just starting to appear in November 2000. USB 2.0 is supposed
to be able to run at 480 Mbits/sec. If that pans out, it may be practical
to put storage devices on it. Even though that's still not as fast as parallel
SCSI's 160 MB/sec (1280 Mbits/sec.) or soon to come 320 MB/sec, it could
cut into parallel SCSI's territory, just as IDE has.
I think USB 2.0 would be more of a threat to IEEE-1394 however.
USB and IEEE-1394 both have the advantage that termination is fixed
and therefore simple. This can be done because all connections are point
to point, not daisy chained like parallel SCSI. This will be attractive
to many of the less technical users.
IEEE-1394 devices are getting to be much more available, so it's going
to be a race to see whether USB2 or IEEE-1394 garners the biggest share
of the low end I/O market.
IEEE-1394 is a 100/200/400 Mbit/sec. serial protocol. Firewire is a
trademark of Apple Computer for an early version of this protocol. There
is a standard (IEEE-1394) that describes the serial interface from a hardware
standpoint. There are other standards that describe the software protocol
that is used to transfer data over this interface. SCSI-3 has a section
(SBP) that describes one protocol.
It is becoming popular for interfacing computers to video cameras for
frame grabbing and editing. Even if it starts to catch on as a storage
interface, it will still be SCSI. People tend to think of SCSI as meaning
only the current parallel SCSI interfaces (Single-ended, Differential,
and LVD and the WIDE and NARROW variations of these.) In SCSI-3 all Hell
breaks loose in terms of how many options there are (Parallel(SE, HVD,
LVD), Firewire, Fibre Channel(copper or fibre), SSA)!
The serial interfaces hold a lot of promise for making the interconnection
of storage devices much simpler, and increasing the distance they can be
from the host. When the cost of these interfaces comes down, they may well
replace the parallel buses we currently use, but it will still be SCSI.
I think it's possible that IEEE-1394 storage devices will replace IDE devices
in mass market PCs in the future (probably not before 2003 or so though).
Probably the most welcome feature of IEEE-1394 is the fact that termination
is fixed and the user doesn't need to think about it.
Each platter in a disk drive is organized as tracks and sectors. Each
sector contains header and trailer information as well as error detection
(CRC) data in addition to the actual user data field.
When a disk is manufactured the platters are blank (no sector layout).
Before shipping, a special command (usually not documented) is issued to
the drive to cause it to lay down the sector headers, blank data fields
and good CRC. Also many data patterns may be written to each sector to
check for media errors. Any sectors with errors are put into the "manufacturer's
defect list" and the drive remembers not to use those sectors in the future.
Later, after the drive is shipped, a user may decide to "Low Level Format"
the drive if he is having problems, or wants to start with a "clean slate".
This is done using the SCSI FORMAT command via a special utility usually
supplied by the host adapter manufacturer (usually in the on-board BIOS).
Some side effects of doing a LLF:
The logical block size and any other saved parameters that are set using
MODE SELECT will remain the same as they were last set (i.e. they will
NOT return to default values). This can be over-ridden with command option
bits.
The data fields of the sectors will be set to the manufacturer's default
value (usually 00 but not always).
Any bad sectors that were mapped out using RE-ASSIGN BLOCK commands will
be available for use again. (i.e. the "grown defect list" is cleared).
This can be over-ridden with command option bits.
If a power failure occurs while a LLF is in progress, the drive may be
left in an unusable state, requiring return to the manufacturer for repair.
It is safest to do this on a system with a UPS.
Usually it is a good idea to LLF a drive when it is installed and then
verify (read each sector using a special utility) it. From then on you
shouldn't need to LLF it again. A good verify utility will offer the option
of re-assigning any bad blocks that are found. These will then be placed
in the drive's "grown defect list". The only way to recover blocks that
are mistakenly added to the grown defect list is to issue FORMAT UNIT to
the drive.
LLF is NOT to be confused with running the MSDOS/Windows utilities called
FDISK or FORMAT. FDISK causes a "partition table" to be created which logically
divides up a disk for use by multiple filesystems and/or Operating Systems.
FORMAT causes a FAT16 filesystem to be initialized in an existing partition.
FORMAT is equivalent to the UNIX command mkfs (Make filesystem). FORMAT
also reads the entire partition and marks any bad sectors found as unusable
in the File Allocation Table. This does NOT cause the drive to add them
to the drive's "grown defect list", but does prevent DOS/Windows from using
them.
I am starting to hear "I see UDMA drives being advertised as 33 or
66 MB/sec, how come my brand new Ultra-WIDE SCSI drive can't even do 20
MB/sec.. SCSI is a bunch of hype". My response is "No, marketing people
are a bunch of liars (or idiots, take your pick)!". Don't blindly accept
what you see in ads. The UDMA drives won't run at 33 MB/sec. in any real
sense either!
There is a common mis-conception that because Fast20 - WIDE is specified
at 40 MB/sec., that your drives will benchmark at that speed. People need
to understand the difference between "bus bandwidth" and "drive performance".
Bus bandwidth is the maximum speed that data can be moved across the
bus.
Drive performance is made up of many parameters; Rotational latency,
data clock rate, seek time,
cache efficiency and other factors.
The fastest disk drives (either SCSI or IDE) made in 1998 can only
transfer 20 MB/sec. even after they
have found the portion of data they need to send.
This is because the data is only moving under the heads
at about 160 Mbits/sec.
As drives start to spin their media faster and the bandwidth of read/write
heads gets higher, this number increases. Current drives can spin at 10,000
RPM. The next generation will spin at 14,400 RPM.
This will probably move the maximum transfer rate for a single drive
to about 28 MB/sec.
As you can see, there is a considerable difference between the drive
speed and the bus speed.
You ask; "Why should I have a bus that's so much faster than the drive?"
The answer is so that you can support multiple drives without slowing any
of them down.
In the example we're discussing here, a Fast 20 - WIDE bus can support
two 20 MB/sec drives before it becomes the bottleneck. This is why Fast40
- WIDE (Ultra2W or U2W) was developed. Servers and other high performance
systems need to handle more than two disks simultaneously. U2W is rated
at 80 MB/sec., so it can support four 20 MB/sec. disks before it becomes
the bottleneck. Later in 1999, Ultra3, or Fast-80, or a subset called Ultra160/m,
host adapters will become available which will allow supporting up to eight
20 MB/sec. drives or five 28 MB/sec drives. At that point the PCI bus becomes
the bottleneck.
By the way, you'll need a 66 MHz (or 64 bit) PCI bus to handle Ultra3/Ultra160
host adapters, since 33 MHz, 32 bit PCI can only transfer 133 MB/sec.
Well, not exactly. It's a matter of definitions.
Marketing people like to use the prefix Mega to mean 1,000,000 and
Giga to mean 1,000,000,000.
Computer engineers define Mega to mean 1,048,576, and Giga to mean
1,073,741,824.
The reason engineers use these strange looking numbers is because they
are powers of 2.
(2 to the 20th and 2 to the 30th)
The ad you read when you bought your disk was written by a marketing
person. The
operating system on your computer was written by an engineer. In engineering
terms,
your 9,100,000,000 byte disk is about 8.5 GB.
At first glance the SCSI protocol may seem rather verbose with 6, 10
or 12 byte commands being sent to read a block of data. Let's look
at a WORST CASE example:
Target sends 512 bytes of data using U2W synchronous xfer mode(6400 ns)
Target enters STATUS phase
Target sends STATUS byte (1 byte @asynch. = 800 ns)
Total transfer time = 24.6 us. Of that time, 18.2 us was due to
the protocol. This comes out to 74% overhead!
Fortunately, in the real world, multiple blocks are read together,
which brings the overhead way down.
If asynch protocol was used for the data phase, this would only be 4.2%
overhead! The problem is that the synchronous speeds get faster and faster,
but synchronous is not used to transfer the command bytes and many of the
delays are set by physical parameters of the bus (length, capacitance etc).
I see a total of 16 extra bytes that were sent in order to read those
512 bytes of data. As a percentage 16/512 is only about 3.1%.
This is for the WORST CASE with the host only asking for 1 block and
using a 12 byte command on a bus with only 1 drive active. In a more typical
case, the host would ask for many blocks to be read together and use a
10 byte command. More importantly, the bus would have several drives active
and the commands and messages would be transferred during the bus idle
times while drives were disconnected doing their seeks.
Low Voltage Differential is a new hardware bus driver type for SCSI-3.
It first becomes important
with Fast-40 (Ultra2) devices. If single ended (S.E.) bus drivers were
used with Fast-40, the bus length would
be limited to about .75 meters! Since this was clearly un-acceptable,
and the older High Voltage Differential (HVD) interface adds too much cost to a system, ANSI defined a new
form of differential interface
that is less expensive to implement because the bus driver logic dissipates
little enough power that
it can be included in LSI chips. They also wanted to make sure they
avoided the confusion caused by
HVD (HVD and S.E. devices cannot co-exist on a bus), so they specified
that if an LVD device is designed properly,
it can switch to S.E. mode and operate with S.E. devices on the same
bus
segment.
Another difference worth noting is that LVD devices do not contain
on-board terminators. You need
to attach an LVD terminator to the end of the cable instead of using
a device to terminate the bus
as was commonly done with S.E. SCSI. The big advantage to LVD is that
you can have a high speed
SCSI bus up to 12 meters in length!
Before you toss that "dead" drive, here are a few things to try:
Substitue another power supply. Maybe it's not getting power.
Check the cable connection. Try another connector.
Re-check your terminators. Have you added a device lately?
If you have a VERIFY utility (such as in the Adaptec SCSI Select BIOS),
run it. Perhaps only certain blocks have gone bad. The verify utility should
be able to re-assign those blocks to good areas of the disk. That still
leaves holes in your files where blank sectors have been substituted though.
If you have a utility that can tell you what files those block numbers
were in, you can just copy over those files. Even if the disk is too damaged
to read the disk media successfully, the verify utility may provide some
error messages or SENSE DATA that will
provide a clue to what's wrong with the drive.
I hope it didn't have any important data on it! (You have a backup of it
anyway right? Oh too bad...)
Is it under warranty? Check the serial number on the mfr web site. If it's
under warranty, contact the mfr for an RMA number and send it back. Don't
violate the warranty by tinkering any further.
No warranty huh? If the drive won't spin up, sometimes it's due to "sticktion".
This means that the heads are "stuck" to the media by vacuum. One
method of trying to un-stick the heads is to try twisting the drive in
the plane of the disk platters with a quick wrist twisting action. If that
still doesn't do it, as a last resort, giving the drive a sharp rap
with a screwdriver handle will sometimes free the heads. At this point
it's worth a shot (so to speak). If you do succeed in getting the drive
spinning again, do NOT turn it off again until you get the data on it transferred
to another drive. The sticktion problem tends to be chronic so plan on
replacing the drive as soon as possible.
If the manufacturer has firmware for it on their website, try re-flashing
the drive's firmware.
If you have another identical "dead" drive lying around, try swapping the
controller card from it onto the drive in question. Perhaps you can make
one good one out of the two bad ones. This only works if the drives really
are identical.
If it still isn't working, you have a nice new paper weight! Or, for a
more educational experience, you can take it apart and see first hand what
those platters look like.
Additional information about what
SENSE DATA can tell you (from Folkert Rienstra):
SCSI devices provide information about their condition and any errors
that have occurred during the previous command execution.
Devices return this information in response to a REQUEST SENSE command.
Many device drivers simply throw this information away making it difficult
to analyze problems that occur during normal operation. If you can reproduce
the problem using smarter software that will issue a REQUEST SENSE command
and interpret the data for you, a device can often tell you what is wrong
with it.
What do you need:
1. A drive exerciser also known as a CSO (Customer Simulated Operations)
program that will report the error sense information.
2. A list of SCSI errors comprised of Sense Key, Additional Sense Code
(ASC) and Additional Sense Code Qualifier (ASCQ).
Or:
2. A program that translates those codes into descriptive information.
In the first category fall codeupdt from IBM and SCSI Workbench from
Western Digital. They both contain a drive exerciser.
SCSIBench, the SCSI benchmark program from Adaptec is a little exerciser
in it's own right: If the drive is not completely up to scratch it will
complain through Sense information.
* There is also SCSITool from Bart Lagerweij which is currently under
construction (Apr 2000) that has a lot of sense codes built in.
* And then there is SMARTMon from SANTOOLS (David A. Lethe) that will
show you not only translated Sense Error data on Inquiry but also accumulated
Sense Log data.
That is, when your drive is "supported" by SMARTMon. SMARTMon does
not have a drive exerciser.
(A few words of caution: Caching parameters in Device Properties MAY
crash or hang your system. Also, adding alerts to 'Alerts|Maintain rulesets
.... for statistical alerts' can result in a hung system too. David
is looking into those at the moment).
In the second category falls SCSIcode from Adaptec. This is a little
DOS program (that can run in a DOS box) that accepts the Sense Key
and the Additional Sense Code and translates those into the appropriate
error descriptions.
That's a very good question! I haven't done a thorough
study to determine how they all do it, but the ones I've looked at sense
a ground connection on certain pins. This may work in many instances, but
it's certainly not foolproof. For example many people connect scanners,
or ZIP drives that have (may their little metal souls be damned) 25 pin
connectors, to the end of the bus. What happens to all those ground connections
now? Who knows! Another problem comes in when 68 pin buses are adapted
down to 50 pins. Same problem. Another problem is if the host adapter is
in the middle of the bus. It might be able to sense whether there is another
terminator, but how can it know if there are too many?
In my opinion, the only reliable ways to sense whether the bus is properly
terminated is by looking and checking manually, or with a Time Domain Reflectometer
and I don't think they'll be putting those onto SCSI host adapters any
time soon (but it's not impossible).
Certain host adapters with auto-termination make the assumption that
when the low byte is terminated the high byte is also. This isn't always
a good assumption, especially if 68 pin to 50 pin adapters are in use.
The bottom line is that you shouldn't depend on auto-termination to
do the right thing. Set the termination manually!
QUESTION: Can
I flash update a new BIOS on my OEM Adaptec host adapter?
ANSWER From: Folkert Rienstra Date: March, 2000 (updated April, 2000)
To know that, you have to know the difference between a product
made by an OEM and a product intended for delivery to an OEM (vs the retail
product).
The first one is the OEM (original equipment manufacturer) himself
(e.g. a card maker) supplying a product that incorporates another manufacturer's
product (e.g. the chip) and sells it under his own name.
The second one is a product intended for use by an OEM where the OEM
(e.g. a PC maker) will use it as a part in his product. Adaptec plays both
roles. It is a chip manufacturer and it also is a card manufacturer. To
complicate things it manufactures cards under its own brand name, identified
as AHA-series adapters to be sold to the public, the so called retail products,
and cards under the AIC-xxxx chipname umbrella, these carry different deviceIDs.
(I am not sure if these were sold to OEMs or as 'Adaptec on the cheap'
retail products).
To complicate things further still, they produce cards under the Adaptec
brandname for use by OEMs. Some of these are recognized by the special
'S' BIOS. It is possible that you can buy these as an OEM version, although
Adaptec never intended for you to buy it, unless you want yourself to be
called an OEM, in which case you would need to deal with Adaptec yourself,
not through your retailer (and supply you own tech. support).
And to complicate things still further they also produce cards under
the Adaptec brand name that identify under the AIC-xxxx chip name umbrella,
although the BIOS may say something different (some 290x and 2930-x cards).
I think that those are intended to come bundled with other products.
Don't take the previous information as fact, it is just my observation.
As to warranty and service, I think that Adaptec will offer support
only for their retail products, which they may track through the serial
number or their TSID number scheme. Of course, they can not prevent you
from downloading a BIOS image for your AHA- or ASC-branded, OEM intended,
card that is physically indistinguishable from the retail product.
Is there a solution for (made by) OEM cards or inboard SCSI solutions?
Yes there is, but it is not without risk and is not for the faint of
heart:
When you have an OEM card or motherboard SCSI solution that has the
"different from AHA branded products" PnP deviceID, you may still have
a possibility to convert an Adaptec sourced retail card BIOS for use on
your card or inboard solution. There are about 5 or 6 places in a ROM image
where the PnP deviceID is stored. When a PCI BIOS extension starts, it
uses those device IDs to find and check against the card/SCSI chipset.
If that ID is not found it does not load. Change the deviceIDs in the ROM
image to the ID used for your card and you are on your way.
There is one small problem however: Adaptec BIOSes are compressed BIOSes
headed by a decompression routine. You will have to decompress the BIOS
before you can edit it, and compress it afterwards, then paste it behind
the decompression header again. Your ROM image is now ready. If you have
a problem understanding what is written here (it involves the use of LHARC
and a binary editor looking for xx-lh5- and hex IDs) don't even try
it.
An example:
You have a AIC-7880 based card identified as "Adaptec AIC-7880 PCI
SCSI Controller" the device ID is 8078(h). Look it up in the driver inf
file like Windows SCSI.INF or AIC78xx.INF that comes with the drivers.
Right behind that you find "Adaptec AHA-2940U/AHA-2940UW PCI SCSI Controller"
the device ID is 8178(h). You get the 2940UW bios (the file that ends in
.ROM) and you replace all instances of 7881(h) in the BIOS header and the
decompressed bios with 7880(h). Reassemble the ROM image and you're done.
The BIOS image can now be flashed into the card or Motherboard. For motherboard
solutions the decompression header may be absent because it is already
part of a compressed motherboard BIOS, and the name of the section may
not be obvious (e.g. the SYMBIOS BIOS in an AWARD BIOS goes under the name
of PCI32.ROM). There may be other sections that need to stay at their fixed
locations, such as the AWARD decompression BIOS @ 1B000 and the AWARD
bootblock BIOS @ 1E000.
* Some of this also applies to the SYMBIOS BIOS included in AWARD sourced
BIOSes.
Notes from the [Editor(GF)]:
Some people have told me that if you get your Adaptec card into an
unusable state when trying to re-flash the BIOS, you may be able to recover
it using an older version of the FLASH.EXE utility. Try the following links
to get older versions:
QUESTION: Although
the Adaptec BIOS identifies my drives, I cannot access my drives under
DOS. What am I doing wrong?
ANSWER From: Folkert Rienstra Date: April, 2000
In order to access your drives under DOS they need to be enabled
in the SCSISelect BIOS setup(CTRL-A during boot). The fact that you can
see them at startup does not mean they are enabled. The BIOS does a device
scan and shows any device it finds, but to be enabled for DOS access, the
device needs to be "Included in BIOS Scan".
Devices that are enabled for BIOS control are identified with an additional
"- Hard Disk n" at the end of the line.
QUESTION: Why
are my 80MB/s Ultra2/LVD drives only listed as 40MB/s [SE] by my OS?
ANSWER From: Dana Lacoste Date: April, 2001
Almost all LVD drives are designed to be able to be used on a Single
Ended bus if desired. In this case, the drive switches to S.E. mode. The
drive determines which type of bus it's on based on the voltage present
on the DIFFSENSE signal. If even one S.E. device is present on an otherwise
LVD bus segment, all devices
will run in S.E. mode. Make sure you have only LVD/SE terminators instead
of merely Active/SE terminators (LVD/SE terminators are also available
which will indicate whether they are operating in LVD or SE mode).
In general when new SCSI protocols are designed they are compatible
with most of the previous protocols. This case is no exception. An Ultra3
drive attached to an Ultra2 host adapter will simply operate in Ultra2
LVD mode. If you connect that same Ultra3 drive to a SCSI-2 host adapter
like an Adaptec 1540cf, it will operate in Fast-10 Single Ended mode. Essentially
the host adapter and drive will negotiate for the best speed that they
both have in common.
PIO stands for Programmed (or Polled) Input/Output. This means
that the CPU is used to read and write data directly to and from the host
adapter chips. This is typically only used on low cost host adapter cards
because it ties up the CPU during I/O which makes multi-tasking work poorly.
DMA, or Direct Memory Access means exactly that. Special circuitry
is included either on the motherboard, or the host adapter card itself,
that can move data between system memory and the host adapter, with the
CPU only performing a simple initial setup of the transfer. There are two
distinct types of DMA circuitry used in PCs, third-party DMA and Bus Mastering
DMA. Third-party DMA uses chips built into all PC/AT compatible motherboards
to transfer the data. Bus Mastering DMA uses circuitry on the host adapter
card itself to take control of the bus and transfer the data. PCI host
adapters all use Bus Mastering DMA. This is the most efficient of the three
data transfer methods and consequently also the most expensive. Using DMA
frees the CPU from the data movement task and interleaves data transfers
into bus cycles that the CPU isn't using. This makes multi-tasking work
very smoothly which is what SCSI is all about!
Another term related to DMA is "scatter/gather". This refers to the
ability to perform the DMA transfer to/from a collection of separate memory
blocks or pages. This is vitally important in virtual memory operating
systems which keep virtual memory addresses contiguous but scatter the
data throughout physical memory pages. Since DMA uses physical addresses
to do the transfer, the DMA chips need to be able to accept a "linked list"
of physical addresses and transfer sizes rather than simply one address
and size. The term "scatter/gather" refers to what happens to the data
during the DMA operation. For READs from the device, the sequence of bytes
from the device are "scattered" onto discontiguous physical pages of memory.
During WRITEs to the device, data is "gathered" from the various physical
pages and marshalled into a sequence of bytes to transfer to the device.
In my opinion, if you're going to bother using SCSI, get the full advantage
and buy a PCI Bus Mastering host adapter.
A SCSI Host Bus Adapter (sometimes called an HBA) is the heart
of a SCSI subsystem. As the name implies, it connects the system's I/O
bus (PCI or ISA) to the SCSI bus. You need to give some thought to what
SCSI devices you will be connecting to your system before choosing one.
There is a large variety to choose from. They range from really low end
PIO
ISA cards that are included with SCSI scanners, CD-RW drives, etc, to dual
channel, Ultra160, 64 bit Bus Mastering PCI cards
costing up to $400 or more.
If you only intend to connect low performance devices such as a scanner
to the system, then a low end HBA is probably all you need.
But, if you want to connect SCSI hard disks, you'll probably want to
get the best card you can afford. If you will have disks and assorted other
slower devices, you may even want to get a dual channel card that will
allow you to isolate the slower devices onto their own bus to keep the
disks performing optimally.
Using an ISA card in a PCI capable system can cause really poor performance.
PCI motherboards often implement the ISA slots in such a way that they
are much slower than ISA slots on ISA only motherboards. There is often
a temptation to use an old ISA card that came with your scanner, or CD-RW
drive. Please resist this urge. These cards rarely have proper drivers
available for other devices, plus they can degrade the performance of the
entire system which defeats the whole purpose of using SCSI in the first
place!
Another factor to consider is the type of support you require. If you
really know a lot about installing and configuring PC option cards, you
may want to save a few bucks and get an "OEM" card. But, if you aren't
a real expert on this, you'd better stick to a "kit" packaged card that
comes with manufacturer's technical support and the required cables, drivers
etc.
Also, you should decide what operating systems you will be running
and make sure they support the specific card you are considering. Also,
check the manufacturer's web site to see if they provide driver updates
on a regular basis. You will find that having updated drivers readily available
makes the difference between enjoying and hating your PC.
To be thorough, you should also read this
article about determining the performance that will result from a particular
combination of devices. Running through these calculations may cause you
to realize that even though the SCSI protocol allows each device to run
at its highest speed, having slower devices mixed with your high speed
devices on the same bus, can eat up the bandwidth of even a high performance
host adapter.
When you mix SCSI devices that have different levels of performance
on the same bus it can be difficult to guess what the overall performance
of the bus will be. You may even find that you run out of bus bandwidth
with fewer devices than you expected.
Here are some formulas I worked out, that at least in theory should
come close to telling you what speed each device will perform at, and what
percentage of the available bus bandwidth you'll be using with all of the
specified devices running flat out.
If all the devices on the bus run at the same speed and that speed is
also the max. speed of the host adapter, you can easily estimate how it
will all work. For example, if you connect three Ultra2WIDE disks that
are each specified to deliver 25 MB/sec sustained, to a Ultra2WIDE host
adapter card, you can figure that all three drives will be able to run
at their maximum performance and most of the host adapter's bandwidth will
be utilized (3 * 25 = 75 MB/sec on a 80 MB/sec host adapter which amounts
to 93.75% utilization).
When you connect two Ultra drives rated at 15 MB/sec sustained, and
a Fast-10, 20x CD-ROM rated at 3 MB/sec sustained, to a Ultra2 host adapter,
what will be the performance of that combination?
You might be tempted to say that the two 15 MB/sec disks add up to 30
MB/sec and the CD-ROM's 3 MB/sec will bring it up to 33 MB/sec on the bus,
which is less than half of the 80 MB/sec the host adapter is specified
for.
However, this would not be even close to reality!
The real answer is that the bus will be 180% utilized, the two disks
will each benchmark at around 8.34 MB/sec and the CD-ROM at around 1.67
MB/sec!
Before we can get real answers, we need some real information:
First, you need the device specifications for all of the devices you
will have connected. The two parameters you need are:
The device's max. burst transfer rate (usually 10, 20, 40, or 80 MB/sec).
e.g. a Fast-20 WIDE disk would have a burst rate of 40 MB/sec.
The device's max. sustained transfer rate. This is the rate that data actually
comes off the medium at. This can be from 150 KB/sec for a 1x CDROM up
to about 35 MB/sec for a 15,000 RPM hard disk.
These are usually available from the manufacturer's web site.
Next, we assume that the host adapter is capable of operating at the
burst rate of the fastest device that will be attached.
Lastly, we assume that a test utility is being used that causes all
attached devices to be accessed continually. This means that the results
will be a "worst case" scenario but may actually reflect reality for very
heavily loaded servers.
Given the above information, we can estimate the utilization of the
bus bandwidth and the speed each device will operate at while running benchmarks.
The following formulas ignore protocol overhead however.
My Algorithm: The way I chose to go about figuring this is to calculate how long
it will take each device to transfer "one seconds worth" of data across
the SCSI bus. (i.e. The sustained number of Megabytes/sec times the number
of microseconds/byte at the burst rate), then, adding this figure for each
device on the bus. If the total is greater than 1 second, all the data
can't be transferred at full speed. Since there's not enough time to transfer
all the data, we need to reduce the time allotted to each device, and see
how much data it could transfer in that amount of time.
dev1_br = The first device's burst rate in MB/sec, dev1_sr = The first
device's sustained rate in MB/sec
dev2_br = The second device's burst rate in MB/sec, dev2_sr = The second
device's sustained rate in MB/sec
devN_br = The Nth device's burst rate in MB/sec, devN_sr = The Nth device's
sustained rate in MB/sec
If Percent_Utilization is less than 100, then each device will run pretty
close to it's sustained rate and it's obvious what percentage of bus bandwidth
remains for other activity.
If however, Percent_Utilization is greater than 100, we need to do more:
Note: I make the assumption that each device will pay the overutilization
penalty in proportion to how much data it will transfer (i.e. how much
it uses the bus). In reality it would depend on other factors too, like
what SCSI ID (and therefore what bus priority) each device was at. I haven't
done any testing to determine whether this is the best way to divide up
the "overtime". Perhaps the faster devices should pay less of a penalty.
I would welcome any data on how this works out on a real bus.
An example: We have three devices attached to an Ultra2 (80 MB/sec) host adapter:
An Ultra WIDE hard disk with a 40 MB/sec burst rate, and a 15 MB/sec sustained
transfer rate.
An Ultra narrow hard disk with a 20 MB/sec burst rate, and a 10 MB/sec
sustained transfer rate.
An Ultra narrow 28x CD-ROM drive with a 20 MB/sec burst rate, and a 4 MB/sec
sustained transfer rate.
iSCSI is a new standard for sending SCSI commands over an IP
network. It is the networking industry's answer to fibre channel. Storage
Area Networks are becoming very important to any company that needs large
amounts of reliable storage. Fibre Channel is the defacto standard
protocol for most SANs. Cisco and other networking companies are now pushing
iSCSI since they ignored fibre channel for too long.
