Dear Osamu,
Thanks for carefully looking
The write benchmark does not have to do it since read does it. So then we
spot the problem.
We could do it for the sequential pattern too, that is right. I do have
much more confidence here that the result is bit identical than to the
random one. Would wonder if random works but sequential doesn't. The
amounts of data to check for random is far less so this is literally no
overhead while for the sequential it may add performance issues when e.g.
reading from bust buffer. Truly we could have done it but i hope u
understand this rationales here.
Regards
Julian
Am 26.09.2017 1:34 nachm. schrieb "Osamu Tatebe"
<tatebe(a)cs.tsukuba.ac.jp>jp>:
Hi George and all,
Thanks for the information.
BTW, ior_hard read benchmark has the option -R, which
means readCheck. Why only this benchmark has the check
option? Other write and read benchmarks do not have it.
Regards,
Osamu
From: Georgios Markomanolis <georgios.markomanolis(a)kaust.edu.sa>
Subject: Re: [IO-500] Running of the benchmark
Date: Fri, 1 Sep 2017 08:31:17 +0000
Dear Osamu,
The auto-detect is useful to tune the parameters for the five minutes
minimum
execution of the benchmark but this does not apply for the find
command as it is too difficult and too extreme probably (Julian correct me
if you have different opinion). Thus, the subtree is not important during
auto-detect.
configs/kaust-georgios instructions in the 4th bullet about how to use
the parallel find and how to define the number of the processes which
should participate during the parallel find.
As we are not the ones who developed some of these benchmarks (we just
use them)
we have not documented, but it is good idea to describe them,
thanks for your feedback.
Best regards,
George
________________________________________
George Markomanolis, PhD
Computational Scientist
KAUST Supercomputing Laboratory (KSL)
King Abdullah University of Science & Technology
Al Khawarizmi Bldg. (1) Room 0123
Thuwal
Kingdom of Saudi Arabia
Mob: +966 56 325 9012
Office: +966 12 808 0393 <tel:%2B966%2012%20808%200683>
On 01/09/2017, 9:14 AM, "IO-500 on behalf of Osamu Tatebe" <
io-500-bounces(a)vi4io.org on behalf of tatebe(a)cs.tsukuba.ac.jp> wrote:
Hi Julian and Georgios,
Thanks for the information about scripts.
Regarding subtree.cfg, it seems not to be determined by
auto-detect.sh. This may effect the find and the mdtest
benchmarks. How do we think about it?
Also, if there is a document or an information about
the benchmark itself, i.e. ior-easy, md-easy, ior-hard,
md-hard and find, please let us know.
Thanks,
Osamu
From: Julian Kunkel <juliankunkel(a)googlemail.com>
Subject: [IO-500] Running of the benchmark
Date: Tue, 29 Aug 2017 23:34:27 +0200
> Dear all,
> I pushed some cleanups to the repository and a README.md file (top
level).
> Hope that provides certain answers, we
know the description are not
> yet perfect, but they will be improved over time given that
additional
> questions arise.
>
> Thanks for those of you that send feedback, do not hesitate to
give
feedback.
>
> Do not hesitate to join the slack, here is the invite link that
shall
MjMyOTgxMDg0OTQ1LTE1MDQwNDE4MzctOTFmMmJiNmM4OQ
Usually, Georgios and me are there frequently and can help you with
any question that arises.
Regards
Julian
--
http://wr.informatik.uni-hamburg.de/people/julian_kunkel
_______________________________________________
IO-500 mailing list
IO-500(a)vi4io.org
https://www.vi4io.org/cgi-bin/mailman/listinfo/io-500
_______________________________________________
IO-500 mailing list
IO-500(a)vi4io.org
https://www.vi4io.org/cgi-bin/mailman/listinfo/io-500
________________________________
This message and its contents including attachments are intended solely
for the
original recipient. If you are not the intended recipient or have
received this message in error, please notify me immediately and delete
this message from your computer system. Any unauthorized use or
distribution is prohibited. Please consider the environment before printing
this email.