All of lore.kernel.org
 help / color / mirror / Atom feed
From: jw schultz <jw@pegasys.ws>
To: linux-kernel@vger.kernel.org
Subject: Re: Horrible drive performance under concurrent i/o jobs (dlh problem?)
Date: Tue, 24 Dec 2002 18:02:58 -0800	[thread overview]
Message-ID: <20021225020258.GC30929@pegasys.ws> (raw)
In-Reply-To: <20021224172122.GB30929@pegasys.ws>

On Tue, Dec 24, 2002 at 09:21:23AM -0800, jw schultz wrote:
> On Tue, Dec 24, 2002 at 10:18:52AM +0100, Roy Sigurd Karlsbakk wrote:
> > keep in mind that only around half of the seek time is because of the 
> > partition! Taking an IBM 120GXP as an example:
> > 
> > Average seek:				8.5ms
> > Full stroke seek:			15.0ms
> > Time to rotate disk one round:	1/(7200/60)*1000 = 8.3ms
> 
> 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.
> 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.
> 
> 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.  Based on that i'd say the seek distance is a much
> bigger player than you are assuming.  If it weren't the
> value of elevators would be much less.

No. Your math is correct.  Mine is upside down.  Don't know
where that came from.  Apologies for the bad smell.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

  parent reply	other threads:[~2002-12-25  1:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-18 19:06 Horrible drive performance under concurrent i/o jobs (dlh problem?) 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
2002-12-25  1:34           ` Rik van Riel
2002-12-25  2:02           ` jw schultz [this message]
2002-12-25  3:41           ` Barry K. Nathan
2002-12-23 17:48   ` Krzysztof Halasa
2002-12-23 18:13 ` Denis Vlasenko
  -- strict thread matches above, loose matches on Subject: below --
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=20021225020258.GC30929@pegasys.ws \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.