From: TJ <systemloc@earthlink.net>
To: linux-raid@vger.kernel.org
Subject: Re: Looking for the cause of poor I/O performance
Date: Fri, 3 Dec 2004 15:03:31 -0500 [thread overview]
Message-ID: <200412031503.32130.systemloc@earthlink.net> (raw)
In-Reply-To: <Pine.LNX.4.44.0412021919400.21152-100000@coffee.psychology.mcmaster.ca>
> > My server is a K6-500 with 43MB of RAM, standard x86 hardware. The
>
> such a machine was good in its day, but that day was what, 5-7 years ago?
> in practical terms, the machine probably has about 300 MB/s of memory
> bandwidth (vs 3000 for a low-end server today). further, it was not
> uncommon for chipsets to fail to cache then-large amounts of RAM (32M was a
> common limit for caches configured writeback, for instance, that would
> magically cache 64M if set to writethrough...)
Bah. As much as I had hoped to squeeze more out of this box, I think you have
a pretty solid point. I tried out doing a quick hdparm -tT on all of the
drives, using the same OS on the newer Athlon box I described. I got much
better numbers. I included the output below.
> > OS is Slackware 10.0 w/ 2.6.7 kernel I've had similar problems with the
>
> with a modern kernel, manual hdparm tuning is unnecessary and probably
> wrong.
>
> > To tune these drives, I use:
> > hdparm -c3 -d1 -m16 -X68 -k1 -A1 -a128 -M128 -u1 /dev/hd[kigca]
I also checked out what hdparm showed for default settings without modifying
them on boot, both on the Athlon, and on the K6. In the case of the Athlon,
you're right, performance suffered from my tuning. In the case of the K6, I
saw no noticeable difference.
It's interesting that on the Athlon, one controller was set to -c1 by default,
while on the K6, the same controller with the same drives is set to -c0 by
default by the exact same kernel. I'm at a loss for how this is determined
and why..
> if you don't mess with the config via hdparm, what mode do they come up in?
I included this for both machines.
I think I will concentrate on tweaking the PCI settings to see if I can't get
a bit more out of that bus and check for any noticable improvements in
throughput. I'm hoping that this still may be related to some sort of PCI
latency issue.
TJ Harrell
_______________________________________________________________________
Default settings on the Athlon:
75 GXP:
Timing buffer-cache reads: 1124 MB in 2.01 seconds = 560.12 MB/sec
Timing buffered disk reads: 108 MB in 3.02 seconds = 35.74 MB/sec
WD 1200:
Timing buffer-cache reads: 1116 MB in 2.00 seconds = 556.69 MB/sec
Timing buffered disk reads: 108 MB in 3.05 seconds = 35.43 MB/sec
WD 2000:
Timing buffer-cache reads: 1092 MB in 2.01 seconds = 544.45 MB/sec
Timing buffered disk reads: 106 MB in 3.00 seconds = 35.32 MB/sec
WD 400:
Timing buffer-cache reads: 1084 MB in 2.01 seconds = 540.46 MB/sec
Timing buffered disk reads: 122 MB in 3.02 seconds = 40.42 MB/sec
WD 2000:
Timing buffer-cache reads: 1140 MB in 2.00 seconds = 569.52 MB/sec
Timing buffered disk reads: 112 MB in 3.01 seconds = 37.19 MB/sec
Defaults on the K6:
/dev/hda:
multcount = 0 (off)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 78165360, start = 0
/dev/hdc:
multcount = 0 (off)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 24321/255/63, sectors = 390721968, start = 0
dev/hdg:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 24321/255/63, sectors = 390721968, start = 0
/dev/hdi:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 234441648, start = 0
/dev/hdk:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 90069840, start = 0
next prev parent reply other threads:[~2004-12-03 20:03 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-02 16:38 Looking for the cause of poor I/O performance TJ
2004-12-03 0:49 ` Mark Hahn
2004-12-03 3:54 ` Guy
2004-12-03 6:33 ` TJ
2004-12-03 7:38 ` Guy
2004-12-04 15:23 ` TJ
2004-12-04 17:59 ` Guy
2004-12-04 23:51 ` Mark Hahn
2004-12-05 1:00 ` Steven Ihde
2004-12-06 17:48 ` Steven Ihde
2004-12-06 19:29 ` Guy
2004-12-06 21:10 ` David Greaves
2004-12-06 23:02 ` Guy
2004-12-08 9:24 ` David Greaves
2004-12-08 18:31 ` Guy
2004-12-08 22:00 ` Steven Ihde
2004-12-08 22:25 ` Guy
2004-12-08 22:41 ` Guy
2004-12-09 1:40 ` Steven Ihde
2004-12-12 8:56 ` Looking for the cause of poor I/O performance - a test script David Greaves
2004-12-28 0:13 ` Steven Ihde
2004-12-06 21:16 ` Looking for the cause of poor I/O performance Steven Ihde
2004-12-06 21:42 ` documentation of /sys/vm/max-readahead Morten Sylvest Olsen
2004-12-05 2:16 ` Looking for the cause of poor I/O performance Guy
2004-12-05 15:14 ` TJ
2004-12-06 21:39 ` Mark Hahn
2004-12-05 15:17 ` TJ
2004-12-06 21:34 ` Mark Hahn
2004-12-06 23:06 ` Guy
2004-12-03 6:51 ` TJ
2004-12-03 20:03 ` TJ [this message]
2004-12-04 22:59 ` Mark Hahn
2004-12-03 7:12 ` TJ
-- strict thread matches above, loose matches on Subject: below --
2004-12-03 11:30 TJ
2004-12-03 11:46 ` Erik Mouw
2004-12-03 15:09 ` TJ
2004-12-03 16:25 ` Erik Mouw
2004-12-03 16:32 ` David Greaves
2004-12-03 16:50 ` Guy
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=200412031503.32130.systemloc@earthlink.net \
--to=systemloc@earthlink.net \
--cc=linux-raid@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;
as well as URLs for NNTP newsgroup(s).