Strange raid results on x58A mobo

[vslo]

Sup dudes,
some of you might remember me few days ago asking about raid stuff.
Well, I made a raid0 on 2 x 500 gb seagate 7200.12 on windows 7 64bits.
my mobo is a biostar tpower x58A with ich10r raid controller.

Those were my results

http://img119.imageshack.us/img119/8679/hdtunebenchmarkintelrai.png

http://img205.imageshack.us/img205/8238/72635137.jpg

isnt that strange??
My burst rate is too low for my controller. I didnt used any drivers during the installation but after it was done I downloaded the last intel matrix storage driver for my chipset.I saw some people with the same raid as I did in worse mobos and olders raid controlers with such better performace, burst rate over 1000mb/s

If you note, my cpu usage is -1,0 % why's that?

thank you in advanc

 

[sub mesa]

Você não está logado ou não tem permissão para acessar essa página. Isso pode acontecer por uma dessas razões:

1. Você não está logado(a). Preencha o formulário no fundo desta página e tente outra vez.
2. Você não tem privilégios suficientes para acesar essa página. Você está tentando editar uma mensagem de alguém, características administrativas de acesso ou algum outro sistema privilegiado?

Host your images elsewhere, so we caqn see them.

 

[vslo]

Ok uploaded!

 

[sub mesa]

So everything looks fine there. No performance problems.

If you try the HDTune Pro benchmark, you will get actual filesystem performance.

But you probably were refering to the 'write caching' option. Once you enable this feature the benchmarks will behave differently and your 'burst speed' will be very high. Note that not all of the benchmark results is 'genuine' because HDTune is a very low level test that misrepresents performance in a case like this.

In other words, enabling the Write Caching option will make you see higher speeds with HDTune, but you don't absolutely need it for proper performance. Without this option, just use filesystem benchmarks like HDTune Pro "Files" benchmark or SiSoftware Sandra filesystem benchmark, or good old ATTO still works.

 

[vslo]

Thank you so much sub mesa, just gave me a big time help here.


So this write back cache doesnt make any difference in istalling/loading?

its just makes benchmarks looks better?

 

[sub mesa]

Yes and no.

Its yields both genuine performance increase and a misconception/misrepresentation of performance by "simple" benchmarks like HDTune.

These simple benchmarks perform serial operation on the volume, they do only one thing at a time. They read block 1, wait for the data, read block 2, wait for the data, read block 3, and so on. This is going to be slow on ANY RAID.

Filesystems instead, use read-ahead when reading large files. They don't read one sector at a time, they read large blocks ahead before the application even requests them. So if you begin reading a large file, it would instantly read the first 8 x 128KiB = 1024KiB of it. This would saturate RAID0 arrays up to 8 disks with an 128KiB stripesize.

In other words; the filesystem reads more intelligently than HDTune does; so even if HDTune gets you low speeds on a RAID0 these low speeds are 'false' because the filesystem will get max speed! The "Files" benchmark in HDTune does test filesystem performance; so its more reliable than the normal surface test HDTune does.

There is some confusion among consumers because enabling the write caching option would make the graph in HDTune really good, while the Files benchmark is more or less the same. The visible performance gain here is false - it just showed what you already had even without write caching. But it appears as if write caching made sequential speeds faster; it doesn't really.

But write caching will make writes go very fast, and can speed up the system in some realistic circumstances. So write caching DOES add to performance; it just shouldn't add to sequential performance on simple RAIDs. The exception here is RAID5 - without write caching writes will be very slow while with write caching the writes will be quite decent.

With software RAID5 on Linux/BSD this is the same; without write-back (called write-through mode) the write speeds are extremely low (like 2MB/s) while with write-back the speeds skyroof > 400MB/s. So here, write-back is pretty much required for decent speeds.

Note that using the write caching / write-back option may be dangerous at risk of filesystem corruption in case of a crash (blue screen) or power outage. So have a backup in all cases of data you don't want to lose!