Step rate change (WD2010) Some Benchmarks(was Re: WD2010 / No ECC)

was-John McMillan jcm at mtunb.ATT.COM
Sat Sep 2 01:33:51 AEST 1989


In article <2729 at cbnewsc.ATT.COM> psfales at cbnewsc.ATT.COM (Peter Fales) writes:
:
>
>> I tried #3, and didn't get any change in seek time. It may be that the step
>> rate is only set once, when the VHB is read during the boot process. The step
>> rate can only be set with a RESTORE or SEEK command, the other commands do
>> not have step rate delay bit fields in them. Becuase of this, changes in the
>> step rate field in the gdws table may not take effect until the seek SEEK or
>> RESTORE command. As far as I can tell, there are no SEEK commands done, except
>> when formatting a disk!
>
>Wow, does this explain why changing the value even in the VHB does not 
>affect anything?  How about it JCM?

Thanks, Pete...

The SEEK command is only used during formatting.  The RESTORE command
is used during formatting and upon the 10th (GDRETRIES-5) retry.

Unfortunately, you cannot easy force the former SEEK as, I believe,
the kernel and the leather restraints prevent re-formatting your
root drive.

Jumping up and down on a bad sector is questionable, and -- despite
our preferences -- some of us lack any bad disk sectors.  (Dysfunctional
brain sectors are discussed elsewhere.)

Soooo, a quick perusal of the LOADER indicates the only RESTORE it
performs is during an error retry -- and IT doesn't insert a rate,
presumably setting it to rate[0] == 35 us.

This leads to an awkward conclusion that (1) the ROM code is setting
the rate [?] and/or (2) it is only being set in systems lucky enuf
to have bad sectors read at least 10 times... OR *MOST LIKELY* one
of those bad brain sectors just kicked in and I've mist the target.

Thanks again, Pete....  more to figure out... Be back later......

john mcmillan	-- att!mtunb!jcm

PS: WD2020-05 StepRate[15]== 16us, not 6.4us as suggested elsewhere.



More information about the Comp.sys.att mailing list