Xref: utzoo comp.sys.att:7401 unix-pc.general:3636 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!sun-barr!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: WD2010 and WD1010 are different Keywords: iv, VHB, WD2010, WD1010, disk controller, step rate, faster? WARNING Message-ID: <2729@cbnewsc.ATT.COM> Date: 27 Aug 89 18:49:45 GMT References: <1624@mtunb.ATT.COM> <1182@mitisft.Convergent.COM> <594@uncle.UUCP> Organization: AT&T Bell Laboratories Lines: 82 > 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@att.com work: (312) 979-8031