From: Jimmie Mayfield <mayfield+usenet@sackheads.org>
To: linux-kernel@vger.kernel.org
Subject: Interesting disk throughput performance problem
Date: Sat, 21 Jul 2001 23:33:13 -0400 [thread overview]
Message-ID: <20010721233313.A15232@sackheads.org> (raw)
Hi. I'm running into some disk throughput issues that I can't explain.
Hopefully someone reading this can offer an explanation.
One of my machines is running 2.4.5 and has 2 hard drives: a 7200 rpm
ATA100 Maxtor and a 5400 rpm ATA33 IBM. Each drive is a master on its own
controller (AMI CMD649 as found on the IWill KT266-R). Both drives contain
reiserfs 3.6x filesystems.
By all local benchmarks, the 7200 rpm drive is the faster drive. But this
doesn't seem to be the case for large files originating from remote clients.
Witness:
My crude test involves scp'ing a 100MB file from another machine on my home
network over 100bT ethernet.
1) scp to the 5400rpm drive: roughly 10MB/sec.
2) scp to the 7200rpm drive: roughly 2MB/sec.
I've tried 'tail' and 'notail' mount options with no change (as expected since
this is a single large file). I suspect that the machine would become CPU-bound
somewhere in the 20MB/sec range (see below for my reasoning).
I see the same sort of behavior using Samba though not nearly as
pronounced (the 5400rpm drive is merely 2x as fast as the 7200rpm drive).
Okay. Since the test involved 2 separate drives with different geometries,
I figured this might be due to physical block location. Perhaps the file
is getting allocated to the fastest cylinders on the 5400 rpm drive and
the slowest cylinders on the 7200 rpm drive. Or it could be a fragmentation
issue.
So I tried the test locally: with the file stored on the 5400rpm drive,
scp it to localhost and write it to the 7200rpm drive. Results were a little
below 10MB/sec (CPU near 100% presumably due to encrypting/decrypting on
the fly).
Any ideas why the 7200rpm drive performs so poorly for remote clients but
performs wonderfully well when those same operations are performed locally?
Jimmie
next reply other threads:[~2001-07-22 3:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-22 3:33 Jimmie Mayfield [this message]
2001-07-22 9:20 ` Interesting disk throughput performance problem Hans Reiser
2001-07-22 14:07 ` toon
2001-07-22 14:41 ` Hans Reiser
2001-07-22 10:29 ` Jakob Østergaard
2001-07-22 10:44 ` Mike Black
2001-07-24 15:06 ` Jimmie Mayfield
-- strict thread matches above, loose matches on Subject: below --
2001-07-24 17:11 Tim Schmielau
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=20010721233313.A15232@sackheads.org \
--to=mayfield+usenet@sackheads.org \
--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