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!neesechris@mimsy.umd.edu (Chris Torek) (11/24/89)
In article <6900004@adaptex> neese@adaptex.UUCP writes: > Host adapters come in many flavors. Some are well supported, others are >not. Some are intelligent, some are not. ... and not least, some work as advertised, and some are incredibly buggy. There is a general tendency for `smart' to imply `buggy', but this is not a hard-and-fast rule. There is also a tendency for `first out' to imply `buggy'. This matters more to the person writing the code to deal with the adapter. > 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. This analysis is a bit too simplistic (it leads to the UDA-50 mentality): the work must be done; the work can be all in one place (the main CPU); the workload can be distributed (shared between the CPU and the adapter); using distributed computing means more total CPU power is being applied. (So far, all is fine.) The conclusion that gets made here is that the distributed system will provide more total throughput. Unfortunately, this is often false. Some of the `total power' being applied goes to overhead--- communication between the `smart' I/O board and the main CPU. If the protocol is fat, or if there are bugs in the `smart board', this overhead can outweigh the savings from having moved some of the `hard work' off the main CPU. Then, too, there is this: the CPU in the `smart' board may in fact be quite stupid. If you give it any significant work, it may take a significant amount of time to handle it. This will increase latency, and may even decrease total throughput (give too much work to the slow processor, and the fast one will always be waiting). >[various points about support deleted] >[various points about speed deleted] > 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. (or more) >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. As long as the SCSI bus is not busy, and/or the bus the adapter is on is not busy, that is. A smoothing buffer *can* work (e.g., the Emulex massbus adapter for SBI VAXen has only a smoothing buffer), but typically it works well only if the rest of the system is overdesigned (e.g., the SBI). > 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. Unix boxes with the 4BSD file system will gain a great deal from a read-ahead buffer (provided you are reading `large' files). Your exact gain will vary, of course. >Today SCSI overhead, for the device, is down to 1 milli-second and less. 1 ms is still quite significant---e.g., on a MIPS box running at 16 MHz (DECstation 3100), the host CPU could execute about 16 thousand instructions. SCSI manufacturers really need to cut the time down by at least an order of magnitude. >BENCHMARKING MADE EASY?? >[text showing how benchmarking SCSI devices is NOT easy] Agreed. It is worth noting that random seek behaviour rarely occurs in practise, so that track-to-track seek time is more important than end-to-end seek time (or the so-called `average' seek time, which is made by assuming that the probability of moving from any one cylinder to any other is independent, i.e., access is completely random). This is true of any system that does sane sector layout, including BSD-file-system-Unix-boxes. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris