There are several different types of SCSI devices. The original SCSI specification is commonly referred to as SCSI-1. The newer specification, SCSI-2, offers increased speed and performance, as well as new commands. Fast SCSI increases throughput to more than 10MB per second. Fast-Wide SCSI provides a wider data path and throughput of up to 40MB per second and up to 15 devices. There there are Ultra-SCSI and Ultra-Wide-SCSI

The last type, SCSI-3, provides the same functionality as Fast-Wide SCSI as well as support longer cables and more devices.

Each SCSI device has its own controller and can send, receive, and execute SCSI commands. As long as it communicates with the host adapter using proper SCSI commands, internal data manipulation is not an issue. In fact, most SCSI hard disks have an IDE controller with a SCSI interface built onto them.

Because there is a standard set of SCSI commands, new and different kinds of devices can be added to the SCSI family with little trouble. However, IDE and ESDI are limited to disk-type devices. Because the SCSI commands need to be “translated” by the device, there is a slight overhead, which is compensated for by the fact that SCSI devices are intrinsically faster than non-SCSI devices. SCSI devices also have higher data integrity than non-SCSI devices. The SCSI cable consists of 50 pins, half of which are ground. Because every pin has its own ground, it is less prone to interference and therefore it has higher data integrity.

On each SCSI host adapter are two connectors. One connector is at the top of the card (opposite the bus connectors) and is used for internal devices. A flat ribbon cable is used to connect each device to the host adapter. On internal SCSI devices, only one connector is on the device itself. Should you have external SCSI devices, there is a second connector on the end of the card (where it attaches to the chassis). Here SCSI devices are “daisy chained” together.

The SCSI-Bus must be closed to work correctly. By this I mean that each end of the bus must be terminated. There is usually a set of resistors (or slots for resistors) on each device. The devices at either end of the SCSI-Bus must have such resistors. This process is referred to as terminating the bus and the resistors are called terminating resistors.

Its fine to say that the SCSI-Bus needs to be terminated. However, that doesn’t help your understanding of the issue. As with other kinds of devices, SCSI devices react to the commands sent along the cable to them. Unless otherwise impeded, the signals reach the end of the cable and bounce back. In such cases, there are two outcomes, both of which are undesirable: either the bounced signal interferes with the valid one, or the devices react to a second (unique in its mind) command. By placing a terminator at the end of the bus, the signals are “absorbed” and, therefore, don’t bounce back.

The following two figures show examples of how the SCSI-Bus should be terminated. Note that Figure 0-6 says that it is an example of “all external devices.” Keep in mind that the principle is still the same for internal devices. If all the devices are internal, then the host adapter would be still be terminated, as would the last device in the chain.

Image – Example of SCSI Bus with All External Devices (interactive)

Example of SCSI Bus with Both External and Internal Devices (interactive)

If you don’t have any external devices (or only have external devices), the host adapter is at one end of the bus. Therefore, it too must be terminated. Many host adapters today have the ability to be terminated in software, so there is no need for terminating resistors (also known as resistor packs).

Each SCSI device is “identified” by a unique pair of addresses, which are the controller addresses that are also referred to as the SCSI ID. This pair of addresses is usually set by jumpers or dip switches on the device itself. Keep in mind that the ID is something that is set on the device itself and is not related to location on the bus. Note that in the figures above, the SCSI ID of the devices are ordered ID 0, 6, and 5. Also the SCSI ID is often set using a combination of jumpers with no 1:1 relationship. (That is a pair of pins labeled ID 0 through ID 7) Therefore, you should always read the hardware documentation to determine how to set the ID.

This sounds pretty obvious, but some people don’t make sure. They make assumptions about what they see on the device regarding how the ID is set and do not fully understand what it means. For example, I have an Archive 5150 SCSI tape drive. On the back are three jumpers, labeled 0, 1, and 2. I have had customers call in with similar hardware with their SCSI tape drive set at 2. After configuring the tape drive and rebooting, they still couldn’t access the tape drive. Nothing else was set at ID 2, so there were no conflicts. The system could access other devices on the SCSI-Bus, so the host adapter was probably okay. Different SCSI devices can be plugged into the same spot on the SCSI cable, so it wasn’t the cable. The SCSI-Bus was terminated correctly, so that wasn’t the problem.

Rather than simply giving up and saying that it was a hardware problem, I suggested that the customer change the SCSI ID to 3 or 4 to see if that worked. Well, the customer couldn’t, because the jumpers on the back only allowed him to change the SCSI ID to 0, 1, or 2. It then dawned on me what the problem was: the jumpers in the back are in binary! To set the ID to 2, the jumper needs to be on jumper 1, not jumper 2. Once the customer switched it to jumper 1 and rebooted, all was well. (Note: I helped this customer before I bought the Archive tape drive. When I got my drive home and wanted to check the SCSI ID, I saw only three jumpers. I then did something that would appall most users: I read the manual! Sure enough, it explained that the jumpers for the SCSI ID were binary. )

An additional problem to this whole SCSI ID business is that manufacturers are not consistent among each other. Some might label the jumpers (or switches) 0, 1, and 2. Others label them 1, 2, and 4. Still others label them ID0, ID1, and ID2. I have even seen some with a dial on them with 8 settings, which makes configuration a lot easier. The key is that no matter how they are labeled, the three pins or switches are binary and their values are added to give you the SCSI ID.

Lets look at Figure 0-8, which represents the jumper settings on a SCSI device. In the first example, none of the jumpers is set, so the SCSI ID is 0. In the second example, the jumper labeled 1 is set. This is 2¹ or 2, so the ID here is 2. In the last example, the jumpers labeled 2 and 0 are set, which is 2² + 2⁰ = 4 + 1, or 5.

On an AT-Bus, the number of devices added is limited only by the number of slots (granted, the AT-Bus is limited in how far away the slot can be from the CPU and therefore is limited in the number of slots). On a SCSI-Bus, however, there can be only seven devices in addition to the host adapter. Whereas devices on the AT-Bus are distinguished by their base addresses, devices on the SCSI-Bus are distinguished by their ID number.

ID numbers range from 07 and, unlike base addresses, the higher the ID, the higher the priority. Therefore, the ID of the host adapter should always be a 7. Because it manages all the other devices, it should have the highest priority. On the newer Wide SCSI-Buses, there can be up to 15 devices, plus the host adapter, with SCSI IDs ranging from 0 to 15.

Now back to our story…

The device address is known as the logical unit number (LUN). On devices with embedded controllers, such has hard disks, the LUN is always 0. All the SCSI devices directly supported by Linux have embedded controllers. Therefore, you are not likely to see devices set at LUNs other than 0.

In theory, a single-channel SCSI host adapter can support 56 devices. Devices called bridge adapters connect devices without embedded controllers to the SCSI-Bus. Devices attached to the bridge adapter have LUNs between 0 and 7. If there are seven bridge adapters, each with eight LUNs (relating to eight devices), 56 total devices are therefore possible.

The original SCSI-1 spec only defined the connection to hard disks. The SCSI-2 spec has extended this connection to such devices as CD-ROMS, tape drives, scanners, and printers. Provided these devices all adhere to the SCSI-2 standard, they can be mixed and matched even with older SCSI-1 hard disks.

One common problem with external SCSI devices is that the power supply is external as well. If you are booting your system with the power to that external device turned off, once the kernel gets past the initialization routines for that device (the hardware screen), it can no longer recognize that device. The only solution is to reboot. To prevent this problem, it is a good idea to keep all your SCSI devices internally. (This doesn’t help for scanners and printer, but because Linux doesn’t yet have drivers for them, it’s a moot point.)

Although the number of host adapter manufacturers has steadily decreased in the past few years, Adaptec, the premier name in host adapters, has bought up both Trantor and Future Domain. Adaptecs biggest competitor for years, Buslogic, was no longer able to compete and was taken over by Mylex (a motherboard manufacturer, among other things). Despite the decrease in number of manufacturers, the number of models is still overwhelming.

Most host adapter manufacturers provide more than just a single model. Many provide models for the entire spectrum of buses and SCSI types. ISA, EISA, PCI, Fast SCSI, Wide SCSI, and Ultra-Wide SCSI are part of the alphabet soup of SCSI devices. You can connect Wide SCSI disks onto a Fast SCSI adapter, although it will still only get 8 bits instead of the Wide SCSIs 16 bits, so it therefore only gets 10Mbytes per second compared to 20Mbytes per second of Wide SCSI.

Ultra SCSI disks can also be connected with the same limitations (it is an 8-bit bus). It can also handle Ultra-Wide SCSI and get 40Mbps. This is not too big of an issue, as most of the devices available today can only handle 10Mbps.

When looking at the performance of a SCSI device, you need to be careful of the manufacturers test results. They can be deceiving. If a test reads 200MB from the disk in 10 seconds, you get an average of 20MB per second. What if those 100MB are all from the same track? The disk hardware reads the track and keeps it in its own cache. When the host adapter requests a new block from that track, the hard disk doesn’t need to find the block on the disk,it delivers it from the cache. This decreases the access time and increases the apparent transfer rate of the drive dramatically. The manufacturer can say, in all honesty, that the host adapter has a transfer rate of 20Mbps, though the drive can only do half of this at most. Again, the chain is only as strong as its weakest link.

This does not mean that Wide SCSI or Ultra SCSI are only useful for the companies marketing departments. SCSI has the advantage of being able to talk to multiple devices. For example, it can request data from one drive and, rather than waiting for the data, free the SCSI-Bus (disconnect). When the drive (or other device) is ready, it requests the bus again (reconnect) and the data is transferred. While the drive searches for the data, the host adapter can request data from another device. While this device is looking for the data, the first device can transfer the data to the host adapter. Being able to read or write devices like this means that a host adapter could get a sustained transfer rate of more that what individual devices can handle. (Note that both the host adapter and device must support disconnect/reconnect.)

Wide SCSI gets its performance gain by the fact it is wide (16 bits versus 8 bits). Ultra SCSI, on the other hand, gets the increase through a shorter cycle time. This is an important aspect because this makes for a steeper edge on the signal (the time from a low to high signal is much shorter, and vice versa). This means that the SCSI-Bus has higher requirements regarding the cabling.

Internal devices usually are connected by flat cable ribbons and present few new problems with Fast SCSI. The maximum length of the cable is half of what it could be with older SCSI devices and you must follow the specs exactly. Round cables for external devices have to be created specifically for Ultra SCSI and are therefore more expensive. Although the actual data transfer rate between the host adapter and the device is only as high as the device can handle, the steepness of the edges is the same. This means that if you connect Fast SCSI devices to Ultra SCSI host adapters, you still need the special Ultra SCSI cables.

Another consideration is that Ultra SCSI requires active termination. On the host adapter side, this isn’t a problem because the host adapters are designed to give active termination. However, many older devices support only passive termination and therefore cant work on Ultra SCSI host adapters. This really comes into play when larger amounts of data are being transferred.

PCI devices can generally behave as either masters or slaves. For slave devices, the CPU is responsible for all the activity. This is a disadvantage for slave devices because the CPU is often busy transferring data and issuing commands instead of doing other work. This is really an issue in multitasking operating systems (like Linux) that have “better” things to do. Master devices, on the other hand, have an advantage here. The CPU only needs to tell them where to transfer the data, and they do the work themselves.

Regardless of whether a device acts as a master or slave, it will take up an interrupt line. Single function devices, such as host adapters, are given the interrupt INT-A. This means that the actual IRQ (between 5 and 15) will be determined by the system BIOS.

Generally, you can say that a higher throughput is required on a file server as compared to a workstation. Although there are applications like CAD or video processing, which require more throughput on a workstation than other kinds of applications, the major of the work is done by the server. Therefore, it is extremely important to consider the performance of your hard disk and similar devices on the server.

Despite reaching comparable prices and sizes, ATA harddisks as suited for work in a server because they do not have the throughput of SCSI. As we discussed previously, SCSI has the advantage of being able to have two devices communicate with each other directly with the need to go through the CPU. In addition, while waiting for one device to find the data, it can “disconnect” itself and you can make a request of another device on the same SCSI bus. This is especially important on servers as they usually have multiple disks, as well as other kinds of devices.

Here again, the chain to your harddisk is only as weak as the weakest link. Therefore, you need to have a SCSI host adapter that can keep up with the hard disk.

Let’s take my Adaptec 2940U2W host adapter which I have in my primary workstation as an example. This is an Ultra2 SCSI device, which gives me a maximum transfer rate of 80 Mbyte/second. One neat aspect of this host adapter, is that it uses a technology Adaptec calls “SpeedFlex.”. Internally, there are three connectors. One for Ultra2 SCSI (80Mb/s), one for Wide Ultra SCSI (40Mb/s) and one for Ultra SCSI (20Mb/s). Externally, you have two connectors. One 68-pin for Ultra2 SCSI and one 50-pin for Ultra SCSI. Therefore, you get the maximum throughput no matter what kind of device is connect to the host adapter. In addition, one aspect of the SpeedFlex technology is that it can operate the different buses at the different speeds simultaneously, so there no performance lost on one bus because of a slow device on another bus.

The “W” at the end of the host adapter name means that it has the Wide Ultra SCSI connector. Adaptec also produces the 2940U2, which has the same specifications, but without the internal Wide Ultra SCSI connector and without the external Ultra2 connector. Note that in each case, devices supporting older SCSI standards can still be connected.

In one one of my machines, I have an Adaptec 3940U2, which is also an Ultra2 SCSI adapter. One key difference is that this adapter is twin-channel. That means I have two SCSI buses running off of the same host adapter. This is extremely useful when you have more device that will fit on a single bus, plus added speed. Both of this aspects make this the perfect adapter for a Linux server (although I use it in my Workstation). Another important difference is that the Adaptec 3940U2 supports 64-bit PCI, although it is still capable with 32-bit PCI.

One thing to note is that all of the devices support up to 15 devices (plus the host adapter per channel). This means that the twin-channel 3940U2 can connect up to 30 devices. In addition, all devices support cables up to 12 meters long.

On one machine I have an Adaptec 1542 CF host adapter. The Adaptec 1540 a SCSI-1 and SCSI-2 compliant ISA host adapter, which has an 8-bit data bus and a maximum transfer rate of 10 Mbyte/sec. This is a perfect host adapter for workstations which require less performance.

Initially, I wanted to say “low end”, but that tends to create false impressions of something of lesser quality. This definitely does not apply to the Adaptec 1540 family (or any of the Adaptec products for that matter). A few months ago, I replaced the 1542CF I had after six years because the built-in floppy controller was no longer working correctly. The host adapter was working fine. I just couldn’t access my floppy drive.

A few weeks later, I put it back into the machine as it as the only one with the external connector my CD-ROM changer had. Rather than buying an adapter for the connector, I put in my old Adaptec 1542 CF and it has run perfectly ever since.

All of the Adaptec host adapters support what is called “scatter gather.” Here, requests for data on the harddisk which are “scattered” all over the drive are “gathered” together, in order that they be more efficiently process.

This is similar to way an elevator works. Image that four people get into an elevator. The first one presses the button for floor 12, the next one for floor 16 the next one for floor 3, and the last one wants floor 8. Although the person wanting to go to floor 12 was there first, the elevator stops at floor 3 first, then floor 8 before continuing to floor 12. This is much more efficient than going to each floor in the order the buttons were pressed.

Accessing a hard disk is similar. On active systems, there will be several requests waiting to processed. Adaptec host adapters will sort the requests based on their physical location on the hard disk. Interestingly enough, Adaptec refers to this as an “elevator sort.”