Unstable speed or correct?

Hello Pol.

On Thu, Jun 9, 2011 at 6:02 AM, Pol Hallen [off-list ref] wrote:

quoted

What benchmark program did you use for the test? Also, was there any other
programs running at the same time? Was the machine in single-user (init 1)
state?

hello :-)

dd if=/dev/zero of=/share/raid6/1Gb bs=1024 count=1000000
1000000+0 records in
1000000+0 records out
1024000000 bytes (1.0 GB) copied, 12.1632 s, 84.2 MB/s

dd if=/dev/zero of=/share/raid6/10Gb bs=1024 count=10000000
10000000+0 records in
10000000+0 records out
10240000000 bytes (10 GB) copied, 142.021 s, 72.1 MB/s

The above dd's seem much more consistent than the graph.

That graphic with palimptest (gnome-disk-utility).

I'm not familiar with this program (BTW, you mean "palimpsest",
right?), and I've run it for the first time on my system (M4A785-M
with Phenon-II X6 1055T, 4GB RAM, with 3 x ST31500541AS 1.5TB 3.5"
5900RPM HDs plugged directly onto the motherboard's SB700 SATA
controller, running Ubuntu Lucid Lynx 10.04.1 LTS, kernel
2.6.32-32-generic; the 3 HDs are mounted as a RAID5 md device and
dedicated to user data-only storage and mounted as /usr2, the root
filesystem runs on a separate SSD disk). Here's my palimpsest graph:
http://durval.com/felwithe_raid5_palimpsest_ro_20110609.jpg

Note that it shows much less "jitter" (local variation) than your graph.

No other applications uses raid (I'm on init 2 but samba, ftp, and other
daemons are off)

iostat not show me any activity by raid, so I think there is not programs that
runs on array.

This is very strange... concurrent access by other programs would
certainly explain the variation on your graph.

I would try running some other benchmark that can be run on
single-user state to see if the variation remains. If it does, then I
would conclude that there's something wrong (possibly on your
hardware, like a failing disk doing retries/reseeks).

Cheers,
--
  Durval Menezes.

thanks :-)

Pol

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html