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

[Peter Fales]

> 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

This is the table for the WD1010, however this is one case where the WD2010
differs from the 1010.  For the 2010, the last two table entries should be:

14	3.2 microseconds (I am sure of this)
15 	6.4 microseconds (I think, this is from memory)

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

Right, this is why Lenny et. al, think it may be possible to improve seek
performance.  I have a drive in my DOS-PC that does not begin moving the
head until ALL the step pulses have been received.  In this case, it
takes about 35 milliseconds to get 1000 step pulses out with a 35 usec
step rate.  If you could cut this down to 3.2 milliseconds by using step
rate 14, it would cut about 30 milliseconds off your maximum seek.  In 
the case of the DOS machine, I was able to get my average access time
down from about 85 to 65 milliseconds by reburning my controller ROM
to use the fastest step rate available on the controller.

On the other hand, I suspect that my Miniscribe 6085 begins moving the
head as soon as the first step pulse is received.  Since the step pulses
are always keeping ahead of the head movement, it doesn't make much difference
whether they come in at 35 or 3.2 microseconds each.  This MAY explain
why I get no difference between step rate 0 and step rate 14.  What it
DOESN'T explain is why I get no reduction in performance by using one 
of the very slow rates like 7 or 13.

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

You are right that you can't use GDSETA, but my results were not so dramatic.
As  soon as I ran the program, my prompt came back, but any attempt to
execute a command resulted in no output and another prompt.  The only way
I could recover was to reboot.

> So, if you want to diddle the step rate, use:
> 1. iv -u (with a reboot)

This is the method I have been using, complete with the reboot.

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

Wow, does this explain why changing the value even in the VHB does not 
affect anything?  How about it JCM?

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