Need some help understanding IOmeter results.....

[mooseracing]

I figured since it seems to be recommended as the speed test here, there should be some good insight

I finally was able to get another decent box up and running, Specs are:
SuperMicro (SM) SC216 2U with currently 8- 300GB SAS 10k in a R10
SM H8DGU-F motherboard with a 2GHz 8core AMD, 16GB RAM, LSI 9260-8i, Intel dual port CX4


The R10 is dedicated to Startwind, running HD benchmarks on the host with simpler tools such as Crystal Disk or HD tach I get around 400MB in R/W

Running IO Meter with the default test for 5 minutes I get:
IOps, Read IOps, Write IOps, MBps, ReadMBps, WriteMBps,
9212.639801 6173.278254 3039.361547 17.993437 12.057184 5.936253

I also did a 4k 100% Sequential Read and the results seemed pretty dismal. I know IOmeter is a better test but why do my results seem so crappy?

[Anatoly (staff)]

Hello
Could you provide more details about IOmeter configuration? Outstanding IOps? Disk align, number of workers, etc.?
You can send .icv file that you`ve configured for iometer.

[mooseracing]

I guess I can't attach, what would be a good email ?

Sorry if there is some basic knowledge of IO meter lacking here.

Thanks

[anton (staff)]

E-mail is one and only support@starwindsoftware.com but you don't really need to send anything so far.

Results are crappy b/c you measure who knows what. In a nutshell: you measure with 4KB I/O blocks. Something that NEVER happens in the real world. HD Tach and CrystalMark (hate this tool actually) show I/O bandwidth with variable block size and you get impressive number of MBps with 64KB - 256KB per single I/O block size. Windows class driver always breaks file I/O it got from local file system (NTFS these days) into blocks of 64KB and up. To speed up the whole thing. Another issue is queue depth. Windows is not DOS, it's multitasking. All I/O in kernel is async and this means you have MULTIPLE I/Os fired at the same time and being ready in the various stages of completion. Pipeline. With I/O Meter start with 16 and go up to 128 or 256. Next go number of workers. It's number of apps doing disk I/O at the same time. Again we're not DOS so Windows does paging, lazy writer does NTFS write buffers flush, background apps reads something and we do something as well. Many apps is many I/O worker threads. Start with one going up to 8 or 16.

So for maximum bandwidth try 64KB - 256KB per single I/O, only read or only write (NO MIX PLEASE), ~64 I/Os pending 1-2-4 workers. For maximum IOps do the same but block size should be smallest. 512 bytes or 4KB (hardware sector size).

That's all...

[anton (staff)]

And I forgot RANDOM Vs. SEQUENTIAL. Use SEQUENTIAL. RANDOM is another test pattern.

[kmax]

I think it might be beneficial if you guys (Starwind) would come up and make available standard .icv files for customer troubleshooting and general benchmarking comparison against other systems.

[anton (staff)]

Sounds like a plan. We'll do it for sure no doubt! And we're also working on built-in monitoring software for StarWind. So you could see latency and bulk transfer numbers in StarWind Management Console itself. Initial version is supposed to be released with V5.7 so stay tuned.

I think it might be beneficial if you guys (Starwind) would come up and make available standard .icv files for customer troubleshooting and general benchmarking comparison against other systems.

[mooseracing]

Thanks for the info. Bumping to 4k from the default let me see more what I was expecting from the current configuration of the array. Good starting place to work from for me at least.

[anton (staff)]

Excellent! We'll proceed with the sample test pattern this week.

Thanks for the info. Bumping to 4k from the default let me see more what I was expecting from the current configuration of the array. Good starting place to work from for me at least.