[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Vista Support Software

Vladimir Ivanov wrote:


Ok, we're quite OT now. :-)


On Mon, 30 Apr 2012, Michael J. Mahon wrote:


Vladimir Ivanov wrote:
The really sad thing is that the single byte XOR checksum of the sector data is simply not enough. When there is a source of noise (including unreliable data and/or reading process) it is so easy to get "good" sector which is actually garbage, that it's not even funny. 


This is certainly true when the channel is perturbed by random noise.

Fortunately, when a sector is being mis-read due to marginal head
positioning, speed, or very localized media problems, the perturbation
is not random, and the checksum is relatively strong when combined
with field delimiter checks.  Put another way, most I/O errors result
in relatively stable (wrong) checksums, not equidistributed checksum
values.

If one were reading a sector which had weak or non-existent recording
over many nibbles, or an equivalent duration of loss of media contact,
then I would expect to see "noise-like" checksums, otherwise, I would
not expect much nondeterminism in the read channel.

Do you have any statistics on mis-reads (of once-valid sectors) that
resulted in good checksums?
From distant usage in the past, copying a disk with errors might still fail even if copious amounts of retry and (desperate) manual intervention somehow led to correct checksum for a single revolution. 

True--and the more errors there are within a sector, the more
"noiselike" they become in their effects.

Clearly, the relatively weak checksum is intended to work for
a relatively reliable read channel--which is the norm for the Disk ][.
From recent experience extracting image data directly from raw RD signal, mispositioning the head enough (i.e. crosstalk) and proper phase of Moon results in morphing of sector data between two stable states with their correct checksums over many revolutions, only one of which is the proper. That with correct field markers. I have a log warning for this type of event (changed sector data) and I've seen it, to my surprise, more than I expected. 

This is quite unusual, particularly for the delimiters to line up,
given the desynchronized soft sectoring from track to track.  In fact,
just the normal speed fluctuations would make it all but impossible
to write two adjacent tracks that maintained delimiter sync.


It would be interesting to write sectors with a longer (internal)
checksum, then perturb head loading, speed, and alignment and see
what fraction of "good reads" resulted in corrupted data.  My purely
anecdotal evidence is that this is quite rare.
The XOR checksum is only 6 bits per 342 nibbles. Quite non-linear for a simple analysis, including the sequencer rule for MSB=1, but obviously very little in terms of data excess.
There's also the sparse nature of the nibble -> 6-bit decode table and whatever is stuffing the "invalid" but possible 128-64=64 entries is just making this more mind-boggling. :-) IIRC, although the table might have indication for incorrect nibbles in the stuffing, the tight loop of RWTS cannot have the luxury of checking it. 

Right--though I wonder if two cycles could be found for a conditional
branch...  ;-)  Maybe instead of a counted loop, the loop should be
terminated by a delimiter nibble, a special case of which is the
error case...


Come to think of it, the decades-long experience of Apple II users,
in which the Disk ][ performed as a robust storage medium, confirms
that the one-byte checksum, plus field delimiter checks, delivered
excellent reliability at very low computational cost.  If this had
not been the case, the Apple II would have acquired the reputation
of an unreliable computing platform.
My point was totally from archival point of view - the uncertainty that an image is really done "right" by automated means when the media is 30+ years old and close to extinction. Even if one has two or more physical copies of the media, they're possibly distinct enough to be useful for a naive bit comparison. 

True.  And I agree that severly degraded recordings violate the
assumptions of the Disk ][ error checking strategy.  Whenever a
lot of retries are needed to achieve a "good" read, manual
inspection should be done to check for reasonable data, with
comparison to another disk being the gold standard.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."