Erratic disk speeds

My disk access speeds are usually poor, with occassional good results.  It seems totally random.  I have had results from 200kb/s up to 30MB/s.  The following were tests run on the server via a telnet prompt over a few minutes:

root@Tower:/mnt/myapps/util# date && write_speed_test.sh
Wed Jan 30 09:16:55 EST 2013
10240+0 records in
10240+0 records out
10485760 bytes (10 MB) copied, 6.49989 s, 1.6 MB/s
root@Tower:/mnt/myapps/util# date && write_speed_test.sh
Wed Jan 30 09:17:45 EST 2013
10240+0 records in
10240+0 records out
10485760 bytes (10 MB) copied, 11.1703 s, 939 kB/s
root@Tower:/mnt/myapps/util# date && write_speed_test.sh
Wed Jan 30 09:17:59 EST 2013
10240+0 records in
10240+0 records out
10485760 bytes (10 MB) copied, 13.5655 s, 773 kB/s
root@Tower:/mnt/myapps/util# date && write_speed_test.sh
Wed Jan 30 09:18:34 EST 2013
10240+0 records in
10240+0 records out
10485760 bytes (10 MB) copied, 39.6506 s, 264 kB/s
root@Tower:/mnt/myapps/util# date && write_speed_test.sh
Wed Jan 30 09:19:17 EST 2013
10240+0 records in
10240+0 records out
10485760 bytes (10 MB) copied, 37.2942 s, 281 kB/s

(write_speed_test.sh just does a "dd if=/dev/zero of=/mnt/disk1/output.dat bs=1024 count=10240"

I have tried different configurations with no material change in results:

  - larger test files

  - different array drives (including an ssd cache drive) (these are connected via an m1015)

  - a non-array drive (connected directly to motherboard)

My read speeds seem ok:

root@Tower:/mnt/myapps/util# hdparm -tT /dev/sdg1

/dev/sdg1:
Timing cached reads:   22406 MB in  1.99 seconds = 11235.54 MB/sec
Timing buffered disk reads: 534 MB in  3.00 seconds = 177.99 MB/sec
root@Tower:/mnt/myapps/util# hdparm -tT /dev/sdb1

/dev/sdb1:
Timing cached reads:   21516 MB in  1.99 seconds = 10787.37 MB/sec
Timing buffered disk reads: 172 MB in  3.02 seconds =  56.90 MB/sec
root@Tower:/mnt/myapps/util# hdparm -tT /dev/md1

/dev/md1:
Timing cached reads:   21696 MB in  1.99 seconds = 10877.90 MB/sec
Timing buffered disk reads: 112 MB in  3.07 seconds =  36.48 MB/sec

I had the same problem on rc4a, and then upgraded to rc11 yesterday with no affect.

Any suggestions as to what I might look for?

My setup:  Gigabyte z77-ds3h  mobo; 24GB Ram; i7-3770 cpu

syslog.txt

I was able to get 530MB/s (to my ssd cache drive, with a 1GB test), and 230MB/s with a 8GB test after this command

sysctl vm.highmem_is_dirtyable=1

I haven't read this entire thread, but certainly seems related: http://lime-technology.com/forum/index.php?topic=22675.135

I have read the thread referenced in my prior post, and will direct future comments there as this is clearly the same issue.

I was going to recommend checking out that thread you linked, so glad you found it, and it is helping.

I do have one recommendation, I see ata_piix being used, which usually means that in your BIOS SATA settings, you have SATA mode set to IDE emulation.  I strongly urge you to change that to AHCI, anything but an IDE emulation mode.  It should be slightly faster, and a little safer.  Not that you are using the onboard SATA ports for anything much, except a CD drive and an old 80GB drive.  They may be your fastest SATA ports, so I recommend reconnecting your parity drive there, and other fast drives too.

Tom, mpt2sas reports version 12.100.00.00.  Online I see a RedHat reference to 12.105.*, and a CentOS reference to 15.00.00.00.  Would a newer version be available and helpful, or am I being confused by weird versioning?

I'll double check the IDE/AHCI setting.  I -swear- I changed that to AHCI just yesterday before I rebooted.  Maybe I didn't save changes properly.  Thanks!

Tom, mpt2sas reports version 12.100.00.00.  Online I see a RedHat reference to 12.105.*, and a CentOS reference to 15.00.00.00.  Would a newer version be available and helpful, or am I being confused by weird versioning?

The 3.4.x kernel uses 12.100.00.00 (this is our kernel)

The 3.5.x kernel uses 13.100.00.00

The 3.6.x kernel uses 13.100.00.00

The 3.7.x kernel uses 14.100.00.00

The current release on the LSI website is 15.00.00.00-3

I'm currently downloading this - the zip file is 700MB 

Do you think this driver has something to do with the 'slow write' problem some people are seeing?

Do you think this driver has something to do with the 'slow write' problem some people are seeing?

Probably not.  I did wonder about that, but did no research until now, and didn't have to go far.  The very first post of the X9SCM-F slow write speed, good read speed thread includes a very clean syslog, X9SCM board with 32GB, no addon controllers and no plugins, only a few drives and all are attached to motherboard ports, no issues with system.  He reports slow writes with or without his SAS cards (this syslog did not have any installed).

I'm currently downloading this - the zip file is 700MB 

OK, that's beyond even Microsoft and Norton's ability to add bloat, for just a driver and docs, right?  Don't tell me they included a video how to compile it!?!

I'm currently downloading this - the zip file is 700MB 

 

OK, that's beyond even Microsoft and Norton's ability to add bloat, for just a driver and docs, right?  Don't tell me they included a video how to compile it!?!

LOL it includes rpm's and iso's for every linux-based distro known to man.  The actual source is 1.6MB, which is still freaking-hard to believe.  It's just a disk controller.  Quick 'wc -l' shows over 40K lines of code 

Note: for some perspective, even though this is meaningless, it's still kinda interesting:

But to give you some idea, there was no more than 10,000 lines of code on the Apollo program, which you have in your hand calculator now.

from http://www.spaceref.com/news/viewsr.html?pid=24883

Note: for some perspective, even though this is meaningless, it's still kinda interesting:

But to give you some idea, there was no more than 10,000 lines of code on the Apollo program, which you have in your hand calculator now.

from http://www.spaceref.com/news/viewsr.html?pid=24883

Thank you very much for that link.  Very very interesting!  I really wish I could have been part of that group.

...  The actual source is 1.6MB, which is still freaking-hard to believe.  It's just a disk controller. ...

 

Note: for some perspective, even though this is meaningless, ...

For some perspective, which is precisely appropriate, the entire source code for the initial release (outside of Bell Labs) of Unix was 132KB. A true work of art. Recommended reading for anyone with a real interest in Unix--you can find it here [link].

--UhClem "It was forty years ago, today ..."  (in a few months)

LOL it includes rpm's and iso's for every linux-based distro known to man.  The actual source is 1.6MB, which is still freaking-hard to believe.  It's just a disk controller.  Quick 'wc -l' shows over 40K lines of code 

I hope that is because there are lots of conditional lines in the source, accommodating "every linux-based distro known to man", together with copious comments.