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

Peter Fales psfales at cbnewsc.ATT.COM
Thu Aug 24 13:30:53 AEST 1989


In article <947 at icus.islp.ny.us>, lenny at icus.islp.ny.us (Lenny Tropiano) writes:
> 
> 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 ... 

Well, I am not quite as brave as Lenny, but I wanted to try this out too.
Since I didn't feel comfortable writing a new VHB on my hard disk, I needed
some way to patch the copy of the VHB read in by the kernel.  It probably
could be done with the kernel debugger, but I found that an easy way was
to pick a random installable device driver and add the line

	gdsw[0].dsk.step = 14;
	
to the installation routine.   This seemed to work because when I do
a GDGETA on the disk, the value returned is 0 before installing this 
driver and 14 afterwords.

However, my results were much the same as Lenny's.  I tried a couple
of different benchmarks:  1) running compress on an 800K file keeps
the disk busy for about 1 minute.  Changing the step rate made no
measurable difference.  2) Trying to come up with test that would require
many long seeks, I tried doing a dd from /dev/rfp001 to /tmp/jnk.
Surprisingly, this did not result in a particularly noisy disk, but it
did take about 7 minutes to run.  And again the difference between the two
times with different step rates was within the noise.

Finally, I tried the first test again with a step rate of 13.  According
to the manual, this is a 6.5 millisecond step rate as opposed to the
35 MICROsecond step rate used when the step parameter is zero.  Again
no difference.

So far, the bottom line seems to be:  If you don't need the larger disk,
the WD2010 is not going to help performance.  If any one else gets 
different results, please let us know.

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



More information about the Unix-pc.general mailing list