jt19840@tut.fi (Tuomi Jyrki Juhani) (10/14/89)
About a week ago, I posted a query in comp.sys.ibm.pc about setting the optimum interleave factor with WD1006V-SR2 ctrl. My query was probably too much system specific, as there has been only one reply (by James White, jrw@uncecs.edu), which was most informative even though my problem wasn't directly related to ROM shadowing as he suggested. Anyway, I have solved my "problem", and I'll post my experiences here, in case someone may find this useful. BTW, I bought my WD1006V-SR2 from Express Micro Mart (in USA, tel 1-800- 533-0177). They had an ad in August 1989 issue of PC Magazine, where the 1006V-SR2 was priced $146. By the time of order (end of August) they had dropped the price to $136! Homesmart Computing (800-627-6998) seems to be selling the same board for $129. Pretty cheap, considering that some ads list the WD1006V-SR2 for about $210! In article <2127@tutor.tut.fi> I wrote: >65MB disk. The disk has been formatted using the on-board BIOS setup- >routine (WD1006V-SR1/2 MR1/2 SETUP REV. 2.0). Spintest reports a >transfer rate of 399 360 BYTES/s with 2 revolutions/track, i.e. >interleave 2:1. CORETEST 2.8 reports a transfer rate of 437 to 438 >Kbytes/s. HDTST128 reports an interleave of 2:1. I have done a non- >destructive re-format (using HDTST128) to change the interleave to 1:1. >However, when I check the interleave after re-formatting, it is still >2:1 and xfer rates are the same as before. Toggling the on-board cache >enable/disable has no detectable effect whatsoever. So, I became more and more suspicious about the reposted 2:1 interleave factor, as the xfer rate measured by CORETEST is M O R E than theoretical maximum rate achievable using 26 sectors/track formatting. This was confirmed in <1989Oct10.022055.13435@uncecs.edu> by James White: >I believe HDTST determines the "interleave" from the transfer rate, not >from the actual interleave. Then, the disk must have been formatted to 1:1 interleave, but the data wasn't moving with the speed it should (438 KB/s isn't bad at all, but I knew that more - upto 790 KB/s - could be expected). My next guess was that problem was with the motherboard, as the only (?) reason that the problem was with the disk drive, would have been that it wasn't spinning at proper speed, and I felt that to be a little far-fetched. I have a C&T-based 386/AT-motherboard (a Taiwanese clone), so I started checking what was stored in 82C301 bus controller configuration registers. I was somewhat amazed to find out that the AT bus was running at an extremely conservative 1/3 of processor clock rate, i.e. 5.33 MHz! A four line assembly program with DEBUG changed the AT bus speed to 8 MHz (1/2 of processor clock rate), and CORETEST told that disk data xfer rate had risen to 622 KB/s. Some further checking revealed that 2 wait states were specified for every 16-bit AT bus transfer. After that was changed to 0 ws, the xfer rate was upto 737 KB/s! I'll settle for that... Very crude measurements indicate that copying a file to null device (dos COPY command) yields about 500 KB/s xfer rate. Jyrki Tuomi Tampere University of Technology, Finland Internet: jt19840@tut.fi UUCP: ..mcvax!tut!jt19840