> On 14 Oct 2019, at 23:16, Gilles Sadowski <gillese...@gmail.com> wrote:
>
> Hello Alex.
>
>> [...]
>>
>> commit 7177cdc82fd5020442f833ea8947151366dec725
>> Author: Alex Herbert <aherb...@apache.org>
>> AuthorDate: Mon Oct 14 21:26:48 2019 +0100
>>
>> Better time estimate for stress test tasks.
>> ---
>> .../rng/examples/stress/StressTestCommand.java | 35
>> ++++++++++++++++++----
>> 1 file changed, 30 insertions(+), 5 deletions(-)
>>
>> [...]
>
> Did you investigate whether some coding project already provides
> such a utility, that could be reused?
No. Reusing a library would be nice if it works for the timing data generated
by PractRand.
I had a simple version for estimating time remaining that worked well for
Dieharder and BigCrush since they always take about the same length of time.
Using the mean execution time, the number of concurrent tasks and the number of
tasks left is pretty accurate.
When I recently ran the repeat of BigCrush it counted down from 96 hours
remaining quite nicely.
I have been testing with PractRand and that can fail very quickly (1000x faster
than a full length run) on certain generators. This makes it difficult to
estimate the time for a test run using the mean or even the median.
It doesn’t really matter for this application that the estimate is correct. The
stress test application currently prints out how far it is through running all
the tasks for each of the generators in the list. The estimate is a nice to
have but is not even recorded in the test results. It prints to console as the
tests are run.
I may look into a library if I have time. For now I tweak the code each time I
run PractRand. What is more important is to be able to run PractRand on my test
machine with many parallel jobs. The first attempt had out-of-memory errors as
it approached 2GB per PractRand process (on the C++ side) which exceeded the
RAM on the machine with multiple jobs. I’ve changed the settings to use less
tests and will see what happens overnight.
Alex
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org