(This is cross-posted from the project's forum:)

I'm noticing an odd behavior in BOINC 8.2.4 Manager. Perhaps this is always the case and I'm only noticing it now because the Amicable Numbers task completion times are so quick - usually less than 60 seconds, often less than 30 seconds, on my PC.

The GPU is running only one task. There is always another GPU task ready to start. As soon as the running task reaches 100% the next task and its elapsed timer starts. I timed the new running task with a stopwatch. BOINC reported 38 seconds to finish. But the stopwatch timed 108 seconds! This behavior is consistent regardless of the number of CPU tasks running, including only 1 (the CPU part of the one GPU task). The stopwatch time accurately reflects my task throughput over many hours.

Along with this, BOINC Manager Tasks page visibly alternates between freezes for several seconds and updating counters normally for several seconds. But During the freezes the task(s) appears to be crunching away steadily according to MSI Afterburner's GPU/CPU usage and power consumption.

Like I said, I haven't noticed this in any other project. Is anyone else seeing this?

Windows11, Ryzen9 7950X, RTX 4090. No unusual event log entries

Thanks

---

My WAG (Wild Arse Guess)- they're using Open CL, most likely without caching. So each time a Task starts, it's has to compile the kernel each time. Once that's done, it can actually start processing the Task.

---

Grant
Darwin NT.

In reply to Grant (SSSF)'s message of 23 Oct 2025:

My WAG (Wild Arse Guess)- they're using Open CL, most likely without caching. So each time a Task starts, it's has to compile the kernel each time. Once that's done, it can actually start processing the Task.

That makes sense regarding the task although I'd think such delays would be included in the elapsed time counter.

I'm still concerned about BOINC Manager Tasks tab freezing - the counters stop updating for all tasks/projects. I don't recall seeing this behavior before - maybe it's the latest version?

Thanks.

---

In reply to wprion's message of 23 Oct 2025:

I'm still concerned about BOINC Manager Tasks tab freezing - the counters stop updating for all tasks/projects. I don't recall seeing this behavior before - maybe it's the latest version?

I don't know about the Tabs freezing, but with Numberfields@home the Progress bar, Elapsed and Remaining (estimated) times all freeze for a second or 3 when the Scheduler is contacted and new work allocated. They then jump to their current value and continue along once the downloads start.
It's not something i've seen on other projects.

---

Grant
Darwin NT.

In reply to Grant (SSSF)'s message of 23 Oct 2025:

I don't know about the Tabs freezing, but with Numberfields@home the Progress bar, Elapsed and Remaining (estimated) times all freeze for a second or 3 when the Scheduler is contacted and new work allocated. They then jump to their current value and continue along once the downloads start.
It's not something i've seen on other projects.

Well, it's kinda like that, but Elapsed Time does NOT jump back to where it should be. I'm processing tasks back to back with only a couple of seconds delay on the start of the new task. Each task is actually crunching for around 60 - 100 seconds (verified by GPU/CPU monitors, watt meter), but the elapsed time shows as little as 6 - 20 seconds. And to be clear, this is Elapsed time, not CPU time.

In reply to wprion's message of 23 Oct 2025:

And to be clear, this is Elapsed time, not CPU time.

Elapsed time being Run time?
Looking at the results for the top 20 systems, and looking at the first 20 Valid results you have returned, it appears to be an issue with just your system (or you're the only person that frequently re-boots- see quote below).


From your other thread on that forum.

After a reboot, task runtimes are between 20-50 seconds.

After a few hours runtimes step-jump to 200-250 seconds. Again, clears up after a reboot.

It would appear that after several hours, the times become more realistic. Re-boot, and they become odd to say the least.

You aren't reserving a CPU core/thread to support the GPU Task (if so Run time & CPU time would be the same, or very similar- this is usually necessary for OpenCL on Nvidia to get full output from the GPU).
Are you running only one GPU Task at a time?
Are you running any CPU Tasks (that project or any other). How many cores/threads are in use?
If you run GPU-Z, how do the reported Runtimes (starting and ending of GPU Tasks) compare with the load graph on GPU-z after a reboot, and then after a while when the times become more realistic?
In Task Manager, does it show just the one instance (or however many you have set it to run) of the GPU application running at any given time (when times are weird and more realistic)?

I'm not sure how the Runtimes are actually determined- whether by the application while it is processing that Task and it then reports them to the Manager, or whether by the Manager which then reports them to the Task.


Very, very, very weird.

---

Grant
Darwin NT.

My RAC for the Amicable project has been consistent and growing. I think the actual task completion time has always been around 90-100 seconds based on stopwatch measurements and manual daily credit calculations. My BOINC's elapsed time reporting is completely inaccurate.

GPU load is fairly consistent with only a momentary drop to 0% upon task completion/new task start.

I'm running only 1 GPU task. I also run another 30 CPU-only tasks for a total of 31 out of 32 available threads. If I shut down all CPU-only tasks the hangs are still there. In the past I've loaded up 30 CPU tasks before (various projects) and could watch BOINC manager tasks tab update all its counters every second without hangs.

A long time ago I read somewhere that in Windows the boinb.exe and/or boincmgr.exe processes should be set to high priority. I haven't done that for years and haven't noticed any issues until now. My processes are set to the default "normal" priority. Last night I tried "above normal" and "high" priority and the hangs lessened but were still there. I'd rather suffer the annoyance of the hangs than take effort away from crunching. I mean, there's also a "real time" priority but I didn't try that. ;-)

I'm going to start a new thread on the priority question.

Thanks

---

In reply to wprion's message of 24 Oct 2025:

My RAC for the Amicable project has been consistent and growing. I think the actual task completion time has always been around 90-100 seconds based on stopwatch measurements and manual daily credit calculations. My BOINC's elapsed time reporting is completely inaccurate.

And the question is why does this happen on your system, and no one else's?
At the project, see if someone else with an NVidia GPU will reboot their system, and then check to see if their GPU processing times drop.

GPU load is fairly consistent with only a momentary drop to 0% upon task completion/new task start.

Is this the case when the short time are reported after a re-boot? Is this the case when the longer times are reported after several hours?
Does the extended pausing occur when the processing times are short and long? If so, is there any change in the length of the pause? Have you tried reserving a CPU core/thread to support the GPU Task to see what the impact is?
In GPU-z, are there any differences in Memory controller, Bus interface or Video engine loads between the longer and shorter Runtimes?


The issue you are describing looks like more an issue with the Science application running on the GPU- the short Runtime tasks are producing Valid results. The times shown in the BOINC Manager match the times show in the completed and Validated Task. That is the case for both the shorter and longer Runtime Tasks.

So everything points to an issue with the GPU application IMHO- it starts off processing Tasks at a very high throughput, but then drops down to a lower level after some time. Re-booting the system sorts it out (forcing a restart of the video driver would probably do the same thing, but most likely trash the currently running Task), or a few hours after a re-boot something else starts up on your system, impacting on the GPU processing.

A long time ago I read somewhere that in Windows the boinb.exe and/or boincmgr.exe processes should be set to high priority.

Only by someone that doesn't know what they are talking about.

---

Grant
Darwin NT.

The hanging Boinc manager resolved itself when I stopped running Amicable Numbers. AN works the GPU harder than any other project I've run, but it's still only one CPU thread. I'm running Einstein now and a full load of CPU tasks and the total CPU load looks the same as before. And the Tasks tab is updating every second - no hangs.

Thanks

In reply to wprion's message of 24 Oct 2025:

The hanging Boinc manager resolved itself when I stopped running Amicable Numbers. AN works the GPU harder than any other project I've run, but it's still only one CPU thread. I'm running Einstein now and a full load of CPU tasks and the total CPU load looks the same as before. And the Tasks tab is updating every second - no hangs.

So whatever is going on with the Runtimes is very probably related to the application as well.

And while it maybe only one thread, if it's not reserved to support the GPU Tasks, then that thread is still being shared with other processes (even if leaving a thread unused by BOINC).

---

Grant
Darwin NT.