Also without 11 validated tasks being returned by the host, the host can never develop the endpoint APR rate of the host on the app. Without a proper APR rate, the host will never get the progress rate and estimated time remaining values correct. With nothing but exceeded time limit errors, the APR will never be developed or correct.
AFAICT Einstein@home ist still using the old project wide DCF instead of the new per app APR, which is why running more than one application creates quite a mess with estimated runtimes. IIRC completing one single task should bump it up enough to avoid any further EXIT_TIME_LIMIT_EXCEEDED errors, DCF always needed longer time to adjust if the estimated run times were too long, but if they were too short, one single WU rised it to whatever was needed to complete it (for example if something else was using lots of CPU time while it was running).
Keith Myers wrote:
The solution to this problem is to manually edit the p_iops and p_fiops values in the client_state.xml file and move the values there over by one or two decimal positions to make the host processing speed smaller.
AND disable re-running the benchmarks with <skip_cpu_benchmarks>1</skip_cpu_benchmarks> in cc_config.xml or you will get the wrong values back pretty soon.
All valid points. Yes, the APR mechanism in use by most BOINC projects is not used for projects running older or customized server software and are running the older DCF mechanism.
Good tip about disabling the benchmarks in the cc_config.xml file.
I'd try editing the benchmark values in the client_state.xml file and see if you can get a task to complete. All it takes is an edit to move the decimal point over to the left one position and save the file.
Keith Myers wrote:Also
)
AFAICT Einstein@home ist still using the old project wide DCF instead of the new per app APR, which is why running more than one application creates quite a mess with estimated runtimes. IIRC completing one single task should bump it up enough to avoid any further EXIT_TIME_LIMIT_EXCEEDED errors, DCF always needed longer time to adjust if the estimated run times were too long, but if they were too short, one single WU rised it to whatever was needed to complete it (for example if something else was using lots of CPU time while it was running).
AND disable re-running the benchmarks with <skip_cpu_benchmarks>1</skip_cpu_benchmarks> in cc_config.xml or you will get the wrong values back pretty soon.
.
So... what should I do?
)
So... what should I do?
All valid points. Yes, the
)
All valid points. Yes, the APR mechanism in use by most BOINC projects is not used for projects running older or customized server software and are running the older DCF mechanism.
Good tip about disabling the benchmarks in the cc_config.xml file.
I'd try editing the benchmark values in the client_state.xml file and see if you can get a task to complete. All it takes is an edit to move the decimal point over to the left one position and save the file.