From: Holger Lubitz <h.lubitz@internet-factory.de>
To: linux-kernel@vger.kernel.org
Subject: Re: UDMA 100 / PIIX4 question
Date: Tue, 20 Mar 2001 17:11:09 +0100 [thread overview]
Message-ID: <3AB7811D.97601E82@internet-factory.de> (raw)
In-Reply-To: <20010318165246Z131240-406+1417@vger.kernel.org> <3AB65C51.3DF150E5@bigfoot.com> <3AB65F14.26628BEF@coplanar.net> <20010319222113Z131588-406+1752@vger.kernel.org>
quintaq@yahoo.co.uk wrote:
>
> On Mon, 19 Mar 2001 12:17:38 -0800
> Tim Moore <timothymoore@bigfoot.com> wrote:
>
> > Apologies for the too brief answer. Sustained real world transfer rates
> > for the PIIX4 under ideal
> > setup conditions and a quiet bus are 14-18MB/s.
I dare to disagree. These numbers are from an Asus P2L97-DS (Dual P2,
Intel 440LX chipset with PIIX4) with an IBM DTLA 307045:
/dev/hda5:
Timing buffer-cache reads: 128 MB in 1.21 seconds =105.79 MB/sec
Timing buffered disk reads: 64 MB in 2.30 seconds = 27.83 MB/sec
/dev/hda5 is the outermost linux partition, starting at cyl 256.
(if you don't count hdparm measurements as real world transfer rates -
linear read as measured by bonnie is 26.3 MB/s).
> There is a Win partition - so I do not think I am at the start of the drive.
>
> Then hdparm -tT /dev/hda
>
> /dev/hda:
> Timing buffer-cache reads: 128 MB in 1.04 seconds =123.08 MB/sec
> Timing buffered disk reads: 64 MB in 4.08 seconds = 15.69 MB/sec
Would your windows partition by any chance be at the beginning of the
disk?
hdparm speed measurements differ by filesystem (i have no idea why,
since they don't go through it - maybe some interaction with the
buffering code).
if you are testing a windows partition, you can expect to see
significantly lower values for hdparm:
/dev/hda1:
Timing buffer-cache reads: 128 MB in 1.65 seconds = 77.58 MB/sec
Timing buffered disk reads: 64 MB in 3.48 seconds = 18.39 MB/sec
Remarkably /dev/hda benches slightly better, even though the 64 MB read
are nearly the same as for hda1:
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.40 seconds = 91.43 MB/sec
Timing buffered disk reads: 64 MB in 3.06 seconds = 20.92 MB/sec
I also noticed that operations on a lot of files (like scanning for all
files in a filesystem as done by updatedb) got really slow with the 2.4
vfat fs, with a very high percentage (in the 90s) of CPU time attributed
to "system". Has anybody else noticed this?
Holger
next prev parent reply other threads:[~2001-03-20 16:12 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-18 16:53 UDMA 100 / PIIX4 question quintaq
2001-03-19 19:21 ` Tim Moore
2001-03-19 19:33 ` Jeremy Jackson
2001-03-19 20:17 ` Tim Moore
2001-03-19 22:22 ` quintaq
2001-03-20 16:11 ` Holger Lubitz [this message]
2001-03-20 17:33 ` Jeremy Jackson
2001-03-20 20:21 ` quintaq
2001-03-20 21:32 ` Mark Hahn
2001-03-21 9:56 ` quintaq
2001-03-21 16:26 ` quintaq
2001-03-21 16:38 ` Mike Dresser
2001-03-23 10:27 ` quintaq
2001-03-21 19:18 ` Tim Moore
2001-03-21 19:29 ` Andre Hedrick
2001-03-22 13:21 ` Holger Lubitz
2001-03-23 10:27 ` quintaq
2001-03-21 19:14 ` Tim Moore
2001-03-23 10:27 ` quintaq
2001-03-23 21:17 ` Tim Moore
2001-03-21 14:06 ` Holger Lubitz
2001-03-19 20:32 ` Mark Hahn
2001-03-19 21:51 ` Tim Moore
2001-03-19 19:55 ` Jeremy Jackson
2001-03-19 20:38 ` Tim Moore
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=3AB7811D.97601E82@internet-factory.de \
--to=h.lubitz@internet-factory.de \
--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