I'm finding this to be quite a challenging sub project. It does take a serious amount of CPU time, even while multi threading them with 8 cores it takes me over 2 days for a single task.

I've gotten a few invalid tasks as well as a couple inconclusive tasks.

http://www.primegrid.com/results.php?userid=172547&offset=0&show_names=0&state=3&appid=13

http://www.primegrid.com/results.php?userid=172547&offset=0&show_names=0&state=6&appid=13

At between 1.2 - 1.3 MILLION seconds of CPU time it can be frustrating. But... this makes me want to try harder for this as it's more difficult to achieve.

So SoB can be a S.O.B. at times but I do feel it is worth the effort. So let the crunching continue!

This is a great incentive - "This project has a 50% long job credit bonus and a 10% conjecture credit bonus."

If it were me, I would fix whatever is wrong with the computer. Might as well abort everything that's in progress since there's a good chance that they're already corrupted and further processing on them would just be wasted.

If the CPU or memory is overclocked, go back to base clocks and see if you stop getting bad results.

Next thing to try is removing the ram and cleaning the contacts. Often, just re-seating the ram can fix the problem, but if you're going to do that you might as well grab a pencil eraser and clean off the contacts while you have the memory out.

It is not normal to get even a single bad result, and you have 3 and probably 5, out of a total of 9.

I had an FX-8120 a few years back that took over a week per SoB unit, but there was no MT and I ran 7 at a time on it. The newer Intels, like your i5-6400, are significantly faster at SoB than the AMD FX line.
That said, you shouldn't be getting errors no matter how long the task takes. It might be a good idea to do some testing on that FX-8350 system to see what the trouble could be.

Windows memory diagnostic tool, which I just found out about, detected no errors.

Base CPU clock restored.

Current SoB task aborted, new started. Will see how the next few turn out.

A few years ago I had 4 SoBs going & after stopping & restarting several times over their 4-day period all of a sudden upon restarting again they all went BOOM & blew up. Were 3 days in so 12 days of processing wasted.

A few years ago I had 4 SoBs going & after stopping & restarting several times over their 4-day period all of a sudden upon restarting again they all went BOOM & blew up. Were 3 days in so 12 days of processing wasted.

One more thing about AMD CPU ( that was heapen several times)
From unknown reason AMD CPU start to freeze from time time, then work few days perfectly.
Solution: remove cooler, remove CPU from socket, put CPU to socket again and put cooler back. I do that and next two years was no problem at all. So it looks like something is shifted in socket ( maybe from fan vibration) or from hot-cool period ( when computer is on or off)
Dont know is that case with you but cannot be hurt to do that.

Memory diagnostic from Windows will not find many errors at all. use memtest86+: it is very good tool and will find far more errors then windows diag tool

memtest86+ running on the 8350 machine. First pass won't be done b4 I go to work so I'm going to let it run several passes as I mentioned. About 100min to check the 32gb. Will see what the results are by this evening.

Thanks again for the help everyone.

memtest86+ running on the 8350 machine. First pass won't be done b4 I go to work so I'm going to let it run several passes as I mentioned. About 100min to check the 32gb. Will see what the results are by this evening.

Thanks again for the help everyone.

memtest86+ running on the 8350 machine. First pass won't be done b4 I go to work so I'm going to let it run several passes as I mentioned. About 100min to check the 32gb. Will see what the results are by this evening.

Thanks again for the help everyone.

7 hrs later, no memory errors detected. Back to crunching.

So memory is not faulty, but problem still exist. So you still have problem, and using those type of SOB task ,you in the time throw away big time for nothing ( if WU completed and marked as invalid)
Stop doing SOB, take shortest task and observe you computer. You can back to SOB every time later

As Michael Goetz said above, it seems to be this AMD 8350 machine. I don't know what is causing the problems, but it seems to just not be a good machine for SoB tasks. On the two other Intel machines, no issues. I checked the RAM, I returned the CPU to stock speeds, and still had issues with the main machine. It is my main machine and I do a lot of different things with it so no more SoB for now with that machine.

I just got my GOLD badge for SoB so I will be crunching other sub-projects with this AMD 8350.

Thank you everyone for your suggestions, ideas, and support.

Penguin wrote:

memtest86+ running on the 8350 machine.

7 hrs later, no memory errors detected. Back to crunching.

I am having problems getting S.O.B. jobs to finish within the deadline. I currently run a stock (non-overclocked) I7 8550U, 12 Gb main memory, although not multi-threaded. I currently have a task that is 86.49% complete with 4 days to go showing, (that figure does not come down as fast as it should, though...) that was due on Dec 26, 2018 - it shows as running for 28 days, so far! Any hints?
____________

I wonder whether multithreading makes that much of a difference on a KBL-R CPU which is power-limited down to 10/15/25(?) W.

KBL-S at 4.2 GHz on dual-channel RAM, with LLR's multithreading enabled, completes a SoB task in less than a day. Running SoB-LLR single-threaded but nothing else on this CPU at the same clock takes about 3 times as long.

Let's say you run the single-threaded SoB-LLR task and nothing else on your KBL-R at 1 GHz (with dual-channel RAM I presume). This should take less than 12 days. This coincides with what Michael saw in the database.

To answer the questions raised:

1) yes, that computer runs 24/7, power failures and Micro$oft Win 10 updates permitting.

2) that computer is also (currently) running 7 SETi@home CPU tasks, and a SAH Beta GPU task.

3) I don't know if I have Dual-channel RAM with two sticks of RAM in this computer - it is under warranty, and I don't want to unscrew the back to find out... With 12Gb, I probably have 8 and a 4 Gb sticks of SODIMM, so I only have the benefit of dual channel on 8 Gb...

Notice that I say "that computer", as I have 7 currently running, (5 laptops) with at least another three waiting for me to fix them! (I just got back from a 'round the world trip Dec 26, and am only now getting my biologic clock back on my home time zone {American Pacific Standard Time...[there is a Australian Pacific time zone, too, as I understand it...]})

When I gave my figures, I had to use the figure in the "elapsed" column, as I don't know when this task actually started, not being home at the time (see last paragraph...) that the WU started. I would not be surprised if the discrepancy is because the WU started and was then laid aside for other higher-priority WU's, not necessarily from PrimeGrid, or because PrimeGrid ran out of allotted "Resource Share" time... (as I recall, I got 8 PG WU's at once, only one of which was this SOB task...)

So, do you run the SoB-LLR task together with SETI@Home CPU tasks and/or with a S@H GPU task? All of these are memory intensive, and degrade each others' performance.

My suggestion:
1. Suspend the SoB task.
2. Finish all SETI tasks and don't fetch more.
3. Create a projects\www.primegrid.com\app_config.xml which specifies multithreading for llrSOB. See e.g. the top of the current Conjunction of Venus & Jupiter Challenge forum thread for an example file.
4. Shutdown and restart the boinc-client to bring the app_config.xml into effect.
5. Resume the SoB task and run it exclusively. Double-check in taskmanager that the task is indeed using more than one core.

Most of PrimeGrid's LLR based subprojects run very poorly if not multithreaded (or rather: if they they run together with other tasks and have to fight them for cache and for RAM bandwidth). On another note, I was never satisfied with boinc-client's built-in task scheduling policy whenever I had a mix of singlethreaded and multithreaded applications. Therefore I never mix them anymore; when I want to run a multithreaded application, I run it exclusively and have all other BOINC projects disabled.