WD2010 / No ECC

[was-John McMillan]

In article <1182 at mitisft.Convergent.COM> dold at mitisft.Convergent.COM (Clarence Dold) writes:
:
>Indeed, there is no ECC support in the kernel, and it would require a 
>reformat of the disk if it did.
>The chip merely informs the system of an ECC error.  Some systems leave
>a 'Track Buffer' intact, for the 2010 to make the change, others must
>locate the data, wherever it has been transferred, and make the change there.

	The above description follows what the WD2010 documents
	indicate IFF the chip is running in ECC mode -- ie., with
	the appropriately re-formatted disk and its 4 byte ECC
	checksums instead of the 2 byte CRC checksums.  The
	chip, as noted in the first sentence, is NOT put in this
	mode.

>I don't recall the detail, but detecting the presence of a 2010 vs a 1010
>on a machine that could have either was done by setting a cylinder register
>to 1200, then reading it back.  A WD1010 would modulo 1024 the register,
>a WD2010 would return 1200.

	I tried this 6 months ago: apparently my test was wrong --
	mea culpa ];-(

	The Kernel Debugger, after loading 0xff into the HICYL register
	reads back 0x03.  Thanks for getting me back on track.  (This
	may also slay an otherwise healthy system, so reset it to its
	original values before departing, please!)

:

>The PLL isn't on the chip, it's external.
>The chip itself might be better...
	
	Agreed: the Data Separator PLL is off-chip.  I had wrongly
	presumed the MFM decoder also used a PLL, but I now see the
	chip's notes says the decoder's data is clocked in bit-by-bit.

	Since it ain't the ECC and it ain't the PLL, WHAT IS the
	difference between the WD1010 & WD2010's data error rates?
	Is it just chip-to-chip differences -- ie., might changing
	to a new WD1010 "fix" problems?  It there a speed/sensitivity
	difference between the two chips?  Is the data separator's
	output marginal for a 1010, but fine for the 2010?  I doubt
	this can be cleared up!
	
>Try setting the Step Rate in an iv.desc file to 14 instead of 0, 
>then iv -u the disk.  No loss of data, just a 20% increase in seek performance
>on 28mSec disks.

	Others have suggested this:  Personally, I just can't face
	the risk....   Gutless Me!  (Except in girth.)

john mcmillan	-- att!mtunb!jcm