Example: http://www.primegrid.com/result.php?resultid=555370092

I have only recently returned to crunching for PrimeGrid after a lot of focus on other projects, so it will take a while to reeducate myself on all the subprojects.

The WU above expired on 17 JUL with 220 hrs crunched and 44 hrs remaining (80.89% complete). This is not right. I have a dual Xeon E5520 (Nehalem) with 24GB ECC RDIMMs. Yes, this machine is no longer a spring chicken, but it should be more capable than this. It runs BOINC 24/7 with the occasional snooze when I want to watch a video without choppiness. All 16 (8 + HT) cores are made available to BOINC projects. No GPU is available.

I just read a thread that mentioned the loss of performance when running LLR units on multiple cores at the same time. I hadn't been watching the system and I found that it was running 4 or more LLRs at once. I have since paused all but one at a time. Could this be a sufficient explanation for the long work time? If not, what else should I look at, or should I just select different subprojects?

It it generally recomended to run at max as many LLR tasks as you have physical cores available so your 4 tasks are ok with the 8 physical cores.

But your CPU has a bad performance on double precicion floting point operation compared to newer cpus that makes it a lot slower -> no AVX or FMA3 instrucion set and a slower clock per core than newer cpus

Second point is that LLR tasks benefit from fast RAM, and yours may have at best 1066Mhz. That also slows the computation.

So over all it's no unusual thing that those tasks take that long on your cpu.

As far as you have described this i can't see any method at speeding up those workunits. It may be best if you switch to another subproject with short tasks, where the execution time - deadline ration is better.

I aborted the task only after checking its status on this website, where it said something like "not completed in time", which I took to mean that I would not get credit for it. If I look at the status of the task now, it only shows that it was "aborted by user", which doesn't tell the whole story.

My original question was really about why my machine takes so long (in actual FLOPs/cycles/whatever) to complete the task. I didn't really think about the scheduling problem at the time. But that is also a concern. Shouldn't BOINC be smart enough by now (v7.2.42) to realize that the task is in such danger of being overdue that it won't pause it in favor of other projects? I don't have time to become an expert in the nuances of the scheduler algorithm, which over the years seems to have gotten too clever for its own good. I just let BOINC run unmolested, but I manually suspend projects when I want to focus 100% effort on my preferred projects.

I guess I will need to figure out which subprojects here are better suited to the instruction set on my CPU, and only subscribe to those.

I will also monitor the temp on my CPUs/memory to see if there is a noticeable problem there.

I aborted the task only after checking its status on this website, where it said something like "not completed in time", which I took to mean that I would not get credit for it. If I look at the status of the task now, it only shows that it was "aborted by user", which doesn't tell the whole story.

I guess I will need to figure out which subprojects here are better suited to the instruction set on my CPU, and only subscribe to those..

I will also monitor the temp on my CPUs/memory to see if there is a noticeable problem there.

You will get credit if you are one of the first two completions.

That is not correct, at least not at PrimeGrid. I can't speak as to how other projects handle late tasks.

You do not need to be one of the first two completions. Any task that returns the correct result before the workunit is purged from the database gets full credit. Workunits don't get purged from the database until several days/weeks/months (depending on the size of the task) after the last in-progress task has completed. In the case of Woodall tasks, the workunit is usually purged 14 days after the last task completes.

I just experienced something while running 8 copies of CUL on my i7. BOINC showed 3 of the workloads accumulating seconds on in the BOINC ELAPSED column but 5 of the workunits were not accumulating seconds and the ELAPSED column was blank ... implying none had yet accumulated any seconds. I checked the TASK MANAGER and it was running at 35% busy, like only 3 of 8 tasks were actually running.

5 of the CUL workloads seemed stuck and were confirmed by the Windows 7 task manager. I don't know how long it took the 5 CUL workloads to percolate to the the RUN state. Nothing I seemed to do in Boinc seemed to get all 8 CUL running. I finally shutdown Boinc and workloads ..... and restarted. When I restarted Boinc and workunits, all 8 CUL workloads restarted.

I watched them stuck for several minutes as I played with boinc knobs so I know it was happening.
I don't know how long that condition would persist OR if it would clear itself up.
This happened on my Haswell i7-4770 machine named sandybridge1 (ID: 238540 ). 6 of the 8 CUL workloads are still running.


It appeared to me like there was some resource deadlock in the BOINC/primgrid environment that stalled the start up and could not clear itsefl. There were no Windows events logged.

8 tasks means you have HT on. I'd turn that off to start with.

Then if still trouble try 75% CPU utilisation (3 cores) on BOINC options.