All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Jackson <jerj@coplanar.net>
To: Holger Lubitz <h.lubitz@internet-factory.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: UDMA 100 / PIIX4 question
Date: Tue, 20 Mar 2001 12:33:25 -0500	[thread overview]
Message-ID: <3AB79464.A7A95A54@coplanar.net> (raw)
In-Reply-To: <20010318165246Z131240-406+1417@vger.kernel.org> <3AB65C51.3DF150E5@bigfoot.com> <3AB65F14.26628BEF@coplanar.net> <20010319222113Z131588-406+1752@vger.kernel.org> <3AB7811D.97601E82@internet-factory.de>

Holger Lubitz wrote:

> 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:

Yes this is why I originally replied to the post... but he's not using a PIIXx at
all,
but the IDE chip on an Intel 815 motherboard.  I'm not sure if they use the same
driver
, but I don't think so.

>
>
> /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,

this is false.  They may differ by partition, since different parts (zones) of a
modern disk have different recording densities and therefore transfer rates.
IBM's spec sheet says rates vary from 15MB/sec to 31MB/sec... it he's seeing
15MB/sec, maybe he should try the other end of the disk.  can you verify this?
try hdparm -t /dev/hda1 instead of hda5 (if those are on opposite ends of the
disk)

include output of fdisk so we can see partition layout, and results of hdparm on
different areas.

>
> 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

please show us your partition table.

>
>
> 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?


  reply	other threads:[~2001-03-20 17:41 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
2001-03-20 17:33           ` Jeremy Jackson [this message]
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=3AB79464.A7A95A54@coplanar.net \
    --to=jerj@coplanar.net \
    --cc=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 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.