The Milkyway project's CPU usage sometimes drops to zero and stays that way. Especially if there is little (free) memory in the machine. Or if a background application with a high CPU/RAM requirement starts. After that, Milkyway won't restart hours later, and BOINC client task switching doesn't work either. (I spent many, many hours looking at Resource Monitor and the Boinc client)
I reproduced the error six times out of seven attempts on three computers using the following steps:
- the system/boinc client starts (Milkyway is running).
- I filled the RAM with data (free memory is about zero)
- I started Win-Defender from a .bat file with command line delay
- Windows-Defender completely loads the cpu/ram
- Milkyway detects high CPU usage and shuts down
- Windows-Defender ends (a lot of memory is freed up!)
- Milkyway did not start again, or stopped after 1...2 minutes, but the status changed to "Running".
- Milkyway project (not a task) manual suspension > another project (Einstein for me) starts immediately and works normally.
- The operation of the Milkyway project is restored only after the Boinc client is restarted (until the next shutdown)
***
Notes:
- then the Milkyway project does not freeze, it simply does not work
- this stop also stops the Boinc client in the sense that task switching does not work. Because of this, other projects do not start either.
- the result of the "load test" was the same for other cpu-loading programs (browser, etc.), so the problem is not caused by the operation of the antivirus
- With little free memory, Milkyway sometimes crashes even without heavy CPU load
- The other project that works for me is Einstein. This does not cause an error. It did not stop even with multiple and persistent cpu/ram overloads. It can be seen from the cpu usage that Einstein is also struggling, but he is pulling himself together. Its resource management is programmed to be very robust.
- when I realized this (three days ago) I stopped the Milkyway project. Only Einstein starts and has collected more credits in three days than previously in a week and a half.
***
Milkyway state is "Running", but no cpu usage:


.
Einstein project memorymanagement:
.
****
Boinc: 7.24.1 (x64); Win 10 Pro (x64)

I just restarted doing this project after taking a break from it. I got credit for about a week then kept getting zero credits a day. When I check Boinc the project keeps getting delisted from the projects I have going. I re-add it and it starts to run and the next day I have no credit and the project is off my project list again. Looking at my stats here it shows 225 work units "completed validation inclusive" These are all on n-body simulation units. How do I fix this?

All my Separation tasks are gone. *thumbsup*

Thanks, I've set mine to also run multiple lower CPU count WUs. Is there any performance increase you see for doing this?

MW only sends out the original task then if it needs a wingman task it generates it

both WUs say

minimum quorum	        1
initial replication	2 

...not sure what's the difference between quorum and replication, but quite obviously a send task IS needed to complete validation.

I've not heard the term 'wingman' task, but the task to complete the validation for BOTH WUs had already been generated, but neither has been sent to be run ... both have status Unsent.

Other DC (boinc) projects [e.g., Amicable numbers] which potentially tie up all the CPUs on one's PC have a mechanism where the max number of CPUs that can be used by any task is set by the user... and this is a straight-forward option within the Project preferences without any monkeying around:

Preferences for this project	Amicable Numbers preferences
                         ^ You can set a limit on the number of CPU cores used

LLP

This figure is fluctuating around a somewhat constant level.

Yes, and it should start to drop once we are through the pile of _0 tasks and start processing the resends. Until than (on average) we report one task, we get a replacement, and for the reported task a resend task is created, so the amount of ready to send tasks is pretty constant.

Two of my tasks are Completed, validation inconclusive:

https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=963991857
24 Jan 2024, 4:42:42 UTC CPU time (sec) 43,471.86 or over 12 hours
yet Task 936324031 is still Unsent
and
https://milkyway.cs.rpi.edu/milkyway/workunit.php?wuid=964000770
23 Jan 2024, 22:51:35 UTC CPU time (sec) 54,474.03 or over 15 hours
yet Task 936319099 is still Unsent

Not running any more tasks for now.

In general there's nothing wrong with planned shutdowns for server maintenance, they are necessary, every project has them on more or less regular basis and since they are planned, everyone can adapt to them. No idea about Cosmology, never crunched for them, but well, like I said, most projects are worse than Milkyway and have REAL issues.

Most problematic BOINC project? You don't seem to have much experience with problematic projects. That huge pile of ready to send tasks is perhaps not optimal, but that's all, not a real issue and seems to be fixed as we are down below 1 million now. SETI was a problematic project with it's permanently overloaded servers, WCG is a problematic project since Krembil runs it. But Milkyway? Sure, I'm not going to say everything is perfect, it's not, but at least there's a steady WU supply and the communication from the project staff improved recently, so we know what's going on. It would be really great, if Milkyway was the most problematic BOINC project and all other were better. Unfortunately most of them are worse and only very few are actually better.

... but that's nothing we can change by not crunching for Milkyway anyway, only project admin can fix it).

Well, by not crunching we can express our disappointment (and motivate project admin to fix the issue).

I'm severely tempted to stop crunching until this gets resolved.....

Any ideas?
It looks like the wing men also completed validation with no credit.

same issue here all of yesterday and today WUs validated with 0.00 credits

I guess you need to cancel separation tasks "waiting for assimilation" now, so they can finally be removed from our results lists.

Regarding one other change that appeared after the server maintenance: is ~3 million ready to send N-Body tasks the new target for the work generators? With that it will take up to two weeks before the _1 and any additional resend tasks make it through that pile (when we had 1.5 millions they needed around 5-7 days).

And since N-Body seem to always need two results to validate, wouldn't in make sense to set minimum quorum and with that initial replication to 2 ? Or are there any WUs, that validate with only one result?

I'm 99,9% sure that those are Separation tasks, that got stuck in the pipline, because of how they "finished" it. Also the pretty constant number of workunits waiting for validation, always around 460, is mainly showing Separation WUs I guess.

If it's a purchased system then the fan on the cpu is not the best of the best to keep the price where it was when you bought it, if you don't do things like that yourself talk to a local computer shop about which fan would be a better choice for your system. If you do do things like that yourself then a good all-in-one water cooled system should drop the temps 5 degrees with no problem, if you need to go further than a full blown water cooled system can drop them 10 degrees with no problem.

An easy answer to the heat is to take off the side of the pc and let the heat out or you can even blow a fan into the now open side. But I know that's not always possible with life going on around us.

The Intel Core i7-1255U is a laptop CPU, so likely there's not much that can be done about the cooling.

Also in most ready build PCs the CPU cooler isn't great and often not enough for running BOINC, but the main issue is usually the more or less the complete lack of adequate air flow. Usually this can only be fixed with a new computer case unless you are sure you have a good one with just not enough fans in it. This should always be the first step, even the best cooler won't help if the heat is accumulating inside the case. This is in particular important when using the PC for things like BOINC. While today's CPUs will simply throttle to protect themselves, there are many other parts running hot in case with no air flow and some of those parts do not have the possibility to protect themselves from overheating.

As far as I can see, the program has really begun to work sustainably. Apparently, it is the frequent stops that drive her into closed loops.
Thanks for the advice!

But in general, this is a big drawback of the program that it's work is not sustainable enough and it couldn't not prevent processor overheating.

It's almost like the system refuses to give me new work since 6 tasks for some odd reason did not get started by the deadline (downloaded dec 3 and supposed to be reported by the 15th). But these tasks have not gone well for the others. 2 random sampled tasks have validation inconclusive. One, the second in line had a computation error (file not found on linux).

I have reset the project, expanded the days from .3 to .5 and it refuses to send work.
The other projects then take over.

Is it this project or is it BOINC or whats going on?

It's almost like the system refuses to give me new work since 6 tasks for some odd reason did not get started by the deadline (downloaded dec 3 and supposed to be reported by the 15th). But these tasks have not gone well for the others. 2 random sampled tasks have validation inconclusive. One, the second in line had a computation error (file not found on linux).

I have reset the project, expanded the days from .3 to .5 and it refuses to send work.
The other projects then take over.

Is it this project or is it BOINC or whats going on?

Set the other projects to no new tasks and then up your cache to a full day or even 2 or 3 days, then ask MilkyWay for work, then once you get it remember to set your cache back where you like it and set your other projects to get tasks again. MilkyWay task can think they will take a long time and 0.3 or even 0.5 of a day may not be enough of a cache size.

As always Mikey, you have the answer!
Thanks and have a good holiday.