Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
HP.com home
HP1000/RTE  >   HP1000/RTE Technical Support

HP1000/RTE

Technical Support
» 

HP1000/RTE

HP1000/RTE information

» HP1000/RTE Home page
» Product information
» Technical support
» Partners
» Section map
Content starts here

SCSI performance information

The purpose of this text is to shed some light on how the SCSI drivers and I/O card work and to make some performance comparisons between SCSI disks and HPIB disks. In making these comparisons, we used a C2212A SCSI drive and a C2200C HPIB drive. These drives use the same disk mechanisms and are both 330 MB drives.

One of the major differences between the newer SCSI disks and the older CS/80 disks is the physical sector size. From at least the 7900A disk drives of the early 1970s until recently, the physical sector size was 128 words (256 bytes). RTE relies heavily on this "constant", and to modify it would require extensive rework. Thus, when the SCSI project was undertaken, one of the major concerns was to make the larger sector sizes (512 bytes for the current hard drives and 1024 for the MO drives) transparent to the OS. To accomplish this, the SCSI card uses an on-board cache on a per channel basis. The management of this cache can result in either a performance increase or decrease depending on how the disk is utilized. We will look at some of the factors involved.

Performance decreases due to the different sector sizes can be demonstrated by looking at the following comparison of the blocks:

|   256 bytes   |   256 bytes   |   256 bytes   |   256 bytes   | ...
------------------------------------------------------------
| ------ SCSI Block 0 ------ | ------ SCSI Block 1 ------ | ...
--------------------------------------------------------------
| RTE Block 0 | RTE Block 1 | RTE Block 2 | RTE Block 3 | ...
------------------------------------------------------------
Comparison of a 512 byte SCSI block with 256 byte RTE block When an RTE user wants to write to RTE Block 1, the following actions must occur:
  1. SCSI block 0 is read
  2. Part of the block is modified
  3. The block is written back to disk
When an RTE user wants to write 512 bytes to RTE blocks 1 and 2, the overhead becomes even more complex due to the activities required to read 2 SCSI blocks (1024 bytes total), modi the needed portions, and write the blocks back to disk.

This problem can be avoided if all transfers are aligned such that they begin and end at SCSI block boundaries. Files can be forced to start at SCSI block boundaries by genning disk LUs so that the allocation unit times 256 bytes is equal to the SCSI block size. The current hard disks (C2212A and C2213A) have 512 byte blocks. This means an allocation unit of 2 will force all files on the disk to start at a SCSI block boundary. The allocation unit is the number of blocks represented by each bit in the bitmap at the the start of each CI volume. (The allocation unit is further described in Chapter 10 of the RTE-A System Design Manual, part no. 92077-90013.) The bitmap has a fixed size of 8192 words (128k bits), and each bit specifies whether each allocation unit is used or free. A disk containing between 128k blocks and 256k blocks will have an allocation unit of 2. Note that in addition to having an allocation unit of 2 or more, the SCSI disk LU must also start at a SCSI block boundary to be aligned.

Our tests comparing SCSI disk transfers with the equivalent HPIB disk show that the HPIB disk will always outperform the SCSI drive when the RTE block is not aligned with the SCSI block. This penalty can become significant when buffer sizes are increased. As a result, in the following discussions when comparing the performance of HPIB disks with SCSI disks, we will always be referring to transfers that have RTE blocks aligned with SCSI blocks. Also, all transfers are an even number of RTE blocks. This ensures that both the beginning RTE block and ending RTE block are aligned with the SCSI block. Note that for SCSI block sizes of > 512 bytes, a larger transfer length will be required to maintain SCSI block alignment at both the starting and ending transfer points.

The effect that increasing buffer sizes have on the performance depends on the type of file being transferred. For type 1 files, the HPIB and SCSI disks have comparable transfer rates until the reads or writes are greater than 16k bytes. For HPIB drives, buffer sizes >16k do not show an appreciable performance difference, whereas for SCSI drives buffer sizes up to 28k bytes continue to show performance increases. SCSI performance degrades when buffer sizes are increased beyond 28k due to an extra seek. Due to the size of cache and additional buffer management, performance will decrease for SCSI reads when block sizes are between 6k and 10k and for writes when block sizes are between 8k and 10k. (Efforts are currently being undertaken to minimize these gaps.)

For type 2 and greater files, disk performance is generally only slightly better for SCSI disks than HPIB disks when transfer sizes are greater than 10k. However, for some transfer sizes of less than 10k, HPIB drives may perform significantly better than SCSI drives.

In summary, when using SCSI drives, we recommend that you use transfers that are SCSI block aligned. Starting block location can be forced to be SCSI block aligned by generating the disk larger than 128k blocks. Ending block can be forced to be SCSI aligned by specifying an appropriate transfer length. In general, performance will increase as transfer sizes (buffer sizes) increase. However, transfer size does not impact performance as much as SCSI block alignment does. In addition, when transfers are SCSI block aligned, performance differences between HPIB disks and SCSI disks are only slight unless the file is a type 1 file and the transfer sizes are between 16k and 28k. For user applications, we recommend that individuals do performance modeling in order to determine which transfer lengths are most appropriate for their applications.

 

Privacy statement Using this site means you accept its terms
© 2009 Hewlett-Packard Development Company, L.P.