It's a double read? I thought it was just checking a byte pattern that was imposed
during the write phase. Something like the rank. But I just thought. I haven't looked
at code. The intention, as you say Osamu, was not to do a double read.
Thanks
John
On Sep 26, 2017, at 7:53 PM, Osamu Tatebe
<tatebe(a)cs.tsukuba.ac.jp> wrote:
Hi Julian,
This checkRead re-reads data and check for errors between
reads. I am afraid this re-read check may not be your
intention.
Regards,
Osamu
From: Julian Kunkel <juliankunkel(a)googlemail.com>
Subject: Re: [IO-500] Running of the benchmark
Date: Tue, 26 Sep 2017 20:07:24 +0200
> 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>:
>
>> 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.
>>>
>>> Check in
https://github.com/VI4IO/io-500-dev/tree/master/site-
>> 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
>>>> never expire:
>>>>
https://join.slack.com/t/vi4io/shared_invite/
>> 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.
>>
_______________________________________________
IO-500 mailing list
IO-500(a)vi4io.org
https://www.vi4io.org/cgi-bin/mailman/listinfo/io-500