public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ed Sweetman <safemode2@comcast.net>
To: "Martin A. Fink" <fink@mpe.mpg.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SATA Performance with Intel ICH6
Date: Fri, 24 Nov 2006 09:05:57 -0500	[thread overview]
Message-ID: <4566FC45.5020602@comcast.net> (raw)
In-Reply-To: <200611241407.01210.fink@mpe.mpg.de>

Martin A. Fink wrote:
> Dear all,
>
> I found out, that writing to a SATA harddisk costs around 20% of the
> computers cpu time. I write blocks of 1MB size to a file. Write performance
> is around 51MB/s what I think is really good. My computer has an Intel ICH6
> chipset and a 3.2GHz Pentium 4 processor.
> If I understand the design of this chipset correctly, then I would have
> expected, that the CPU needs to do only few work, instead I found out, that
> writing to disk seems to be really hard work for the CPU.
>
> Can I do anything to optimize writing from memory to disk?
>
> My final aim is to get around 140MB/s of data from 3 different Gigabit
> Ethernet cards and store it on 3 harddisk drives that perform 50MB/s.
> >From the SATA bus side there should be no problem. Each of the 4 SATAs on
> this ICH6 chipset are capable of 150MB/s.
>
> So what makes my CPU that slow? Is it a hardware problem or a problem of
> SATA driver of my operating system?
>
> time dd if=/dev/zero of=test.zero bs=1M count=1000
> results in
>
> real 0m52.561s
> user 0m0.003s
> sys  0m7.407s
>
> and strace dd... gives among other information
> 6.84s 1004calls syscall: write
>
> So I spend 45s of 52s within the kernel. Why so long?
>   
forgetting the fact that you're only writing 0's and that makes me 
wonder if the filesystems are cheating because the data it's writing is 
all the same, you aren't syncing that data.  You're not benchmarking the 
actual write speed, you have buffer being used still with uncommitted data.

try using iozone or something a little more stressful on the system.  


If you rerun the "benchmark" and your scores are much better (like with 
your example the second run gets 260MB/sec for me) then it's not a good 
benchmark.   It should be consistantly the same no matter how many times 
you run it.


> By the way: I'm working with SuSE Linux 9.2 on a Dell Desktop PC, 1GB RAM
>
> Thank you for answers,
>
> Martin
>   

  parent reply	other threads:[~2006-11-24 14:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-24 13:07 SATA Performance with Intel ICH6 Martin A. Fink
2006-11-24 13:33 ` Alan
2006-11-24 14:10   ` Martin A. Fink
2006-11-24 14:30     ` Alan
2006-11-24 14:54       ` Martin A. Fink
2006-11-25 19:23     ` Andrew Morton
2006-11-24 14:05 ` Ed Sweetman [this message]
2006-11-24 22:10 ` J.A. Magallón
  -- strict thread matches above, loose matches on Subject: below --
2006-11-24 14:30 Daniel J Blueman
2006-11-28 10:09 Martin A. Fink
2006-11-28 10:43 ` Alan

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=4566FC45.5020602@comcast.net \
    --to=safemode2@comcast.net \
    --cc=fink@mpe.mpg.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