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

[Peter Fales]

Thanks to the combined efforts of a number of net folks, I
finally succeeded in getting my WD2010 to accept the faster step rate.

The hypothesis that step rate is only set in the ROM code and then
never touched unless there is a disk error seems to be correct.  I
was able to get my disk to use a step rate of 14 (3.2 microseconds)
which showed a significant improvement over the default rate of 0 (35 
microseconds) according to Lenny's exerciser.  I was also able to get
it to use a step rate of 13 (6.5 MILLIseconds) which, as expected,
produced a radical decrease in disk performance.  6.5 milliseconds
is a frequency of about 160 Hz, and I could hear the disk humming
as it slooooowwwwwlllllyyyy  moved the heads around the disk.

To get it to work, I changed the step rate parameter in the VHB
(using iv -u), then I had to figure out how to get the system to
execute a RESTORE.  I added the following lines to the "devrom" 
driver posted a while back (though any installable driver should
work, even one custom written for this purpose).

#include <sys/gdisk.h>

rominit()
{
	HD_BASE[H_COMMANDREG] = W_RESTORE+gdsw[0].dsk.step;
}

All this is doing is blasting out a RESTORE when the driver 
is installed as part of system initialization. 
I suspect that I may be on somewhat shaky ground here, because I
do no special checks to ensure that the WD2010 or anything else
in the system is not already busy.  But it is quick, easy, and seems
to work.  Maybe our kernel guru (hi JCM!) can provide more information.

I also had to make some minor changes to the INSTALL file to
tell masterupd that an init routine is now being provided, and to
ensure that masterupd is always run, even if /dev/rom already 
exists.  I can hear the RESTORE happen just after the "lddrv -a"
is executed, and there seem to be no unwanted side effects.

Once I made all the above changes, my benchmarks all of a sudden
started working faster.  My results from "testit" are summarized
here:

			Step Rate 0	Step Rate 14
		
long			9		7
random			5		4
converging		1232		1071
sequential		486		485

I haven't noticed much difference in the way the system behaves, but
I may try to do some comparisons on tasks like compiling large files
to see if it has any effect.

Thanks everyone!

-- 
Peter Fales			AT&T, Room 5B-420
				2000 N. Naperville Rd.
UUCP:	...att!peter.fales	Naperville, IL 60566
Domain: peter.fales at att.com	work:	(312) 979-8031