public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64] Re: Is my RAID performance bad possibly due to starting sector value?
Date: Fri, 28 Jun 2013 09:12:24 +0000 (UTC)	[thread overview]
Message-ID: <pan$279a9$4e73505c$b340c741$3010b655@cox.net> (raw)
In-Reply-To: pan$dcf36$c3d7c9cc$7915dd10$d07d87ae@cox.net

Duncan posted on Fri, 28 Jun 2013 03:36:10 +0000 as excerpted:

> So now I guess I send this and do some more testing of real device, now
> that you've provoked my curiosity and I have the 50 GB (mostly)
> pseudorandom file sitting in tmpfs already.  Maybe I'll post those
> results later.

Well, I decided to use something rather smaller, both because I wanted to 
run it against my much smaller btrfs partitions on the ssd, and because 
the big file was taking too long for the benchmarks I wanted to do in the 
time I wanted to do them.

I settled on a 4 GiB file.  Speeds are power-of-10-based since that's 
what dd reports, unless otherwise stated.  Sizes are power-of-2-based 
unless otherwise stated.  This was filesystem-layer-based, not direct to 
device, and single I/O task, plus whatever the system might have had 
going on in the background.

Also note that after reading the dd manpage, I added the conv=fsync 
parameter, hoping that gave me more accurate speed ratings due to the 
reducing the write-caching.

SSD speeds, dual Corsair Neutron n256gp3 SATA-600 ssds, running btrfs 
raid1 data and metadata:

To SSD: peak was upper 250s MB/s over a wide blocksize range of 1 MiB to 
1GiB.  I believe the btrfs checksumming might lower speeds here somewhat, 
as it's quite lower than the rated 450 MB/s sequential write speed.  

From SSD: peak was lower 480s MB/s, blocksize 32 KiB to 512 KiB (smaller  
blocksize range but much smaller block than I expected).  This is MUCH 
better, far closer to the 540 MB/s ratings.

To/from SSD: At around 220 MB/s, peak was somewhat lower than write-only 
peak, as might be expected.  Best-case blocksize range seemed to be 256 
KiB to 2 MiB.

So, best mixed-access case would seem to be a blocksize near 1 MiB.

I did a few timed cps also, then did the math to confirm the dd numbers.  
They were close enough.

Spinning rust speeds, single Seagate st9500424as, 7200rpm 2.5" 16MB 
buffer SATA-300 disk drive, reiserfs.  Tests were done on a partition 
located roughly 40% thru the drive.  I didn't test this one as closely 
and didn't do rust-to-rust tests at all, but:

To rust: upper 70s MB/s, blocksize didn't seem to matter much.

From rust: upper 90s MB/s, blocksize upto 4 MiB.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman



  reply	other threads:[~2013-06-28  9:12 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-20 19:10 [gentoo-amd64] Is my RAID performance bad possibly due to starting sector value? Mark Knecht
2013-06-20 19:16 ` Volker Armin Hemmann
2013-06-20 19:28   ` Mark Knecht
2013-06-20 20:45   ` Mark Knecht
2013-06-24 18:47     ` Volker Armin Hemmann
2013-06-24 19:11       ` Mark Knecht
2013-06-20 19:27 ` Rich Freeman
2013-06-20 19:31   ` Mark Knecht
2013-06-21  7:31 ` [gentoo-amd64] " Duncan
2013-06-21 10:28   ` Rich Freeman
2013-06-21 14:23     ` Bob Sanders
2013-06-21 14:27     ` Duncan
2013-06-21 15:13       ` Rich Freeman
2013-06-22 10:29         ` Duncan
2013-06-22 11:12           ` Rich Freeman
2013-06-22 15:45             ` Duncan
2013-06-22 23:04     ` Mark Knecht
2013-06-22 23:17       ` Matthew Marlowe
2013-06-23 11:43       ` Rich Freeman
2013-06-23 15:23         ` Mark Knecht
2013-06-28  0:51       ` Duncan
2013-06-28  3:18         ` Matthew Marlowe
2013-06-21 17:40   ` Mark Knecht
2013-06-21 17:56     ` Bob Sanders
2013-06-21 18:12       ` Mark Knecht
2013-06-21 17:57     ` Rich Freeman
2013-06-21 18:10       ` Gary E. Miller
2013-06-21 18:38       ` Mark Knecht
2013-06-21 18:50         ` Gary E. Miller
2013-06-21 18:57           ` Rich Freeman
2013-06-22 14:34           ` Duncan
2013-06-22 22:15             ` Gary E. Miller
2013-06-28  0:20               ` Duncan
2013-06-28  0:41                 ` Gary E. Miller
2013-06-21 18:53         ` Bob Sanders
2013-06-22 14:23     ` Duncan
2013-06-23  1:02       ` Mark Knecht
2013-06-23  1:48         ` Mark Knecht
2013-06-28  3:36           ` Duncan
2013-06-28  9:12             ` Duncan [this message]
2013-06-28 17:50               ` Gary E. Miller
2013-06-29  5:40                 ` Duncan
2013-06-30  1:04   ` Rich Freeman
2013-06-22 12:49 ` [gentoo-amd64] " B Vance
2013-06-22 13:12   ` Rich Freeman
2013-06-23 11:31 ` thegeezer

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='pan$279a9$4e73505c$b340c741$3010b655@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-amd64@lists.gentoo.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