On Jun 12, 2018, at 3:47 PM, Glenn Lockwood <glock(a)lbl.gov> wrote:
Hi John & Committee
I'd like to run IO-500 on our systems, but I have a few concerns that other sites may
also share. In the interests of gaining clarity and resolution before the deadline, I
figure I would ask them here rather than in private.
Concern #1: The current state of the authoritative IO-500 benchmark distribution is a
little unclear to me . As I understand it, there are two versions:
1. the official version, where each benchmark must run for at least five minutes
2. the stonewall version, where each benchmark is allowed to stop after five minutes
In addition, I've been confused by the different options of parallel find. It looks
like the most sensible one, pfind, is in the "utilities/find/old/" directory
whose name suggests it is old and I shouldn't be using it. Is this true?
The "new" pfind is part of the fprof utilities developed by LLNL/ORNL. They can
in the build/pfind/ directory, and enabled in the io500.sh file like:
io500_find_cmd_args="-s 300 -r $io500_result_dir/pfind_results"
For GPFS filesystems, the following should probably be used, though the above pfind will
also work (perhaps getting a comparison of both would also be interesting).
Concern #2: I can't help but notice that several HPC storage
vendors have been using the IO-500 results for marketing material ("IME is
holistically faster than DataWarp" and "DataWarp has the fastest peak flash
performance"). It is therefore conceivable that submitting anything but hero numbers
could be used to make me, my employer, or our vendor partners look bad. I don't want
my center's results being used to show how bad our storage solution is, especially if
the numbers are only low because I didn't tune the benchmarks optimally.
I think the sample size is too small as yet to make any definitive claims. However, the
same is true of Top-500 numbers as well. Everyone will slice them in the way that makes
their product look favourable (e.g. HP has the top number of systems on the Top-500, Cray
has X systems in the Top-10, IBM has the #1 system, or whatever).
For the IO-500 the vendors will tout their easy vs. hard results, or peak streaming, or
whatever makes them look good.
That shouldn't prevent us from gaining more insight into the storage system
As such, is it possible to submit results, hero or otherwise,
anonymously? Even though there's only a few 1.6 TB/sec file systems in production in
the world, even the pretense of anonymity would make me feel more secure in submitting
sub-optimal (or embarrassing) numbers.
The same could be said of the Linpack results. Vendors and sites spend days/weeks tuning
Linpack results, and system procurements are often designed to get a specific Top-500
While I'm not expecting that level of investment into IO-500 results, I'm sure
spend some time to optimize their performance.
IMHO, things that make the IO-500 results better (improved streaming, improved small IO,
improved create/stat/unlink/find, maybe improved MPI-IO middleware) will all result in
better real-world application performance.
The good news is that no matter what result you provide, it will almost certainly be in
top 500 results (top 50 more likely). In a few years the list will be more populated,
people will have more experience with running the test and the storage vendors will also
have looked at the test and tried to improve the IO performance in a useful way. At this
stage, however, I think it is important to just participate and get some momentum behind
On Tue, Jun 12, 2018 at 2:25 PM John Bent <johnbent(a)gmail.com>
> Hello IO500 friends,
> We are at a critical junction for IO500. Hopefully most of you joined this list
because you agree with the motivation behind IO500 and only a few of you joined to laugh
at its painful demise.
> To the former, the committee wants to remind you all that we will unveil the second
list at ISC18. As of now, we do have a few submissions but we fear they may be too few to
be sufficiently impressive to ensure our continued relevance. We are clearly still too
new to have achieved critical mass.
> We remain committed to the community's need for an IO500. Reporting only hero
numbers as was the pre-IO500 status quo hurts us all. Collecting a large historical data
set of IO performance benefits us all.
> Please help ensure the success of our effort by submitting results yourselves and by
encouraging and soliciting others to do so. The community stands ready to provide
assistance as is necessary although please remember that the benchmark is very easy to
John (on behalf of the committee)
IO-500 mailing list
IO-500 mailing list