Hello. I ended up resetting, removing, and re-adding E@H. Added the special app back in, and over the last 24 hours, everything seems to be working correctly again. I still get the 4 hour back off, but now receive more than 4 hours worth of work per update. Not sure what changed, as I tried this a few times before posting this issue, but seems to be working at t the moment.
To answer your question, did not change anything inside the app_info.xml file. Just unzipped the special app, and placed inside the E@H directory.
I wonder if it has something to do with REC debt balancing. You mentioned Einstein was the only gpu project you were running.
But that leads to assume you are running other BOINC projects that are cpu.
The REC debt mechanism does not care about gpus or cpus, it just needs to balance the credit among all your projects.
If you have a cpu project(s) that are of very low RAC credit or very low resource share compared to Einstein, the client may feel that the Einstein project needs to hit a pause or breather to let your other projects catch up to the RAC level the Einstein project has been sustaining.
For what-it-is-worth, the exact same thing happened to me once I started using the new/special app as well. In my case, I have always been getting plenty of work to fill the 4 hours so it has had no practical impact (and probably helps the server as well with less total contacts.) I have been following this thread and tried all the same recommendations to no avail. Currently I am crunching only one other CPU project (SiDock) and have NNT marked for my other GPU project (GPUGrid) on this computer.
Yes, I am running a few other projects that are CPU only. I'll keep an eye on this, and if the problem resurfaces, will play around with the Resource Share. Thanks again for the help.
Keith Myers wrote:
I wonder if it has something to do with REC debt balancing. You mentioned Einstein was the only gpu project you were running.
But that leads to assume you are running other BOINC projects that are cpu.
The REC debt mechanism does not care about gpus or cpus, it just needs to balance the credit among all your projects.
If you have a cpu project(s) that are of very low RAC credit or very low resource share compared to Einstein, the client may feel that the Einstein project needs to hit a pause or breather to let your other projects catch up to the RAC level the Einstein project has been sustaining.
This makes the balancing go faster by changing the averaging from ten days of credit to only one day of credit.
Would this also fix the problem of downloading work to a pc that has Einstein as a zero resource share Project and cache settings of 0.5 and 0.1 that already has a few hundred very short tasks from another Project from getting alot of Einstein tasks and then trying to run them immediately? Einstein was just recently enabled as a 'get tasks from here if you can't get tasks from there' Project. The other Project has a setting of 1 or 2, I use 100 as the max for my resource settings as it's easy to keep track of for me.
It could. Mainly the setting prevents any one project from dominating crunching for too long. Task crunching will switch off faster to your other projects before swinging back to your 100 resource projects.
It could. Mainly the setting prevents any one project from dominating crunching for too long. Task crunching will switch off faster to your other projects before swinging back to your 100 resource projects.
Thank you very much, I went around to all my pc's and put it in the ones it was missing on, I fould it already in one. ;-))
Hello. I ended up resetting,
)
Hello. I ended up resetting, removing, and re-adding E@H. Added the special app back in, and over the last 24 hours, everything seems to be working correctly again. I still get the 4 hour back off, but now receive more than 4 hours worth of work per update. Not sure what changed, as I tried this a few times before posting this issue, but seems to be working at t the moment.
To answer your question, did not change anything inside the app_info.xml file. Just unzipped the special app, and placed inside the E@H directory.
Appreciate the help.
I wonder if it has something
)
I wonder if it has something to do with REC debt balancing. You mentioned Einstein was the only gpu project you were running.
But that leads to assume you are running other BOINC projects that are cpu.
The REC debt mechanism does not care about gpus or cpus, it just needs to balance the credit among all your projects.
If you have a cpu project(s) that are of very low RAC credit or very low resource share compared to Einstein, the client may feel that the Einstein project needs to hit a pause or breather to let your other projects catch up to the RAC level the Einstein project has been sustaining.
For what-it-is-worth, the
)
For what-it-is-worth, the exact same thing happened to me once I started using the new/special app as well. In my case, I have always been getting plenty of work to fill the 4 hours so it has had no practical impact (and probably helps the server as well with less total contacts.) I have been following this thread and tried all the same recommendations to no avail. Currently I am crunching only one other CPU project (SiDock) and have NNT marked for my other GPU project (GPUGrid) on this computer.
Yes, I am running a few other
)
Yes, I am running a few other projects that are CPU only. I'll keep an eye on this, and if the problem resurfaces, will play around with the Resource Share. Thanks again for the help.
You can help the client
)
You can help the client balance project debt faster by changing one of the client defaults that harks back to the days of dial-up internet.
Change this value in Options in cc_config.xml from:
<rec_half_life_days>10.000000</rec_half_life_days>
to:
<rec_half_life_days>1.000000</rec_half_life_days>
This makes the balancing go faster by changing the averaging from ten days of credit to only one day of credit.
Keith Myers wrote: You can
)
Would this also fix the problem of downloading work to a pc that has Einstein as a zero resource share Project and cache settings of 0.5 and 0.1 that already has a few hundred very short tasks from another Project from getting alot of Einstein tasks and then trying to run them immediately? Einstein was just recently enabled as a 'get tasks from here if you can't get tasks from there' Project. The other Project has a setting of 1 or 2, I use 100 as the max for my resource settings as it's easy to keep track of for me.
It could. Mainly the setting
)
It could. Mainly the setting prevents any one project from dominating crunching for too long. Task crunching will switch off faster to your other projects before swinging back to your 100 resource projects.
Keith Myers wrote: It
)
Thank you very much, I went around to all my pc's and put it in the ones it was missing on, I fould it already in one. ;-))