It's not that it's inaccurate -- it's actually not working at all.
The app (in this case, the wrapper) is supposed to call a BOINC API periodically to tell the BOINC client what the current completion percentage is. It appears that this is not happening -- there's a bug in the wrapper somewhere.
You see the percentage appear to climb upwards, but that's only because when the app doesn't call the API, recent BOINC clients "guess" about the completion percentage and show you what it aught to be based on the elapsed time and how long BOINC expects the task to run. It's totally bogus. With an older BOINC client, the percentage would just stay at 0.00 the entire time.
I suspect the wrapper isn't calling the API because it's not seeing the % string coming out of LLR. You changed what goes into stderr, and that probably affected the detection of the % complete.
It should be an easy fix.
(I'm talking about the Windows wrapper. It's possible the behavior under Linux/Mac is different.)
Hope this helps!
Mike
/ 
Reply
Quote
rebirtherVolunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 2 Jan 13
Posts: 7479
Credit: 43,686,081
RAC: 42,669
It's not that it's inaccurate -- it's actually not working at all.
The app (in this case, the wrapper) is supposed to call a BOINC API periodically to tell the BOINC client what the current completion percentage is. It appears that this is not happening -- there's a bug in the wrapper somewhere.
You see the percentage appear to climb upwards, but that's only because when the app doesn't call the API, recent BOINC clients "guess" about the completion percentage and show you what it aught to be based on the elapsed time and how long BOINC expects the task to run. It's totally bogus. With an older BOINC client, the percentage would just stay at 0.00 the entire time.
I suspect the wrapper isn't calling the API because it's not seeing the % string coming out of LLR. You changed what goes into stderr, and that probably affected the detection of the % complete.
It should be an easy fix.
(I'm talking about the Windows wrapper. It's possible the behavior under Linux/Mac is different.)
Hope this helps!
Mike
Iam using
In ops you can define Exact fraction done? but I dont know if its ever working.
/ Reply
Quote
Iam using
<rsc_fpops_est>8e10</rsc_fpops_est>but its never accurate. Tell me about a fix so I can give you the code.
We set rsc_fpops_est dynamically based on the size of the candidate and the FFT size. It uses the same mechanism that's used to calculate the credits.
In ops you can define Exact fraction done? but I dont know if its ever working.
Not in ops. I don't think they ever modified the web page for it. You have to use SQL to set a field in the app table. Look at the columns in the app table -- it will be obvious which column it is. Set the value to 1.
None of that, however, is the problem. In the PrimeGrid wrapper, the wrapper creates a pipe from LLR's stdout, and reads that pipe. Whenever it sees the percentage string, it uses that number to send to the BOINC API to report percentage complete. For some reason, that's not working in the wrapper here. Something was changed. Unless this is fixed, none of the rest matters.
/ Reply
Quote