Browse Prior Art Database

Optimization of a Software Generating Process

IP.com Disclosure Number: IPCOM000107590D
Original Publication Date: 1992-Mar-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 3 page(s) / 110K

Publishing Venue

IBM

Related People

Means, R: AUTHOR [+2]

Abstract

It is desirable to use a PS/2* as a host or a control unit when attaching to SCSI devices. A significant problem with this stems from the fact that the PS/2 internals are not parity (or CRC/ECC) protected, raising data integrity issues. One solution to this problem calls for software generation of parity across key control structures. This parity can be checked by the end user of the control structure and, if found to be correct, can guarantee the integrity of the control structure. A serious drawback to this process is the expense (in processor cycles used) of generating parity with software.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Optimization of a Software Generating Process

       It is desirable to use a PS/2* as a host or a
control unit when attaching to SCSI devices.  A significant problem
with this stems from the fact that the PS/2 internals are not parity
(or CRC/ECC) protected, raising data integrity issues.  One solution
to this problem calls for software generation of parity across key
control structures.  This parity can be checked by the end user of
the control structure and, if found to be correct, can guarantee the
integrity of the control structure.  A serious drawback to this
process is the expense (in processor cycles used) of generating
parity with software.

      Described here is a partial results method that will
significantly reduce the execution time required to do soft parity
generation.  A particularly critical control structure is the command
packet (CCB) which is sent to a SCSI device.  Errors can occur where
a command is transformed to another command because of a switched bit
in a CCB (Command Control Block).  Therefore, the CCB is a prime
target for soft parity checking.

      An interesting characteristic of a CCB is the fact that some
fields (up to 85% of some commands) are constant.  For example,
reserved (unused) fields that must be zero, the op-code, and fields
that are defined but unused (always zero) by a particular product,
are constant across successive executions of a particular command.
By identifying the location of the constant fields within the CCB,
pre- calculating parity across these constants, and storing this
information along with the CCB's control structure, a great deal of
time (up to 85% for some SCSI commands) can be saved when generating
parity for a CCB.

      The figure shows the SCSI read command which will be used for
an example to describe the concept.  Bytes 00 through Bytes 09 are
the SCSI CCB.  Bytes 10 and 11 are Partial Results bytes stored in a
controller or device for each command.  The Partial Results are
calculated for bytes in a command that do not change.  A unique piece
of code shown in Table 1 is run at IML time to perform this
operation.  This code is "hard coded" to know which fields are
constant.  For the Read command these are Bytes 00, 01, 06, and 09.
The code then...