lkml.org 
[lkml]   [1999]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject[OFFTOPIC] Re: disk head scheduling
On Fri, Mar 19, 1999 at 10:39:50PM -0500, Richard B. Johnson wrote:
> > Who's talking about optimizing based on phony geometries? Did you read what
> > I wrote?
>
> You just wrote it. Even though I worked for a major disk manufacturer
> I don't know what you will say in the future.

This is getting silly. I can't understand where you get the idea that I was
talking about any phony geometries. I explicitly said `some manufacturers are
good enough to tell us the real geometry in their tech notes'.

>
> As I explained, most IDE geometries are phony for compatability with
> the H/C/S acessible through the BIOS.

I _know_ that.

> The average latency is something you expect when you see a head spinning
> over a platter. However, it is some invention rather than fact. This is
> why we have sector interleave. There are few (if any) IDE drives that
> can read or write an entire track in one revolution. The high bit-density
> and low bandwidth I/O path almost guarantees that you can't get the data
> out of a sector buffer fast enough. Therefore sectors are interleaved.
> The real number of sectors is almost always a prime number so that an
> interleave of 2,3,4,5 or greater can be used. The manufacturer formats
> the drive with the interleave that matches the sector-to-sector time
> against the I/O bandwidth.

Maybe you know better, but I have a data sheet in front of me that says
the sector interleave on my drive is 1:1.

>
> In fact, I have written utilities that determine the optimum interleave
> and format the drive to that value.
>
> > Bunching requests that are on the same track is good, since the drive
> > probably does some read-ahead and caching. But accesses that are far enough
> > apart that they can't be to the same track can be done in either order with
> > no significant difference in time.
> >
>
> I don't think IDE drives do read ahead and caching. Look at the
> electronics. There is just a servo chip, a read/write amplifier,
> serializer, and a static-RAM sector buffer. IDE means Integrated
> Drive Electronics, which translates to cheap. That is how and why
> they are made.

Again, the same data sheet says my drive can do read-ahead. That would be
nonsense without some form of caching.

> > IBM is good enough to tell me that there are 8 zones on my platters, numbered
> > 0 to 7 from the outside in. They also tell me the recording density at both
> > ends. From that we can work out a rough estimate of the number of sectors per
> > track and the number of tracks in a zone. If two requests are to different
> > tracks, then which is performed before the other is largely irrelevant, so I
> > can order my requests to minimize the total number of seeks.
> >
>
> Good luck. This means that the drive was so poorly designed that they
> had to use 8 different sector interleaves to get acceptible performance.

?? It isn't 8 different interleaves. It's 8 different sectors/track value, so
as to maintain roughly the same recording density. Lots of modern IDE drives
do this. This just makes the transfer rate different on different zones, so it
varies from 76.5 Mbits/sec on the inside to 127.4 Mbits/sec on the outside.

>
> > > CPU cycles that could be used elsewhere. What happens is you slightly
> > > slow the overall operation of the entire machine without increasing the
> > > Disc performance at all. Wasted CPU cycles are never gotten back, you
> > > burned them up, making a beautiful I/O queue, then accomplish nothing
> > > for your effort.
> >
> > Yes, but my machine is almost always waiting for disk I/O. The only time my
> > CPU utilization goes over 90% is when I'm running gcc. Usually my idle time is
> > what is over 90%.
> >
>
> Guess again. CPU cycles used doing nothing useful are lost forever.

Yes, so let's waste 'em sorting I/O requests instead of twiddling our thumbs.

> Getting a lucky hit on a sector boundary occasionally will never show
> up as an average increase in I/O speed. It is way below the noise.
>

Ok, forget I ever started this...

-- arvind

-
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    [W:0.116 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site