HDD Implementation Of RC (Read Continuous)

Tom Gardner tom.gardner at syquest.com
Tue Nov 26 17:49:55 PST 1996


* From the SCSI Reflector (scsi at symbios.com), posted by:
* tom.gardner at syquest.com (Tom Gardner)
*
     Gerry:
     
     Thanks for the input; am i to take this as a fact that seagate 
     products do transmit synthetic data or that this is just your belief?
     
     What do you suppose yr drives do when the have a problem in the system 
     area (e.g., reading a FAT) - this is a real issue since the drive has 
     no way of knowing when its transmitting audio, video, files, system,
     etc.
     
TomG
______________________________ Reply Separator _________________________________
Subject: RE: HDD Implementation Of RC (Read Continuous)
Author:  Gerry Houlder <Gerry_Houlder at notes.seagate.com> at Internet
Date:    11/18/96 10:50 AM


* From the SCSI Reflector (scsi at symbios.com), posted by: 
* Gerry Houlder <Gerry_Houlder at notes.seagate.com>
*
Tom's main question was:
     
>The question is are HDD's which support RC really sending bad data or 
>just using the RC as a global switch to minimize the length of error 
>recovery.  
     
I believe most drive implementations will follow the letter of the definition, 
meaning that raw data from the drive will be sent to the host with no attempt 
to recover errors or even re-read bad headers (in this case a block of 
"fabricated" data is returned for that block). This conforms to the letter of 
the Standard.
     
This mode was created for video applications where raw video data
was read from disk and dumped to a screen. The idea was that even a large 
chunk of bad data would only be a brief glitch on a video screen and may not 
even be noticed if both the previous and following frames were good. The 
video industry doesn't operate this way, however, making this feature pretty 
worthless.
     
The combination of MPEG coding and data compression is used to keep the 
transfer rates low. It also means that even one or two bad bits can cause 
remnants that can persist for many frames. Video servers have to be a lot 
smarter
to make sure that bad data isn't used.
     
Video customers I have talked to are willing to tolerate a higher error rate, 
but if a
bad block is sent to the host there should be a CHECK status to indicate bad 
data
was sent. The host can then use sense data to identify the bad block and won't 
use
it. This usually means the controller will chose to redisplay the previous 
frame in place
of the frame with a bad block in it. There are no standard settings to do this 
exactly.
Perhaps the standards committee should be inventing one?
     
Part of the problem is lack of attendance at standards meetings by video 
companies.
I get the feeling that the video industry treats this area as a "trade secret", 
when each
company doesn't want to standardize techniques they spent a lot of effort 
overcoming.
They see this as helping their competitors more than helping themselves. Another
possible reason is that video servers are mostly a niche market served by small 
specialty companies. Small companies are far less active in standards activity 
than
larger, more established companies.
*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com
*
* 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