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

[John B. Milton]

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

I had my doubts, now I know. Changing the step rate WILL NOT increase the
step rate performance, only decrease it. This is a table of step rate values
and time delays:

 0	35us  (microseconds)
 1	0.5ms (milliseconds)
 2	1.0ms
 3	1.5ms
...
12	6.0ms
13	6.5ms
14	7.0ms
15	7.5ms

As a point of reference, the disk rotates at 3600 rpm, or 60 rps, 60 Hz.
1/60th of a second = 0.01666667 or about 17ms.

With the type of drives we use on the UNIXpc (ST 506 interface), the drive is
not told which cylinder to put the head on, but rather when to make ONE step,
and in which direction to make it. The same as for floppy drives. The HDC
(Hard Disk Controller, WD1010-05 or WD2010-05) can do seeks (step to the right
cylinder) in two ways. One is to set the cylinder you want, then issue a SEEK
command. This will send all the step pulses to the drive with the requested
delay between each pulse, then show complete. The drive may or may not ACTUALLY
be done seeking at this point, but the HDC shows complete and ready for the
next command. The second way to seek is to set the cylinder and the sector you
want to read or write, then issue the READ or WRITE command. The HDC will
compare the cylinder you want with the one the head is currently on, then issue
the appropriate number of steps in the right direction. The HDC will then WAIT
for the drive to show complete on the SC (Seek Complete) pin of the HDC. Some
drives will take a long time to show complete, others will show complete more
quickly, it all depends on how fast your drive can actually move the head. This
second kind of seeking is called an implied seek.

So, the value given to the HDC does not control how fast the drive seeks, only
how fast the step pulses are sent to the drive. The main reason the parameter
is available at all, is to deal with very old drives that can't take fast step
pulses, or can't tell the outside world when they're actually done with a
given seek. I have played around with several older hard drives, and I have
never found one that needed a slower step rate. Drives that DO need slow step
rates generally WON'T WORK AT ALL with fast step rates. As far as newer, more
intelligent drives go, the quicker you can send all the steps to the drive,
the quicker the drive can figure out where you really want the head. Once it
knows where you really want the head, it can seek most efficiently directly
to that position.

There is one other way to seek the drive. This method is called recallibrating.
The command in the HDC is RESTORE. With this seek method, the direction is
set towards lower numbered cylinders, and step pulses are sent to the drive
until the head gets to track 0. There is a special signal from the drive,
usually corresponding to an actual sensor, which is used to indicate when the
head is on track 0. The RESTORE command is used to get the head to a known
position, when the position of the head is not known or is suspect. After each
step pulse is sent to the drive, the HDC waits for the drive to show complete,
then tests the track 0 line to see if the head is all the way back. On most
drives this makes a very loud noise, because the head moves a short distance,
stops, and repeats. The RESTORE command is used when the machine is reset, or
on the UNIXpc, when there is a read error. If a hard drive shows not ready or
write failure during any command (including RESTORE), then the command is
aborted.

Now, for you intrepid folks who are out there writing seek testing programs
using the ioctl(f,GDSETA,gdctl) technique, WATCH OUT! The GDSETA interface
was providied ONLY FOR FLOPPY DRIVES!!! It was inteneded for programmers
who want to access non-UNIXpc (VHB) floppies (like Mtools). When a GDSETA
ioctl() is issued, the drive sizes in the "params" are used to reconfigure
the in-memory slot 0 partition table entry. All other partition table entries
for the specified drive from 1 to MAXSLICE are zerod. This is not good. The
swap and all file system partitions simply disappear. The next time there
is a page fault, the offending process is killed. When init page faults, it
is killed, UNIX pitches a bitch and panics.

So, if you want to diddle the step rate, use:
1. iv -u (with a reboot)
2. a loadable driver
3. nlist()/lseek()/read()/write() on /dev/kmem

but do not use GDSETA.

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!, and RESTOREs only happen when the disk gets up to 10
restries on a bad spot, or during formatting. These are my method #3 results:

Max cylinder: 67608575
Old step rate was 0
Seeks per step rate: 1000
Step rate 0 (0):148
Step rate 1 (1):198
Step rate 2 (2):185
Step rate 3 (3):178
Step rate 4 (4):134
Step rate 5 (5):140
Step rate 6 (6):157
Step rate 7 (7):140
Step rate 8 (8):144
Step rate 9 (9):135
Step rate 10 (10):134
Step rate 11 (11):134
Step rate 12 (12):134
Step rate 13 (13):136
Step rate 14 (14):134
Step rate 15 (15):133
step reset to 0 (0)

Quite frankly, I think this dead horse has been beat.
I know I am
'night folks.

Anybody want to stay up all night and re-boot their machine 16 times?

John
-- 
John Bly Milton IV, jbm at uncle.UUCP, n8emr!uncle!jbm at osu-cis.cis.ohio-state.edu
(614) h:294-4823, w:785-1110; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!