mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: jw schultz <jw@pegasys.ws>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: Horrible drive performance under concurrent i/o jobs (dlh problem?)
Date: 24 Dec 2002 13:00:59 -0800	[thread overview]
Message-ID: <1040763659.2109.26.camel@ixodes.goop.org> (raw)
In-Reply-To: <20021224172122.GB30929@pegasys.ws>

On Tue, 2002-12-24 at 09:21, jw schultz wrote:
> I'm afraid your math is off.
> 
> The rotational frequency should be 7200*60/sec which makes
> for 2.31 us which would produce an average rotational
> latency of 1.16us if such a condition even still applies.

No, I think you're just a bit off.  A 7200RPM drive *does* revolve in
8.3ms.  A 2.31us rotation time would be 432900 RPS or approx. 26,000,000
RPM.  Which is pushing it.

The 8.3ms rotational latency is clearly visible as a wide band if you
graph access time against distance. 
http://www.goop.org/~jeremy/seek-buf.eps is an example of a 7200RPM
Western Digital drive.

> My expectation is that the whole track is buffered starting
> from the first sector that syncs thereby making the time
> rotfreq + rotfreq/nsect or something similar.  In any case
> the rotational latency or frequency is orders of magnitude
> smaller than the seek time, even between adjacent
> tracks/cylinders.

Track to track seek time is typically around 1ms.  Rotational latency is
often the dominating factor in access time.

> If the the stated average seek is 50% of full stroke and not
> based on reality then 76% of the cost of an average seek is
> attributed to distance and likewise 87% of the cost of a
> full.

Well, average seek is a vague concept.  If you assume that all seeks are
randomly distributed, then it might mean a half-stroke seek.  But almost
all seeks are short, so the weighting means that short seek time is the
most important to optimise (which drive vendors do: they use techniques
like dumping more current into the coils for short seeks because they
know it is short; if they dumped the same current for a long seek, it
would burn things out).  Also, there are only two cylinders between
which you can have the maximal seek, whereas every adjacent pair of
cylinders can have a minimal seek; in other words the physical nature of
the drive means that short seeks will dominate, even with random
seeking.

Rotational latency tends to dominate these days: a fast drive can do a
track to track seek in 1ms, and full-stroke seek in 9ms or so.  That
means that a 1ms track-to-track seek can take longer than a full stroke
if you include the 8.3ms variation.

Elevators are important for keeping seeks short.  This is partly to
reduce the seek time, but mostly because drives are optimised so that
the track-to-track skew is set up to minimise rotational latency.  The
further you seek, the more likely you are to miss the rotlat deadline
and have to take a full rotation penalty.

	J


  reply	other threads:[~2002-12-24 20:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-18 19:06 Torben Frey
2002-12-20 20:40 ` Joseph D. Wagner
2002-12-20 22:25   ` David Lang
2002-12-21  6:00     ` Joseph D. Wagner
2002-12-23  1:29       ` David Lang
2002-12-24  9:18       ` Roy Sigurd Karlsbakk
2002-12-24 17:21         ` jw schultz
2002-12-24 21:00           ` Jeremy Fitzhardinge [this message]
2002-12-25  1:34           ` Rik van Riel
2002-12-25  2:02           ` jw schultz
2002-12-25  3:41           ` Barry K. Nathan
2002-12-23 17:48   ` Krzysztof Halasa
2002-12-23 18:13 ` Denis Vlasenko
2002-12-18 21:10 Con Kolivas
2002-12-18 22:16 ` Torben Frey
2002-12-18 22:37   ` Andrew Morton
2002-12-18 23:30     ` Torben Frey
2002-12-18 23:46       ` Andrew Morton
2002-12-18 22:40   ` Torben Frey
2002-12-19 14:29 Torben Frey
2002-12-20  1:47 ` Nuno Silva
2002-12-27 13:04   ` Torben Frey
2002-12-20 14:27 ` Roger Larsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1040763659.2109.26.camel@ixodes.goop.org \
    --to=jeremy@goop.org \
    --cc=jw@pegasys.ws \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome