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

[Lenny Tropiano]

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.
|>
|>Ignore any significance in my signature.
|>I don know nuddin about the Unix PC.
|>The iv part, in particular, is untried, untested, and subject to failure.
|>(but somebody that is well backed up should tell us if it works.)
|>

Ok, call me brave, but I had to try it...  It sorta was a test for my WD2010
anyhow.   I have another UNIX pc (icusdvlp) that I use for such occasions,
I never subject my main machine (icus) to anything this terrible (well, almost
never) ...

I proceeded tonight to try what Clarence Dold from Convergent mentioned
above, change the step rate, rewrite the VHB and see what difference that
will make, if any.

This is how I went about it.

First I had to see if the WD2010 that I got a while back (not from Thad,
but thanks to him he finally pushed me to install it and test it ...) was
going to work.  I installed it in my UNIX pc, 40MB, 2M RAM, pretty much
vanilla, except that Gil last weekend did the motherboard wiring work on the
machine to make it two (2) hard drive *ready*. (Thanks) When I find a need for
two there, he'll make the upgrade board and we'll be in business.  

I powered up the machine in diagnostics, and ran the usual disk tests,
sequential seek, random seek, etc...  All tested just fine.  Step one was
verified, the WD2010 worked!

Now I booted the machine with the floppy boot disk, and then the floppy
filesystem so I could have a single user (very stripped down) floppy UNIX.
(Version 3.51).

Here's a very close representation of what I did ...  (excuse me if there
are any typos).

# /etc/umount /dev/fp002
# /etc/fsck -s /dev/rfp002		| I have /etc/fsck on my Floppy UNIX
					| and I figured I would salvage the
					| freelist while I was at it.
...
# /etc/mount /dev/fp002 /mnt
# cp /mnt/bin/dd /bin			| copy some utilities we'll need for
# cp /mnt/bin/time /bin			| benchmarking ...
# /etc/umount /dev/fp002

# /bin/time /bin/dd if=/dev/rfp002 of=/dev/null bs=100k

	| I have standard partitioning for multi-user (in other words,
	| swap is 5MB and the rest of the 40MB drive is /dev/fp002 (slice 2)

359+1 records in
359+1 records out

real	1:39.7
sys	   0.0
user	   2.9

	| I did this for several iterations, and 100k make the seeking rather
	| fast... without a buffer it would have taken a VERY long time

	| Iteration #2

real	1:39.4
sys	   0.0
user	   3.1

	| Iteration #3

real	1:39.6
sys	   0.0
user	   3.1

	| Iteration #4

real	1:39.7
sys	   0.0
user	   3.0

...

	| Ok, now the fun and *dangerous* stuff ...   Jumping into in 
	| chartered territory.  

# mount /dev/fp002 /mnt			| get the hard disk ready ...
# PS1="## "				| just signify the last shell with
					| a different prompt
## /mnt/etc/chroot /mnt /bin/sh		| chroot(2) to the Hard disk
# iv -dv /dev/rfp000 > HD.desc

	| Here I wrote out the description table (current one) of the VHB
	| and BBT (bad block table).   This is important, so when you write
	| the new VHB it matches exactly, except for the item we're about
	| to change...

# /bin/ed HD.desc
/step
steprate	0
s/0/14/p
steprate	14
w
131

	| Ok, we changed the steprate to 14 like Clarence suggested ...
	| Time to hold my breath..

# iv -uv /dev/rfp000 HD.desc
Device type: HD	  Name: WINCHE
Cylinders: 1024   Heads: 5	Sectors: 17

* Phase 1 - Initializing Internal VHB
* Phase 2 - Writing out new VHB
* Phase 3 - Writing out new BBT
* Phase 4 - Allocating download areas.
	    Writing out new loader.
	    3 partitions, 23 blocks for loader, Bad Block Table Allocated

	| Ok, everything seems normal yet.  Ahhhhhh....

# exit
## /etc/umount /dev/fp002
## /etc/fsck /dev/rfp002
...
## PS1="# "

	| Time to repeat above tests ...

# /bin/time /bin/dd if=/dev/rfp002 of=/dev/null bs=100k
359+1 records in
359+1 records out

real	1:40.1
sys	   0.0
user	   3.1

	| Hmmm, nothing ... no improvement, so far longer ...

	| Iteration #2

real	1:40.2
sys	   0.0
user	   3.0

	| Iteration #3

real	1:41.0
sys	   0.0
user	   3.2

	| Iteration #3

real	1:40.1
sys	   0.0
user	   3.0


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 differnce 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 ... 

						Take care ...
						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