Now trying tests with IOperf

( http://nucwww.chem.sunysb.edu/htbin/software_list.cgi?package=ioperf )

THIS PAGE DOES NOT CONTAIN MEANINGFUL NUMERICAL RESULTS YET!!!  THERE ARE AT LEAST TWO PROBLEMS WITH THE IOPERF NUMBERS TO BE RESOLVED (as described below).  Once resolved, this page will likely be completely rewritten.

The original IOperf code would not compile:

[root@dh34 ioperf]# make
cc -lm -o Ioperf ioperf.c
ioperf.c: In function 'main':
ioperf.c:133: error: 'CLK_TCK' undeclared (first use in this function)
ioperf.c:133: error: (Each undeclared identifier is reported only once
ioperf.c:133: error: for each function it appears in.)
ioperf.c: In function 'get_timer':
ioperf.c:477: error: 'CLK_TCK' undeclared (first use in this function)
make: *** [Ioperf] Error 1

Comments in /usr/include/time.h and /usr/include/bits/time.h lead me to think that "CLK_TCK" is just an obsolete name for CLOCKS_PER_SEC, though this struck me odd, because ioperf code is also using CLOCKS_PER_SEC for CLK_SCALE.

I modified ioperf.h, changing

# define SCALE    CLK_TCK

to

# define SCALE    CLOCKS_PER_SEC

and it compiled, but there is clearly a problem with the real timing scale factor (perhaps simply off by 1 million?). 

So for now, these "real time" results are obviously not realistic numbers, BUT, they are would probably be correct in relative (ratio) terms -- twice as fast is twice as fast.  The CPU % is meaningless for the same reason.

Another limitation (and more important for our purposes) in the "stock" ioperf appears to be a 2GB file size limit.  To get around this, I added "-D_FILE_OFFSET_BITS=64" to the CFLAGS line in the makefile.  I was able to write a 39GB file after this, but there is an overflow at some point in one or more variables, because the printed filesize was -1989672960 in the standard output.  (Even at 8GB, the file size overflow appears).  While the html output has a different filesize that the standard output, it too appears to be incorrect above a certain point.  For instance, look at the third example below, in which the file size should be 8GB, but is instead only ~4GB.

With these two oddities (wrong real times and file sizes), I don't see much point in generating a lot of results at this time.

JUNE 27 update.  With some wanton changes of int, long int and size_t to 'long long int' in declarations and casting of the ioperf code, I was able to get correct file sizes everywhere (?) for a test with 8GB file size.  This still leaves the timing issue unresolved, so the actual rates are still not meaningful, I don't think, but now perhaps the results will at least be able to be contrasted amongst the different filesystems for relative differences.

On to some results:

Ioperf -l 5 -s 100 -n 100000 -html -w -m eastwood-hda:

Ioperf -l 5 -s 100 -n 100000 -html -w -m newman-hda:

(All this shows is that the two machines perform almost identically, as expected,since they are the same hardware.)

Ioperf -l 5 -s 100 -n 2000000 -html -w -m eastwood-hda

 No explanation why the Block IO and character results decreased so dramatically with each iteration...  (FWIW, according to the ioperf man page, each iteration is an average of the current result with all previous results, so it would seem that the first iteration was much faster than subsequent iterations for some reason...)  This may be a side effect of the incorrect filesize, since there is an overflowed variable going into the calculations.

June 27 update: at least the file sizes are now as expected with an 8GB file after some changes to make variables long long ints: