The title says it all.

See http://s65.photobucket.com/albums/h216/Ray_GTI-R/BOINC%20issues/Moo/ for more details.

Ray
(Same problem on my other PCs - when I posted the same thing IRO Moo GPU tasks Teemu asked me to create a new thread "for the CPU tasks not respecting BOINC preferences that's ... something I could probably do something with", so yer'tis)

---

Still a problem.

Teemu asked me to create this thread "for the CPU tasks not respecting BOINC preferences that's ... something I could probably do something with"

Hello?
(FWIW - "I'm working on it" is a valid response.)

Still a problem.

Teemu asked me to create this thread "for the CPU tasks not respecting BOINC preferences that's ... something I could probably do something with"

Hello?
(FWIW - "I'm working on it" is a valid response.)

Okay let's try again here...what exactly is Boinc doing? Are you seeing the cpu crunch at 100% when you set it to only use 50%, is that the problem? Because if so that is NOT a problem, it is a design issue. Boinc uses 100% of your cpu but only 50% of the time, in your case, so over time it will only use 50% of the cpu. It is kind of like offering you 2 quarters or 5 dimes, each is 50 cents it is just a different way of getting there.

Hi.

I understand your reply, but I disagree as follows:-

Refer to http://i65.photobucket.com/albums/h216/Ray_GTI-R/BOINC%20issues/Moo/MooTasksIgnorePreferencesD.jpg

These are Moo preferences, specifically "Use at most x% of CPU".

Emphasis on the words "at most". To me that means that for whatever reason x% must NOT be exceeded.

Design issue, feature, flaw, bug, defect, glitch ... whatever.

I call it a problem.

Turning to the averaging over time or mixing of cents. That's all well and good if you know in advance the exact amount you are dealing with. I don't know in advance how long my PC will be switched on/processing Moo tasks. A simple example:- if I intend to check my emails and it might take 30 minutes. If Moo uses 100% CPU for all that time (rather than my 50% setting) it follows that somehow Moo anticipates that my PC will be switched on for a total of 60 minutes and will run at 0% CPU for the remaining, non-existant 30 minutes. That is wrong - it's a problem. I know it doesn't work exactly like that in practice - yes, it's a lot more complicated and yes, over time it might average out at 50%. I refer back to the words "at most" ... it's much easier to get one's head around.

Still a problem.

Ah, yeah, haven't yet tried to figure out if there's something I can code to limit the CPU usage. Any changes I do requires a new app version deployed so until that happens, I haven't changed anything.

In any case, it could be that BOINC Client is the one that should limit our CPU usage. However, only thing it can do is sent a suspend commands to us and we should be respecting those already.

BTW, which of your host is the one you are trying to limit CPU used? I'd like to see if BOINC Client has indeed sent any suspend commands to it.

Oh, D.Net Client, which we use to do all the hard work, is set to only use any idle CPU time. So if your mail client wants cycles, it'll get them (even all of them). I'm just mentioning this in case you don't know this as this should limit the harm done by us using 100% CPU.

-w

Thanks Teemu.

The ones I'm most focussed on are Moo Computer IDs:- 7312, 4908 & 5323.

Cheers, Ray
(If it helps, the CPU usage isn't 100% all the time. Just an awful lot more time, consecutively, than I want. If it's a timing issue then I'd hazard a guess maybe Moo isn't checking CPU usage often enough - once every physical second might do the trick whereas it seems to check only every 5-10 seconds or sometimes longer??? Other BOINC tasks such as SETI [Lunatics enhanced binary] & Cosmology on e.g., Moo Computer ID 5085 never seem to exceed the BOINC/Project preferences on that PC.)

Hi.

I understand your reply, but I disagree as follows:-

Refer to http://i65.photobucket.com/albums/h216/Ray_GTI-R/BOINC%20issues/Moo/MooTasksIgnorePreferencesD.jpg

These are Moo preferences, specifically "Use at most x% of CPU".

Emphasis on the words "at most". To me that means that for whatever reason x% must NOT be exceeded.

Design issue, feature, flaw, bug, defect, glitch ... whatever.

I call it a problem.

Turning to the averaging over time or mixing of cents. That's all well and good if you know in advance the exact amount you are dealing with. I don't know in advance how long my PC will be switched on/processing Moo tasks. A simple example:- if I intend to check my emails and it might take 30 minutes. If Moo uses 100% CPU for all that time (rather than my 50% setting) it follows that somehow Moo anticipates that my PC will be switched on for a total of 60 minutes and will run at 0% CPU for the remaining, non-existant 30 minutes. That is wrong - it's a problem. I know it doesn't work exactly like that in practice - yes, it's a lot more complicated and yes, over time it might average out at 50%. I refer back to the words "at most" ... it's much easier to get one's head around.

Your problem is with the Boinc Master Programmer Dr. David Anderson of Seti, he is the originator of Boinc and still the Master Programmer, in short Boinc is 'his baby'. He came up with the averaging of the cpu that is leading to your problem. He does have a mailing list, but remember it is 'his baby' so be gentle! I have no idea but he could be up against a cross platform, meaning Linux, Windows and Mac etc, etc programming issue and this way solved it for all. I am NOT a programmer just a very long time Boinc user.

Hi mikey:-

Moo tasks ignore BOINC CPU preferences

mikey, SETI & Cosmology etc respect BOINC preferences. I know ... I checked before I posted the original message. I have also spent the last couple of hours comparing, adjusting BOINC & non-Moo preferences to re-check my facts on two completely different PCs. It's definitely a problem that manifests itself running Moo CPU tasks on the PCs mentioned. A similar issue exists for GPU tasks but there is a different thread for that erm, design issue. Trust me, if it were a general BOINC issue I would not have brought it up here (based on my perception of these symptoms).

Thanks Teemu for taking up this topic.

The ones I'm most focussed on are Moo Computer IDs:- 7312, 4908 & 5323.

Interesting, looking at those computers, BOINC Client indeed sends us the suspend command quite often. Like you can see, for example, in http://moowrap.net/result.php?resultid=6273835. Compare it to http://moowrap.net/result.php?resultid=6190048, which is from the computer that you say working correctly (or at least more correctly).

So in this level, it's the BOINC Client that does the limiting. Like I explained, D.Net Client that we use always takes uses all the "extra" CPU your system has everytime it's not paused. I would guess, because the working one is using 6.10 and broken 6.12 BOINC Client, that there are some problems/bugs/regressions in this area in the BOINC Client.. (And only its devs can do anything about that, if anybody can.)

However, I have added this as an issue for our wrapper so I can check if there's anything I can tell to D.Net Client to also limit CPU (and it might do a better job). But I can't promise that I find a way (or even when I get to work on this). :(

-w

[the] D.Net Client that we use always [use takes] all the "extra" CPU your system has

The problem explained.
Defined well :-)

"regressions" ... ahh - another synonym for problem! Congrats.

However, I have added this as an issue for our wrapper so I can check if there's anything I can tell to D.Net Client to also limit CPU (and it might do a better job).

I hope so [hugs]

Ray

Does the approx 5 minute gap in the following ...

[Dec 31 23:11:23 UTC] Running again after pause... (flagfile cleared)
[Dec 31 23:16:03 UTC] Paused... (found flagfile)

... point to an issue???

Does the approx 5 minute gap in the following ...

[Dec 31 23:11:23 UTC] Running again after pause... (flagfile cleared)
[Dec 31 23:16:03 UTC] Paused... (found flagfile)

... point to an issue???

I'm not sure how BOINC Client tries to limit our CPU usage so that might or might not be an issue. There's always some balancing between interrupting crunching too often (that uses CPU as well, for "nothing") and to actually get something crunched.

-w

Does the approx 5 minute gap in the following ...

[Dec 31 23:11:23 UTC] Running again after pause... (flagfile cleared)
[Dec 31 23:16:03 UTC] Paused... (found flagfile)

... point to an issue???

I would prefer many, very frequent

interrupting crunching ... (that uses CPU as well, for "nothing)"

rather than a blown CPU/GPU/motherboard or whatever due to overheating.

On second thoughts, let me refer back to the original point:- Moo tasks ignore BOINC CPU preferences.

Ray
PS:- For now I have set the local CPU "at most" preference on this PC down from 50% to 25% which seems to reduce Moo disobedience but at the expense of wasting time when running other non-Moo CPU tasks which do observe the 50% setting rather more obediently i.e., they are doing "nothing" a lot of the time thanks to this problem.

Its not a Moo issue, its the way BOINC is designed, and the way a facility is expressed.

The use at most x% of a cpu is not an exact science. That switch is there to limit the number of cores used in processing. It will therefore default to (for a quad) 25%, 50%, 75% or 100% (one, two, three or four cores) whatever value you set it chooses what it considers to be the closest number of cores to the percentage you entered.

In no way does the facility give the precise percentage option, thats a coding nightmare to end coding nightmares. The text painted to screen could be a little clearer, thats for sure, but that doesnt change the underlying use of that switch. So set a percentage of (say) 60% and you'll get two out of four cores on a quad enabled for BOINC, 27% will get one, etc etc.

It is in effect a crude switch to limit the number of Cores used in BOINC processing. We can all think up other preferences or wish lists for it based on the text painted to screen - hence it was somewhat unfortunate BOINC chose that form of text explanation painting to screen, but that text, or our personal wish list, will not alter what its coded to do - limit the cores used to a maximum granularity of whole cores.

Regards
Zy

Thanks, Zydor, for the reply which I appreciate and must have taken some significant time to compose. I strongly disagree for a number of factual, proveable reasons.

Its not a Moo issue

It is a Moo issue - that's why I posted here.
Non-Moo tasks work exceptionally well and within the 50% rule that I require. Moo does not. I can prove it and have previously done so. If you wish I can re-test on at least 3 significantly different PCs but please believe me ... this really is a Moo problem.

Teemu has agreed, if you wish I can quote.

The use at most x% of a cpu is not an exact science.

I have always understood and respect that.
However, the previous facts speak for themselves.

In no way does the facility give the precise percentage option

Again, I have always understood and respect that. It is, IMHO the granularity as mentioned previously - or the lack of it - is the Moo issue.

So set a percentage of (say) 60% and you'll get two out of four cores on a quad enabled for BOINC, 27% will get one, etc etc. It is in effect a crude switch to limit the number of Cores used in BOINC processing ... limit the cores used to a maximum granularity of whole cores.

Apologies for my ignorance but after many years running many BOINC tasks I have simply never observed this on non-Moo tasks.

If you are speaking on behalf of the Moo project and you wish to re-define the BOINC CPU usage user parameters then the Moo project should publish what it perceives the new interpretation of the BOINC parameters to be. In the meatime, Moo tasks ignore BOINC CPU preferences and is therefore ignoring the simple concepts used & observed by other projects as described in plain english via BOINC preferences.

With Respect, Ray

(If I'm wrong, show the proof.)

---

Ray

Zydor makes comment from his background experience of both BOINC and long term involvement in the IT industry.

In the projects he takes an interest in his advice/comment/observation is not necessarily factually correct as he is involved in projects as a cruncher and supporter, just the same as both of us.

He is not part of the project team, and, therefore, his comments are based on his experience, related to BOINC projects, and what he sees from other posting in forums and threads like this one. This is helped when a poster replies that his comments have lead to something which has helped solve the issue at concern.

John

Thanks, John Clark, for the clarification.

In desperation/exasperation set local preferences for BOINC "Use at most % CPU time" on this PC to the lowest and most ineffiecient[*] value I've ever used [*]especially for other projects ... i.e., 10%.

Still Moo uses e.g., 50% of one core for far too long and simultaneously some random % of the other core periodically then sleeps seemingly forever???. At this setting other projects just idle (relatively speaking).

I then set local preferences to 15%, same result. Then I set local preferences to 20% ... same result as I had previously set BOINC "Use at most % CPU time" to 25% & 50%. Nightmare!

This is not what I want.

Put another way - Moo is seriously out of my control on certain of my PCs.

Reminder ... Moo tasks ignore BOINC CPU preferences.

When will this be fixed?

Ray
(Happy to receive any positive response.)[/u]

...rather than a blown CPU/GPU/motherboard or whatever due to overheating.

If overheating is what you are trying to fight, then may I suggest running something like TThrottle (see http://www.efmer.eu/boinc/)? That does a good job of suspending crunching frequently and is quite effective at reducing heat output. However, it does affect all BOINC tasks and not just ours by default (you might be able to tweak it to only see Moo tasks).

But yes, that's just another workaround for the issue and I'm not trying to say it's enough.

PS:- For now I have set the local CPU "at most" preference on this PC down from 50% to 25% which seems to reduce Moo disobedience but at the expense of wasting time when running other non-Moo CPU tasks which do observe the 50% setting rather more obediently i.e., they are doing "nothing" a lot of the time thanks to this problem.

Interesting that other tasks are not affected. Is there any other wrapper based applications on the list of correctly behaving apps (for example, yoyo@home)? You didn't happen to run dnetc@home before moo and observed if they handled CPU preference?

Looking at your images again, it seems our tasks are in high priority mode. I wonder if that means BOINC Client is not limiting CPU usage for tasks it thinks might miss their deadline.

There's few other thing you could help me verify. When our log indicates that we are in pause mode, does our CPU usage drop to zero? And there's no extra dnetc518* processes running (and taking CPU time)? I mean, their number matches the number of tasks BOINC Manager says are running and also matches the number of dnetc_1.2_* controlling processes that are running?

BTW, I did take briefly a look at this some time ago and unfortunately it seems my first thought on how to fix this is not going to work. :( The D.Net Client we use doesn't have a parameter to limit CPU percentage usage (only number of CPUs and scheduling priority).

Have you considered disabling only CPU tasks (assuming there's a GPU) for Moo on the affected host? This change be done in our project preferences. While it's unfortunate to resort to that, it's totally understandable given your problems. At least until (and if) I can address the problem.

-w

" And there's no extra dnetc518* processes running (and taking CPU time)"

The above sentence, what does it imply? I am asking this question because two days back there was some thing wrong with Boinc. On exit when i switched on the task manager i found one thread of the above mentioned active. I re-installed Boinc but no help. Then i had to delete the the Boinc folders and again clean install which seems to have solved the problem for the time being.

" And there's no extra dnetc518* processes running (and taking CPU time)"
The above sentence, what does it imply?

There should be exactly one dnetc518* and one dnetc-1.2* process for each active task. This does include any tasks that were previously run and were left waiting in suspended state by the BOINC Client.

If there are any extra, left over cruncher processes then it can mean they consume CPU/GPU power when they shouldn't. It's possible their crunching is for nothing depending on what they are doing but at the very least their progress is probably not tracked correctly.

Hmm, you mean you terminated BOINC Client normally and it left the dnetc518* process still crunching? If so, this is a problem that sometimes seem to happen due to our wrapper or BOINC Client behaviour. Our new app version is probably a bit better at killing dnetc518* processes on exit but I believe there's also a BOINC Client version that had bugs in killing subprocesses.

-w

Thankyou very much for a answer. Its not just moo, some other projects also keep on happily crunching on exiting Boinc. Oh! well, at least moo is behaving these days.
Regards.