putting 16 ms in the table accelerates the "full take" about 10 seconds.
Do you mean "to about 10 seconds"? 0.016 x 615 = 9.84 seconds. So the stepping portion of this entire "blasting everything off the disk" exercise is only 10 seconds. Why not go ahead and assume the worst case of 20ms a step, that takes traversing the whole disk a step at a time to only
12.3 seconds.
So, let's bandy about some other "guess" numbers: with a 1:1 controller you're reading a *track* every 16.7 ms. There are four tracks per cylinder on an ST-225, so if we assume that the controller could just go straight to reading the next track then the total time to read a whole cylinder *plus* stepping to the next is about 87 milliseconds. ((16.7*4) + 20) Multiply by 615 and that's a whopping 54 seconds to read the whole disk.
Even if we assume that the cylinder read time is twice the single track time (IE, there's one rotation's worth of latency when switching tracks within a cylinder, which there really isn't reason to assume if the designers of the controller were smart) the total read/transit time only goes up to around 95 seconds. I'd think if there was that much penalty going from track to track it would have shown up in those benchmarks I ran back in the day on my 1006, though.
(FWIW, a 20MB drive in 54 seconds is "only" about 370Kps, and 95 seconds 210Kps. That latter number is within reach of the original MFM controller used in the IBM AT, interleave and all. So these just don't seem unreasonable to me.)
