Xref: utzoo unix-pc.general:3627 comp.sys.att:7387 Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!bu-cs!spdcc!rayssd!icus!lenny From: lenny@icus.islp.ny.us (Lenny Tropiano) Newsgroups: unix-pc.general,comp.sys.att Subject: Re: Step rate change (WD2010) Some Benchmarks ... **IT WORKS!** Summary: I goofed ... Ok, shoot me! Here I am following up to my own article! Keywords: WD2010, step-rate, faster! Message-ID: <948@icus.islp.ny.us> Date: 25 Aug 89 02:35:19 GMT References: <1624@mtunb.ATT.COM> <1182@mitisft.Convergent.COM> <947@icus.islp.ny.us> Reply-To: lenny@icus.islp.ny.us (Lenny Tropiano) Organization: ICUS Software Systems, Islip, New York Lines: 78 In article <947@icus.islp.ny.us> lenny@icus.islp.ny.us (Lenny Tropiano) writes: |>In article <1182@mitisft.Convergent.COM> dold@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. |>|> |> ... [ a bunch of stuff on how-to do it all left out, plus some erroneous hypotheses ] ... |>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 difference 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 ... |> As people pointed out, there were two things inherently *WRONG* with my original hypothesis about the seek rates ... Firstly I was testing I/O throughput, and not seeking ... at least not major seeks, it was track to track seeking... Secondly, something I thought about after Peter Fales mentioned about changing the gdsw tables in memory to 14, what I neglected to do was REBOOT! That means if I changed the VHB, the step-rate information would have remained the same in core memory... At least this is what I assume ... I doubt the kernel rereads the VHB and rewrites the gdsw tables. Well after thinking that through, I wrote a simple hack (for those who want the disk exerciser, let me know) that just lseek()'d to the first position of the hard disk (/dev/rfp000) [ie. 0] and the last position of the hard disk ... [ie. (maxcyls*maxheads+maxheads) * sectorsize * sectors-per-track ] ^^ should be = 512 ^^ should be = 17 I didn't really seek to the total end, I was about one sector off (512 bytes) and then I read 512 bytes in ... I did this in a loop for 100 iterations, averaged all the iterations using the times(2) system call. Basically I called times(2) before the lseek() and read at the the beginning, and after the lseek() and read at the end ... I subtracted time_after and time_before and averaged them over the 100 iterations. I ran this program 5 times (100 iterations each) in step-rate 0, and step-rate 14. Wow! There was a difference. Here are the average results ... WD2010 installed Step-rate = 0 Iteration #1 avg time = 51 Iteration #2 avg time = 51 Iteration #3 avg time = 51 Iteration #4 avg time = 51 Iteration #5 avg time = 51 Step-rate = 14 Iteration #1 avg time = 37 Iteration #2 avg time = 36 Iteration #3 avg time = 37 Iteration #4 avg time = 37 Iteration #5 avg time = 37 So on the average it was 14 time units (60th of a second) faster ... That's a 27.4% increase in seek performance, Thanks Clarence! It seems faster overall anyhow ... I wonder how it will work on those 20 megger's out there with 67ms seek time ... I'd like to hear those success stories too! -Lenny -- Lenny Tropiano ICUS Software Systems [w] +1 (516) 589-7930 lenny@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