Do you allow BOINC to use 100% of CPU time? If not, change that setting to 100% and restart the BOINC client (or reboot your computer).

Disable this and also "Suspend when no mouse or keyboard input in last xx minutes". Or simply set it to "run always" in the activity menu, than it will ignore all of that and won't suspend anything.

I've seen this occasionally on my Windows machines. Hasn't affected the Linux boxes, so I wondered if my Cloud Backup Software latched on to the file and didn't properly close the handle. [I backup my ProgramData folder for the XML/INI/Config Files and haven't told the backup software to exclude the various WCG workfiles.]

A Suspend | Resume on the Project, or reboot always alleviates the matter. Of course watching the queue isn't something that I do religiously so if I find one, it's many days old by the time I find. However, it's been 4+ months since I last seen one hung.

> so I wondered if my Cloud Backup Software latched on to the file

Don't use Cloud b/u (or any real-time B/U).

>A Suspend | Resume on the Project, or reboot always alleviates the matter.

Suspend/Resume/ Close BOINC Mgr works on some instances when tehy are well advanced, but not for these recent cases.

Reboot is not practical every time it happens... (last reboot was 11 days ago).

Richard

Richard,

People have been offering possible solutions but they have been working in the dark because, unlike other BOINC-based projects, WCG gives us no way of determining various useful diagnostic points

So, with apologies in advance if you are already aware of some (or all) of the below...

For anyone to really help, the following information is more or less essential:

• What hardware (CPU, memory capacity)?
  
• What O/S?
  
• What BOINC client?
  
• How many "CPUs" is BOINC allowed to use?
  
• Is the CPU time set at below 100% (and if so, why)?
  
• Is "Leave applications in memory" set (and if not, why not)?
  
• Is work being done for non-WCG projects as well?
  

See what I mean about working in the dark?

Because of the way this thread has progressed(?) we can deduce [partial] answers to many of these points -- something Intel?, Windows?, 80% of unknown number of CPUs. 100% time) -- but we don't know what processor or RAM capacity (which may or may not be key!)

We all seem to have been assuming that there isn't some sort of throttling being imposed by the hardware (power limit or over-temperature limit). I once had a Ryzen running one application at a time at less than 1GHz because the CPU fan had stopped running (a problem soon resolved, of course!), so some really odd things can happen; most cases are less extreme than that!...

Another reason for performance issues is when the amount of work on the system results in memory overload (either bandwidth issues or actual swapping!) -- whilst MCM1 doesn't currently have a particularly large footprint, who knows what else might be present and eating memory...

If you are feeling particularly intrepid you could have a look in the BOINC slots directory for tasks that seem stuck at 0.5%. There should be a "stdout" file - not sure how it's named in Windows - which might give some clues. One common reason for tasks seeming to get stuck at 0.5% is that the watchdog thread for the application sees that the task hasn't initialized within some deadline interval so it assumes the initialization failed and tries to restart the task! That is why folks mentioned that one shouldn't do less than 100% of CPU time (MCM1 is known to have problems on some systems where users do that to reduce temperatures or fan noise!)

Just some thoughts -- as I said, sorry if you were already aware of all this...

Good luck getting it sorted out!

Cheers - Al.