A new problem

[jgillett]

OK - this thing has a mind of its own...

Every night the iMac backs up and then reboots (old habits). On reboot BOINC starts automatically. So far, so good.

This time, instead of BOINC running 3 seti cudas, 5 APs, and 3 pogs concurrently as it was nicely doing earlier, it is now still running 3 seti cudas but 8 pogs and no APs. All APs are now either waiting to run or ready to start. The 5 APs that were running before are now stuck.

Didn't change anything. Is there any way to get it back to the way it was as above - a nice friendly balance?

Over 48 years as a computer tech with the last 20 of that also as a web developer, running seti since May of '99, and I still don't get stuff like this.

Thanks - again.

[John P. Myers]

BOINC may be hitting the POGS harder because the deadline is sooner, making it more of a priority. It could also be POGS takes longer and you have more POGS WUs in your cache than AP.

[jgillett]

BOINC may be hitting the POGS harder because the deadline is sooner, making it more of a priority. It could also be POGS takes longer and you have more POGS WUs in your cache than AP.

Actually a LOT more pogs than APs right now, John. They've apparently decided to pick on me because overnight the number really went up.

Thanks.

[Mumps]

Actually, more recent versions of BOINC don't seem to treat your resource share the way you would expect. It's no longer an "instant in time" sort of allocation. BOINC actually looks at recent history and will try to get the recent hours run in line with your shares. So when you add a new project, the first thing it does is go crazy trying to run your new project to balance out the share to match your now current settings.

It also doesn't help, as JPM mentioned, when some projects hand out big chunks of work per request. Because then you do sometimes end up in situations where the work freshly downloaded looks like it will take more time than you'll have available to run them. Hence the "High Priority" status. I've seen projects, and I think POGs is one of them, that pretty much will stay at high priority because every time it reports work in, you get more work that keeps the pressure up to meet your deadlines.

One of the newer features that has been implemented though is the app_config.xml file. In that, you can set the max number of concurrent WU's you'll allow for a given application. For projects like POGs, that only have a single app, that makes it relatively easy. But historically I've noticed that work fetch doesn't pay attention to that limit, so if you set it to say 25% of your cores, the project will still send you enough work to feed 100% of your cores and immediately go into hysteria because BOINC knows it won't have enough time to finish. At least newer versions do block more downloads once a project goes to High Priority mode for a given project. (At least, that's what I think I've been seeing. I may be wrong on a lot of these observations. )

[jgillett]

Pogs is completing WUs very quickly, and, as you suggest, the more it sends in (even the occasional one at a time) the heavier the response in new WUs. I have just set pogs to 'no new tasks' to let the backlog clear out a bit. The list is so long there might even be enough in there to run to the challenge close, but will keep an eye on things. Possibly as that load lessens the APs will start up again.

Would you have, or are they available on the forum, suggested app_info and app_config files that might get this iMac more in line?

Thanks!

[zombie67]

It's best to take a deep breath, and take the long view. Stop trying to micro manage which tasks are running at any given time. Let BOINC work it out over weeks or months.

[jgillett]

OK...

[DrPop]

Something you run in to is the "due date" on a WU as well. BOINC will usually try to complete a WU with a sooner expiration date than one with an older date. So if POGs (for example) has WUs that are due back to the server sooner, and your AP WUs are good for maybe a couple weeks or something, then BOINC will keep burning through more and more POGs until the AP WUs' due date gets closer.
Hope that makes some sense.

[zombie67]

If you really wan to micro manage, the only way to make BOINC work exactly as you want is to run one project at a time. Let's say you want SETI 80% and Einstein 20%. Then run run SETI for 4 weeks, an then Einstein for 1 week.

Even using app_config.xml cannot get the job done, with the convoluted BOINC code. Eventually one project will over load, go into panic mode, and leave you with idle threads.

[jgillett]

If you really wan to micro manage, the only way to make BOINC work exactly as you want is to run one project at a time. Let's say you want SETI 80% and Einstein 20%. Then run run SETI for 4 weeks, an then Einstein for 1 week.

Nope, not trying to micro-manage. All I wanted was to get it back to running the way it was initially. Was not trying to stir up a mess here.

Even using app_config.xml cannot get the job done, with the convoluted BOINC code. Eventually one project will over load, go into panic mode, and leave you with idle threads.

Which I am finally understanding thanks to the help I've gotten here.

Thank you.