neese@adaptex.UUCP (11/15/89)
The following is inetended for those who may have or are thinking about purchasing a SCSI subsytem. THE HOST ADAPTER: THE FIRST PIECE OF THE PUZZLE Host adapters come in many flavors. Some are well supported, others are not. Some are intelligent, some are not. To decide on the correct host adapter to use is a difficult decision and one that should not be taken lightly. Unless you are prepared to continue investing in other adapters as your systems needs grow, you need to study and understand the different types of host adapters and the application they are going to be used in. The simplest host adapters are cards that may have an INT13 At BIOS to support hard drives under MS-DOS. These host adapters usually have no UNIX support as it is very difficult to do a device driver that can be made to work reliably. Dumb cards such as these usually have timing constraints that make it almost impossible to have a UNIX driver. The next level of host adapter goes to the other extreme. They are very intelligent and usually hide the SCSI bus from the operating system. These types of adapters have a wide base of support in software, as they can run in any environment with very little software effort. They are also expensive adapters, which may not be needed in the MS-DOS machine. Indeed, they may be overkill for a machine that is to be relegated to the DOS environment. If you are going to be using MS-DOS and MS-DOS alone, then the low cost approach is not a bad one. But if you intend to use UNIX/Novell/OS2, then the low cost approach will be a poor one. These operating systems/environments are all multi-threaded. That is they can issue more than one command at a time. With an intelligent host adapter, this is easily done and managed by the host adapter. With a low cost board, the software to do this work must be driven by the main CPU, which will incur considerable command overhead. Of course, there is also the support issue. You always would like to avoid the finger pointing that can occur when using products from several companies, when a bug arises. This is best done by buying a product that is supported by the operating system manufacturer. There are very few SCSI host adapters supported by the operating systems manufacturers. You need to ask them what they will support and what they won't. A little planning in this area may solve many potential problems for you. Questions you should ask: a) What operating environment will I be using? b) Is the operating environment multi-threaded? c) Am I going to be using several operating systems? d) Do I care if support is from one operating system vendor? SCSI DEVICES AND MANUFACTURER'S CLAIMED DATA RATES Ignore the manufacturer's rated data rates. They are measured on the SCSI bus assuming that no data is being transferred to the device buffer from the media and they also assume the best case data transfer (no disconnects). To get an idea of how a device might perform, look at the clock rate of the head. You will see a range from 7.5 Mhz to 24 Mhz. Some devices have multiple clock rates. These are bit zone recorded devices. They have more sectors on the outer tracks than they do on the inner tracks. The data rate to the devices buffer is the rate of the clock on the head. A 7.5Mhz head moves data to the buffer at 750KB/sec and a 24Mhz clock on the head moves data at 2.4MBytes/sec. Data rates to/from the buffer from/to the SCSI bus are regulated by the clock rate of the dual ported buffer (where applicable). If the buffer has a 4MHz clock, then the fastest the data can be shipped to/from the buffer is 4MBytes/ sec, but if data is being shipped to/from the media from/to the buffer, then the rate that data can move across the SCSI bus is directly impacted. For instance, if the drive is putting data into the buffer at 2.0MBytes/sec and the buffer is a 4MHz part. The fastest data can be moved to the SCSI bus is 2.0MBytes/sec not 4MBytes/sec. This, of course, only applies to those devices that have a dual ported buffer. How the buffer full/empty ratios are used will also effect the data rate. SCSI devices, for the most part, have programmable buffer full/empty ratios stored in a mode page of the device. NOTE: Not all devices allow a user to reprogram these parameters. These parameters affect when the device should and should not, get on the SCSI bus for a data transfer. Typically, a SCSI device will ask for the bus, on a read, when there is at least 1 sector in the data buffer ready to transfer. The transfer will start and the device will continue to put data into the buffer if possible, as data is taken out of the buffer. If the buffer falls below the 1 sector limit, then the device will disconnect from the bus and will not reconnect until the buffer has at least one sector's worth of information. Questions you should ask: a) How fast is the dual ported buffer? b) What is the clock rate of the heads? c) Is the device capable of synchronous transfers? d) How is the buffer full/empty ratios calculated and implemented? TO BUFFER OR NOT TO BUFFER? The size of the buffer has a lot to do with the overall performance of the SCSI device. Buffer sizes range from 16K to 256K. If the buffer is not dual ported, then that implies the device cannot allow data to be moved from/to the SCSI bus while the HD is moving data to/from the buffer and vice-versa. If the buffer is just a buffer to smooth the data transfer, then the size of the buffer can be small if you have a host adapter capable of moving the data at the full rate of the SCSI bus. If the adapter is dumb and cannot move data very quickly, then a larger buffer is required to minimize the disconnects/ reconnects on the SCSI bus. In this implementation, the size of the buffer will not impact nor help performance. Also, with a dumb adapter you will find it very difficult to maintain a 1:1 interleave with this type of buffering scheme. Typically, this is the poorest performing SCSI device. If the device has a read ahead buffer, then sequential accesses will be much quicker. Although the more fragmented the file system the worse the worse the performance. In this case, the size is dependent on the overall implementation. If the read ahead will abort at the end of a track, then the buffer need not be larger than the largest track on a device. If the read ahead is aborted at a cylinder switch, then the buffer size should be large enough to accommodate the largest cylinder. For the most part, this is a good implementation. If the device has a read ahead cache buffer, then this, like the read ahead buffer, will give good sequential accesses, but still poor performance on a very fragmented filesystem. As data in the buffer is recoverable, because this is a cache, some performance gains will be noticed in a multi-user environment. The same rules for the read ahead buffer above apply when it concerns the size of the buffer. A better performance implementation. If the device has a segmented cache buffer, then this will yield the best performance available in all operating environments. It must be tunable so you can match the characteristics of the operating environment. The size of the buffer should not be less than 64K for this type of implementation to be effective, but it can be as large as the vendor chooses and the bigger the better. This is the best performance choice. Questions you should ask: a) What type of buffer algorithm do you use? (i.e. read-ahead, cache) b) Is the buffer algorithm programmable? c) What is the size of the buffer? d) What is the clock (or resolution) of the buffer? e) Is the buffer dual ported? SCSI COMMAND OVERHEAD SCSI command overhead is a much discussed topic when users opt to go with SCSI and generally a very heated topic. In the past, the overhead was very high (on the order of 3 milli-seconds). Today SCSI overhead, for the device, is down to 1 milli-second and less. Some devices have multiple processors, one for running the SCSI bus and one for the device electronics. These type of devices have less overhead than a single processor device as they can do things in parallel. Be aware of the manufacturers specs. Though they don't lie, they publish the best case overhead times. SCSI command overhead, as measured by the manufacturer, is typically taken from the time a TEST UNIT READY command takes to complete. The problem with that is this command takes the shortest path through the vendor's firmware as it does not require any data transfers. The best way to measure the overhead for a SCSI device is to issue a write command and then issue the same command again, to ensure the device is at the track it should be. Using a logic analyzer, measure the time from the last command byte to the ending status phase for the second write command. Subtract the data phase of the command and you will have a more believable idea of the overhead. The reason you want to use a write command is to eliminate any disk latency that a read command would generate. Measuring overhead from the system level is virtually impossible, as you also have the host adapter overhead and then the bus and CPU rates come into play. Questions you should ask: a) What is the SCSI command overhead for your controller? b) How is the overhead measured? c) Does your device have multiple processors? d) What is the clock rate of the processors? BENCHMARKING MADE EASY?? Throw away CORETEST, or disregard the seek times and the size of the request. Seek times on a SCSI device cannot be measured at the BIOS level unless the benchmark can be told what physical parameters to use. SCSI is a logical block interface and has no physical characteristics. The number of heads, sectors, and cylinders at the BIOS level are all incorrect, so the seek times that virtually all of the benchmark programs use will not yield accurate seek times. You cannot use the manufacturer's seek rate as it is measured at the mechanical level and not at the SCSI bus level. To test the seek times, you almost have to write your own benchmark. If 'adaptex' was going to be around I would have a program that would do just that for SCSI devices and post it, but alas. CORETEST also reads the same data over and over again, so a SCSI device that has a read ahead buffer, will not be accurately measured. In order to get a fair idea of the data rates that a SCSI device can yield requires you to measure data transfers in the following ways: 1) Sequentially 2) Random (1/3 stroke, preferred as you can do that at the BIOS level) 3) Read the same data over and over again. Now that will take care of the single-threaded benchmark, but what UNIX/XENIX and other multi-threaded operating environments? While none of the current benchmarks really do a fair job of measuring the correct thing for these environments, they can yield some useful information. With a multi-threaded environment, you should not only consider the average access time and the data rate, but more importantly. How does the SCSI implementation I have chosen effect the overall throughput of my system? While in a single-threaded environment most devices will benchmark well, device characteristics change dramatically in a multi-threaded mode. This is due in part to the devices ability to efficiently arbitrate for the SCSI bus. Some devices may take as long as 3 milli-seconds to complete an arbitration cycle, while others take only 1 milli-second. The only way you can judge the devices is via a logic analyzer. You are basically looking for the overall usage of the SCSI bus. Questions you should ask: a) How can I measure the average seek time? b) What environment will this implementation be used in? c) How can I best judge the performance in this environment? PERSONAL PERFORMANCE RATING If I had to rate, regardless of capacity, the best performing SCSI devices that I have used, the list would go: Quantum (3 1/2") 64K segmentable cache buffer, RLL 2.7, ZBR async/sync Quantum (5 1/4") 64K segmentable circular cache buffer, RLL 2.7, async Imprimis (5 1/4") 32K read ahead buffer (*), RLL 2.7, ZBR, async/sync Maxtor (5 1/4") 45K read ahead buffer (*), RLL 2.7, async/sync Micropolis (5 1/4") Priam (5 1/4") Imprimis (3 1/2") Maxtor (3 1/2") 8K buffer, RLL 2.7, async Seagate (5 1/4") Basic buffer Conner (3 1/2") Basic buffer Rodime (3 1/2") Basic buffer * Drives come with read ahead disabled. It can only be activated via software Recomended products to avoid Cast/Newbury Do not meet SCSI standard (Rev17B) Microscience Do not meet SCSI standard (Rev17B) TERMS ZBR Zone Bit Recorded Roy Neese Adaptec Central Field Applications Engineer UUCP @ {texbell,attctc}!cpe!adaptex!neese merch!adaptex!neese