From: Helge Hafting <helgehaf@aitel.hist.no>
To: Bharath Krishnan <bharath@mit.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Yet another disk transfer speed problem
Date: Fri, 01 Mar 2002 10:02:54 +0100 [thread overview]
Message-ID: <3C7F43BE.B0D2EAE@aitel.hist.no> (raw)
In-Reply-To: <1014914087.3274.22.camel@wavelets.mit.edu> <006401c1c091$d721ec00$5a5b903f@h90> <1014926801.3274.40.camel@wavelets.mit.edu>
Bharath Krishnan wrote:
>
> Hi,
>
> I would expect the disk which acts slower(maxtor) to be atleast as fast
> as the other one (ibm).
>
> reasons:
>
> 1. Both are 7200RPM
Not enough to get anywhere near equal performance.
This also depends on how densely data is packed onto a single track.
A 7200 RPM drive reads a whole track in 1/7200 minute, or 1/120 second.
That limits the maximum speed - but how much data is there
on a single track? Slow 7200 RPM drives have many tracks and little
data on each track. Fast drives have fewer tracks and more
data in each. Note that this has nothing to do with disk geometry
reported by hdparm, that geometry is just a lie.
All new drives have a varying amount of data per track as the
outermost tracks are longer than the innermost.
That of course also means the speed varies a lot depending on
_what_ track is used for testing.
My atlas IV scsi drive does 21MB/s on the outer tracks and 15MB/s
on the inner tracks according to specs. Running bonnie tests
on partitions at either end of the drive confirms the difference.
So, expect 7200 RPM drives from different manufacturers to
have very different transfer speeds. Or even different sized
drives from the same.
> 2. The slower one(maxtor hdg) is one of the newer ata133 disks while
> that faster one is ata100(ibm hde). I would expect atleast equal
> performance from both.
133 or 100 sets an upper limit of 133 or 100MB/s for sure, but that
doesn't matter _at all_ because the platters aren't that fast
anyway. The best you'll ever get depends on how much data they fit
on the outermost track. The 133 interface will be 33% faster when
transferring small amounts of data to or from the drive's internal
cache, but it won't impact transfers bigger than the cacee size
at all. hdparms 64M test is bigger than the drive's internal cache
which probably is a few megs only.
Helge Hafting
next prev parent reply other threads:[~2002-03-01 9:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-28 16:34 Bharath Krishnan
2002-02-28 19:55 ` Joseph Malicki
2002-02-28 20:06 ` Bharath Krishnan
2002-03-01 9:02 ` Helge Hafting [this message]
2002-03-01 19:50 ` Bharath Krishnan
2002-03-01 15:58 ` Holger Lubitz
2002-03-01 19:54 Bharath Krishnan
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=3C7F43BE.B0D2EAE@aitel.hist.no \
--to=helgehaf@aitel.hist.no \
--cc=bharath@mit.edu \
--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
all inboxes | Powered by JetHome®