Step rate change (WD2010) Some Benchmarks ... **IT WORKS!**

[Lenny Tropiano]

In article <947 at icus.islp.ny.us> lenny at icus.islp.ny.us (Lenny Tropiano) writes:
|>In article <1182 at mitisft.Convergent.COM> dold at mitisft.Convergent.COM 
|>(Clarence Dold) writes:
|>...
|>|>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.
|>|>
|>
... [ a bunch of stuff on how-to do it all left out, plus some erroneous
      hypotheses ] ...

|>Nada .. Oh well, for this long winded explanation, essentially you
|>can't improve the seek performance by 20% ... In fact it might just
|>be hindering it, but for 1 second difference that could mean just about
|>anything.   If someone has a better test for seeking, let me know, I'm
|>willing to try this again under different stress test values ... 
|>

As people pointed out, there were two things inherently *WRONG* with my
original hypothesis about the seek rates ...  Firstly I was testing
I/O throughput, and not seeking ... at least not major seeks, it was 
track to track seeking...  Secondly, something I thought about after
Peter Fales mentioned about changing the gdsw tables in memory to 14,
what I neglected to do was REBOOT!   That means if I changed the VHB,
the step-rate information would have remained the same in core memory...
At least this is what I assume ...  I doubt the kernel rereads the
VHB and rewrites the gdsw tables.

Well after thinking that through, I wrote a simple hack (for those
who want the disk exerciser, let me know) that just lseek()'d to the
first position of the hard disk (/dev/rfp000) [ie. 0] and the last
position of the hard disk ...  [ie. (maxcyls*maxheads+maxheads) * 
sectorsize * sectors-per-track ]
^^ should be = 512      ^^ should be = 17

I didn't really seek to the total end, I was about one sector off (512
bytes) and then I read 512 bytes in ...   I did this in a loop for
100 iterations, averaged all the iterations using the times(2) system
call.

Basically I called times(2) before the lseek() and read at the the 
beginning, and after the lseek() and read at the end ...  I subtracted
time_after and time_before and averaged them over the 100 iterations.
I ran this program 5 times (100 iterations each) in step-rate 0, and
step-rate 14.  Wow! There was a difference.

Here are the average results ...
WD2010 installed
Step-rate = 0

Iteration #1 avg time = 51
Iteration #2 avg time = 51
Iteration #3 avg time = 51
Iteration #4 avg time = 51
Iteration #5 avg time = 51

Step-rate = 14
Iteration #1 avg time = 37
Iteration #2 avg time = 36
Iteration #3 avg time = 37
Iteration #4 avg time = 37
Iteration #5 avg time = 37

So on the average it was 14 time units (60th of a second) faster ...
That's a 27.4% increase in seek performance, Thanks Clarence!

It seems faster overall anyhow ...  I wonder how it will work on
those 20 megger's out there with 67ms seek time ...

I'd like to hear those success stories too!

-Lenny
-- 
Lenny Tropiano             ICUS Software Systems         [w] +1 (516) 589-7930
lenny at icus.islp.ny.us      Telex; 154232428 ICUS         [h] +1 (516) 968-8576
{ames,pacbell,decuac,hombre,talcott,sbcs}!icus!lenny     attmail!icus!lenny
        ICUS Software Systems -- PO Box 1; Islip Terrace, NY  11752