Message boards :
Number crunching :
Moo tasks ignore BOINC CPU preferences
Message board moderation
Author | Message |
---|---|
Send message Joined: 24 Oct 11 Posts: 23 Credit: 5,417,903 RAC: 0 |
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) |
Send message Joined: 24 Oct 11 Posts: 23 Credit: 5,417,903 RAC: 0 |
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.) |
Send message Joined: 22 Jun 11 Posts: 2080 Credit: 1,844,376,616 RAC: 12,696 |
Still a problem. 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. |
Send message Joined: 24 Oct 11 Posts: 23 Credit: 5,417,903 RAC: 0 |
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. |
Send message Joined: 20 Apr 11 Posts: 388 Credit: 822,356,221 RAC: 0 |
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 |
Send message Joined: 24 Oct 11 Posts: 23 Credit: 5,417,903 RAC: 0 |
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.) |
Send message Joined: 22 Jun 11 Posts: 2080 Credit: 1,844,376,616 RAC: 12,696 |
Hi. 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. |
Send message Joined: 24 Oct 11 Posts: 23 Credit: 5,417,903 RAC: 0 |
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. |
Send message Joined: 20 Apr 11 Posts: 388 Credit: 822,356,221 RAC: 0 |
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 |
Send message Joined: 24 Oct 11 Posts: 23 Credit: 5,417,903 RAC: 0 |
[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)... point to an issue??? |
Send message Joined: 20 Apr 11 Posts: 388 Credit: 822,356,221 RAC: 0 |
Does the approx 5 minute gap in the following ... 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 |
Send message Joined: 24 Oct 11 Posts: 23 Credit: 5,417,903 RAC: 0 |
Does the approx 5 minute gap in the following ... 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. |
Send message Joined: 5 May 11 Posts: 233 Credit: 351,414,150 RAC: 0 |
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 |
Send message Joined: 24 Oct 11 Posts: 23 Credit: 5,417,903 RAC: 0 |
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.) |
Send message Joined: 27 Jul 11 Posts: 342 Credit: 252,653,488 RAC: 0 |
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 |
Send message Joined: 24 Oct 11 Posts: 23 Credit: 5,417,903 RAC: 0 |
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] |
Send message Joined: 20 Apr 11 Posts: 388 Credit: 822,356,221 RAC: 0 |
...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 |
Send message Joined: 24 Nov 11 Posts: 9 Credit: 32,783,542 RAC: 0 |
" 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. |
Send message Joined: 20 Apr 11 Posts: 388 Credit: 822,356,221 RAC: 0 |
" And there's no extra dnetc518* processes running (and taking CPU time)" 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 |
Send message Joined: 24 Nov 11 Posts: 9 Credit: 32,783,542 RAC: 0 |
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. |