🚀 go-pugleaf

In article <47vle9$5hi@fox.almaden.ibm.com>,
Chuck Tribolet <triblet@almaden.ibm.com> wrote:
>In <47tbk2$ktb@decaxp.harvard.edu>, bb@wjh.harvard.edu (Brent Byer) writes:

     [ discussion of IBM DeskstarXP performance ]

>>  and since there are 4 data surfaces, a sustained
>>  transfer loses one disk revolution after every four revs, for
>>  the seek to the next cylinder.  Hence, 4.14 * 4 / 5 = 3.2 .

>You don't necessarily loose a whole disk revolution while doing the seek.
>The first byte of all the tracks on all the disks DON'T line up.  They are
>offset so that if a seek is done at the end of the last track on the cylinder
>then just as the seek completes and the servo settles down, the first bytes
>of the first track on the next cylinder are coming under the heads.  Also,
>it takes a little time (called head settle time) to switch from on track
>to another on the same cylinder.  To allow for this, there's a much smaller
>offset from on track to another on the same cylinder.

Thanks for the correction, and clarification.
I'm glad to see the sensible engineering you described.

I was trying to `justify' the spec's "3.2 MB/sec sustained transfer rate"
relative to a minimum (inner tracks) useful-data rate of 4.14 MB/sec.
 [ and the numbers seemed to fit so nicely ]

Could you please explain that 3.2 vs 4.1 confusion.
Have I made another bad-ass umption ?

  [ re: 5400rpm * 90 sect/trk * 512 bytes/sect / 60 sec/min = 4.14 MB/sec

        the described skew would suggest a `lost transfer opportunity' of
        about 3-4ms (2.3ms trk-to-trk + 4*settle-fudge) each 44ms (4 revs),
        or about .25-.35 MB/sec
  ]

(It's been over 20 years since I've written disk drivers ... and it shows.)

-- brent