> 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

Reply via email to