HDD Implementation Of RC (Read Continuous) SCSI

Pat LaVarre LAVARRE at iomega.com
Sun Nov 17 15:02:52 PST 1996


* From the SCSI Reflector (scsi at symbios.com), posted by:
* Pat LaVarre <LAVARRE at IOMEGA.COM>
*
I never exactly understood the purpose of
the RC bit either.

To date, we've pointed customers who think
they might like this bit towards a series of
vendor-specific controls that in effect
involve the host any time the drive
experiences an error gross enough to force
it to skip a rev.

The thinking is that the host can then tell
the drive to skip the sectors that passed
under the heads as the last command ended
and move on.

We never comfortably settled on a level at
which, to quote the standard, it would be OK
to "fabricate" data.  For instance, if a
shock makes the heads skate, can we really
just send whatever happens to be in the
buffer?

By and large, the people who want the read
speed made possible this way want a
comparable write speed.  For products in
which write speed is comparable to read
speed to begin with, a bit to let reads
catch up with writes doesn't buy much.

In the mass market, applications have
difficulty promising that the O.S. won't
suddenly come out and ask for some indexing
info, or some form of compression, that
can't cope with bit loss.  Particularly if
someone takes a piece of media from one
machine to another.

The only positive development I can think of
in this arena is the video world's movement
towards frame-based compression.  Given an
algorithm in which a bit error scrambles
only one frame rather than the entire rest
of the stream, then intentionally unreliable
data channels (: like the IDE bus, for
example :) become suddenly more viable
alternatives.

Hope someone comments on this.

Cheers.   Pat LaVarre

*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com




More information about the T10 mailing list