UltraSCSI

Originally published  August, 1998

by Carlo Kopp

© 1998, 2005 Carlo Kopp

The latest buzzword to hit the disk drive market is UltraSCSI. This series has examined the basic SCSI-2 protocol, and disk and bus performance issues in SCSI-2, in 1995. We will now extend the earlier discussion to encompass the UltraSCSI standard, and make some observations on how best to take advantage of this new technology. The driving force for the evolution of faster SCSI derivative standards has been the unprecedented growth in multimedia applications in the last two years. This can be largely attributed to the effects of growth in W3 services, driven in turn by what appears to be insatiable consumer demand. Multimedia demands bitmapped graphics, and bitmapped graphics need both server bandwidth and cache bandwidth at the user end, for what are typically bulky bitmap graphics files. From a user's subjective perspective, the ability of system to suck cached W3 files off its disk is often the determinant of acceptable performance. Moreover, commercial sites are increasingly turning to RAID (and in the author's opinion, half a decade later than they could have) and large RAID configurations comprising dozens or more fast (5-20 Mbytes/sec disk bandwidth) SCSI disks are simply beyond the performance capabilities of the single SCSI bus via which the RAID array is accessed. These trends will not diminish. Devices such as Solid State Disks are now becoming affordable, with manufacturers now producing 5.25" form factor devices with sizes up to and beyond the magical Gigabyte, at prices below USD100/Mbyte. A solid state disk does not exhibit the mechanical access time limitations of a conventional rotating disk. Its internal latency is therefore determined by the time it takes to fetch data from a slow DRAM array. Solid state disks therefore have total aggregate access times of the order of milliseconds, rather than the tens of milliseconds found in rotating media. This is typically a factor of ten improvement. The storage environment we can expect to see in the latter half of the decade will be characterised by an increasing amount of RAM storage used either directly, or used in larger on-drive caches, or used in RAID arrays. A large RAID array the author evaluated on behalf of a customer recently used a 4 Gigabyte DRAM cache sitting on top of a Terabyte class disk storage array. This effect will be seen from the top to the bottom of the market. Single user systems such as larger PCs and Unix workstations, small servers, large servers and large centralised systems will all use components in this performance class. The pressure for I/O bandwidth is not only confined to the storage side of the system. We are also seeing an explosion in processor performance, with many manufacturers now shipping superscalar 64-bit datapath CPUs, with 128-bit wide DRAM arrays now becoming the norm for workstations and top end PCs. Machines of this type are gluttons for opcode fetch bandwidth, with sophisticated caching and prefetching logic schemes which will suck substantial chunks of the customary 512 byte block per each prefetch operation. So our venerable SCSI bus was caught between a rock and a hard place. In many configurations the SCSI bus is indeed becoming the bottleneck to throughput performance. Interestingly, the problem is more evident in smaller systems rather than large systems. This is because large systems can usually accommodate, both physically and in terms of costs, a large number of SCSI I/O controllers and busses across which the storage media can be spread. The pressure in this direction was evident for some time now, and a major effort is under way to develop optical fibre and protocol-wise related serial derivatives of the SCSI standard. Whilst a number of products using various flavours of fibre-channel are now beginning to appear in the marketplace, the technology is still a bit immature and importantly, provides no backward compatibility to the large population of existing SCSI-2 drives. Because the fibre SCSI derivatives require a completely new storage subsystem we can expect them to move into the market fairly slowly, mainly as completely new installations. The existing fast 10 Mbyte/s and standard 5 Mbyte/s SCSI-2 drives represent an enormous investment across the established user base and the drive and I/O adapter manufacturers recognised this, moving in the interim to the Ultra SCSI standard. The Ultra SCSI Standard  The objectives of the Ultra SCSI standard are threefold. The first was to provide a substantial improvement over the established 10 Mbyte/s SCSI-2 standard to meet user expectations of throughput performance. The second was to provide a standard which can accommodate the existing population of drives. The third was to provide a buffer between existing technology and the fibre SCSI standard, as the latter is still maturing and will take some time before it is wholly accepted by the user base. With the growing non-professional user base, the latter is now a major issue. Another issue was the requirement to enlarge the address space of the bus, allowing more drives per chain. The SCSI-2 standard supported clock speeds of up to 10 MHz, and bus datapath widths of 8, 16 and 32 bits. The 8 bit configurations supported low density 50 pin connectors, whereas the "wide" 16-bit configurations were limited to high density 68-pin connectors. The author has yet to see a production 32-bit wide device. The designers of the UltraSCSI standard had essentially two choices in improving bandwidth while retaining backward compatibility. These were either to clock the bus faster, or widen the datapath. The eventual trade-off was a combination of both, and the much of the UltraSCSI we see in the market today uses a 16-bit datapath clocked at 20 MHz. The standard also supports the "narrow" 8-bit datapath. The use of a 16 bit datapath allows the use of existing 68-pin connectors which are still compact enough not to be cumbersome. The Ultra standard provides an 8 device address space on the narrow bus, and a 16 device address space on the wide bus, retaining the existing SCSI arbitration protocol. The earlier parts in our SCSI series discussed in considerable detail the technical problems associated with clocking long electrically heterogenous SCSI busses at 10 MHz "fast" SCSI speeds. Reflections and ringing effects on cables, exacerbated by poor quality terminators, poor drive and interface design, cheap and nasty connectors and dissimilar cable electrical behaviour make the attainment of full 10 Mbyte/s burst performance quite difficult. Full length 6 m SCSI chains with full seven drive populations can be hard to build successfully. The recommended strategy for dealing with the problem was to shorten the bus length and limit the number of drives on the chain. The Ultra SCSI standard finally addresses this issue, specifying a hard limit of 1.5 metres bus length. Even so, Ultra SCSI devices have significantly improved bus receivers and transmitters on their interface chips. Arguably, these have been long overdue, as the miserable robustness of many SCSI-2 designs, as previously discussed, caused much pain in the user community. Differential versions of UltraSCSI nominally support 25 metre cable lengths. The UltraSCSI standard retains much of the timing of the 10 MHz Fast SCSI standard, with Arbitration, Bus Clear, Bus Free, Bus Set, Bus Settle, Reset Hold, Data Release and Selection Timeouts identical. The big differences are seen where it matters, in the data transfer timings used when data is clocked between the devices on the bus. These are halved, to match the 20 MHz clock cycle of the Ultra standard. An 8-bit wide Ultra bus will deliver 20 Mbyte/s bursts, and a 16-bit wide Ultra bus 40 Mbyte/s bursts. As with existing SCSI-2 busses, the controllers will initially arbitrate the transfer rates on a drive by drive basis. The short cable length mandated by the standard has also seen a growth in the availability of SCSI extender devices. A SCSI extender is typically built as a fully regenerative bidirectional repeater. It separates the bus into two terminated segments, and retimes and retransmits all bus signals transparently in either direction. In this fashion, it prevents garbage from one segment of the bus from contaminating the other. The penalty in using a SCSI extender will be a slight loss in performance, subject to the depth of buffering in the extender (this can be very low), and the cost and reliability penalties of adding extra hardware into the chain. A typical extender will use an external plugpack adapter to power itself, as the SCSI termination power line cannot deliver enough to feed it. Integrating UltraSCSI A user seeking to add an Ultra device or devices to his or her system should consider carefully how to go about this. Whilst many manufacturers claim their products can accommodate existing cables, experience with fast SCSI suggests that this may be optimistic in many instances. The scenario we will consider is an existing workstation or PC platform, which may be used as a user platform or server. The system will have a number of fast narrow devices installed on one or two SCSI chains. The user's favourite disk vendor has offered the latest and greatest UltraSCSI disk which ostensibly solves all of the user's existing I/O throughput problems (an interesting subject to debate within itself). The first question to ask is whether a suitable Ultra SCSI controller is available for the machine in question. If the platform uses one of the more popular busses, such as PCI or Sbus (SMI or clone), this is not an issue as a wide range of boards is becoming available. Selecting a board is then driven by the availability of device drivers for your operating system, and if this requirement is met, then comparing prices, performance of the host bus interface and mundane but vital issues such as support. Having answers to these questions, we must now ask the question whether it is better to replace one of the existing SCSI controllers or add another SCSI chain. If the host is out of empty slots, this defaults to replacement and a drive shuffle. Given the pathological behaviour of many items of existing fast SCSI-2 hardware, it is highly recommended that the Ultra SCSI chain use its own controller, cables and devices. Whilst in theory it is possible to do a drive shuffle and replace an existing controller with an Ultra device, the risk involved in doing so is that bus robustness will be impaired by using older cables/connectors and drives. Moreover, older terminators may misbehave electrically at 20 MHz, as many commodity type terminators are barely able to accommodate the 10 MHz fast standard. Therefore, if a controller replacement and drive shuffle is to be done, it is highly recommended that the upgrade also include new "Ultra rated" cables and terminators. The UltraSCSI standard promises useful gains in performance against Fast SCSI-2 , but as with all SCSI upgrades, common sense should prevail. In the real world there are no silver bullets.

$Revision: 1.1 $

Last Updated: Sun Apr 24 11:22:45 GMT 2005

Artwork and text © 2005 Carlo Kopp