Xref: utzoo comp.sys.att:7477 unix-pc.general:3672 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!att!cbnewsc!psfales From: psfales@cbnewsc.ATT.COM (Peter Fales) Newsgroups: comp.sys.att,unix-pc.general Subject: Re: Step rate change (WD2010) Some Benchmarks(was Re: WD2010 / No ECC) Summary: It works! Message-ID: <2903@cbnewsc.ATT.COM> Date: 2 Sep 89 18:27:40 GMT References: <1624@mtunb.ATT.COM> <1182@mitisft.Convergent.COM> <594@uncle.UUCP> <1648@mtunb.ATT.COM> Organization: AT&T Bell Laboratories Lines: 61 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 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@att.com work: (312) 979-8031