lkml.org 
[lkml]   [1999]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateMon, 22 Mar 1999 11:15:45 +0100
FromVojtech Pavlik <>
SubjectRe: [OFFTOPIC] Re: disk head scheduling
On Sun, Mar 21, 1999 at 11:15:30PM -0500, Richard B. Johnson wrote:

> Basically you move a head over some magnetic media and write
> data in a circular track. When you want that data back, you
> switch the head into a read amplifier and read it.

Current drives have separate read and write portions on the head. You can
only read with a magnetoresistive head ...

> In the "olden" days, you could optimize the throughput by altering
> the sector interleave during a formatting operation. By matching
> the rate at which data could be written or read with the rate
> at which you could send or receive these data from the external
> world, you could optimize the I/O performance of the disk drive.

Yes, this was during the OMTI (ST-xxx, I don't recall the number), interface
days, when drives used to do MFM, and the better RLL ...

But even those, as soon as the controller cards got more RAM than 512 bytes
(16 kilobytes were needed, for one track of 17 (MFM) or 26 (RLL) sectors),
all were formatted to 1:1 interleave, because anything else was only slowing
them down.

Interleaving died fairly soon, and as far as I know was never needed since
that time.

> In recent years, the emphasis has been upon increasing the storage
> capacity of these Disc drives. The storage capacity, which used
> to be specified in terms of kilobits per square inch, called
> areal density, is now specified in terms of gigabits per linear
> centimeter.

Geez, I don't think you got the numbers right. If a harddrive had
a gigabit per linear centimeter, it'd have 3 GB (gigabytes) on
just the outer track ... which isn't the reality.

Should you be saying something like 0.1 Mbit/cm, I'd believe that.

> This means that read amplifiers that used to handle data at up
> to 10 MHz are now handling data at 800 Mhz to 1 GHz. You can
> check the numbers yourself. The bits per second that travel under
> the read head is now much greater than the bits per second that
> any I/O interface can handle.

I did. Quantum says for their current fastest IDE drive: Maximum internal
data rate: 241 Mb/sec. That's megabit per second. And, that makes it 30 MB
per second, which the drive will easily transfer to the host over it's
UDMA66 interface.

> This means that sector interleave,
> spiral compensation, and other tricks are now worthless because
> nothing you do along these lines will allow you to actually use
> data as fast as it becomes available. The data just arrives too
> fast. Because of this, sectors are no longer interleaved.

I can't agree with you here. Should the data be too fast for the interface,
interleaving OF COURSE would help, since for 2:1 you'd read the whole track
in two revolutions instead of one, effectively halving the data rate that
the interface needs to transfer to the host.

> Marketing persons, seizing buzzwords, cite this as an advantage
> and quote 1:1 interleave as though it were a benefit. Instead it
> is simply a side-effect.

It's more likely a necessity. Any other interleave would slow the
drive down, which isn't at all what manufacturers wish. They could
just let it spin slower ...

> Expensive disk drives now do full track buffering. This costs
> money because RAM costs money. To buffer one full track on a
> Disc drive requires CAPACITY / (HEADS * CYLINDERS) which can
> be upwards of 100 megabytes of high-speed SRAM.

All disks can do full track buffering now. And, if you think that cylinders
are somewhere in the range of hundreds, then I guess you're off by a couple
orders of magnitude. A track can easily fit into the 512 KB buffer on your
usual IDE drive.

> Because of this, rotational latency now means nothing either.
> This is another buzzword gone obsolete.

Hmm, then why all manufacturers state it? "Average Rotational Latency: 5.56 ms"

> Some IDE drives provide "read ahead".

All of the recent ones.


Have fun,
Vojtech

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [from the cache]
©2003-2010