Xref: utzoo unix-pc.general:3614 comp.sys.att:7366 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!icus!lenny From: lenny@icus.islp.ny.us (Lenny Tropiano) Newsgroups: unix-pc.general,comp.sys.att Subject: Step rate change (WD2010) Some Benchmarks ... (was Re: WD2010 / No ECC) Summary: I'm real BRAVE! Keywords: iv, VHB, WD2010, WD1010, disk controller, step rate, faster? Message-ID: <947@icus.islp.ny.us> Date: 23 Aug 89 00:17:01 GMT References: <1624@mtunb.ATT.COM> <1182@mitisft.Convergent.COM> Reply-To: lenny@icus.islp.ny.us (Lenny Tropiano) Organization: ICUS Software Systems, Islip, New York Lines: 175 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. |> |>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 anyhow. I have another UNIX pc (icusdvlp) that I use for such occasions, I never subject my main machine (icus) to anything this terrible (well, almost never) ... I proceeded tonight to try what Clarence Dold from Convergent mentioned above, change the step rate, rewrite the VHB and see what difference that will make, if any. This is how I went about it. First I had to see if the WD2010 that I got a while back (not from Thad, but thanks to him he finally pushed me to install it and test it ...) was going to work. I installed it in my UNIX pc, 40MB, 2M RAM, pretty much vanilla, except that Gil last weekend did the motherboard wiring work on the machine to make it two (2) hard drive *ready*. (Thanks) When I find a need for two there, he'll make the upgrade board and we'll be in business. I powered up the machine in diagnostics, and ran the usual disk tests, sequential seek, random seek, etc... All tested just fine. Step one was verified, the WD2010 worked! Now I booted the machine with the floppy boot disk, and then the floppy filesystem so I could have a single user (very stripped down) floppy UNIX. (Version 3.51). Here's a very close representation of what I did ... (excuse me if there are any typos). # /etc/umount /dev/fp002 # /etc/fsck -s /dev/rfp002 | I have /etc/fsck on my Floppy UNIX | and I figured I would salvage the | freelist while I was at it. ... # /etc/mount /dev/fp002 /mnt # cp /mnt/bin/dd /bin | copy some utilities we'll need for # cp /mnt/bin/time /bin | benchmarking ... # /etc/umount /dev/fp002 # /bin/time /bin/dd if=/dev/rfp002 of=/dev/null bs=100k | I have standard partitioning for multi-user (in other words, | swap is 5MB and the rest of the 40MB drive is /dev/fp002 (slice 2) 359+1 records in 359+1 records out real 1:39.7 sys 0.0 user 2.9 | I did this for several iterations, and 100k make the seeking rather | fast... without a buffer it would have taken a VERY long time | Iteration #2 real 1:39.4 sys 0.0 user 3.1 | Iteration #3 real 1:39.6 sys 0.0 user 3.1 | Iteration #4 real 1:39.7 sys 0.0 user 3.0 ... | Ok, now the fun and *dangerous* stuff ... Jumping into in | chartered territory. # mount /dev/fp002 /mnt | get the hard disk ready ... # PS1="## " | just signify the last shell with | a different prompt ## /mnt/etc/chroot /mnt /bin/sh | chroot(2) to the Hard disk # iv -dv /dev/rfp000 > HD.desc | Here I wrote out the description table (current one) of the VHB | and BBT (bad block table). This is important, so when you write | the new VHB it matches exactly, except for the item we're about | to change... # /bin/ed HD.desc /step steprate 0 s/0/14/p steprate 14 w 131 | Ok, we changed the steprate to 14 like Clarence suggested ... | Time to hold my breath.. # iv -uv /dev/rfp000 HD.desc Device type: HD Name: WINCHE Cylinders: 1024 Heads: 5 Sectors: 17 * Phase 1 - Initializing Internal VHB * Phase 2 - Writing out new VHB * Phase 3 - Writing out new BBT * Phase 4 - Allocating download areas. Writing out new loader. 3 partitions, 23 blocks for loader, Bad Block Table Allocated | Ok, everything seems normal yet. Ahhhhhh.... # exit ## /etc/umount /dev/fp002 ## /etc/fsck /dev/rfp002 ... ## PS1="# " | Time to repeat above tests ... # /bin/time /bin/dd if=/dev/rfp002 of=/dev/null bs=100k 359+1 records in 359+1 records out real 1:40.1 sys 0.0 user 3.1 | Hmmm, nothing ... no improvement, so far longer ... | Iteration #2 real 1:40.2 sys 0.0 user 3.0 | Iteration #3 real 1:41.0 sys 0.0 user 3.2 | Iteration #3 real 1:40.1 sys 0.0 user 3.0 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 ... Take care ... 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