Lots of people are making the same mistake, often after seeing threads like this and getting worried.

Inconclusives are not errors.

Do not report inconclusives - wait until they are revalidated.

Thank you.

WCG is obviously a very complex project and I have times where I just do not understand what causes so many issues for crunchers. I have been away from HFCC for a few weeks, working on year 3 and 4 for NRW, and I have just gone back to HFCC.

So far I have 25 Valid, 1 Inconclusive and no errors. Seems to me that is how it should work. Now I do not do anything fancy to my systems but I have a variety of CPU, memory and Windows OS. Most of my systems are unattended (as far as WCG goes). I have had 34 systems loaded and only had 2 systems that gave me problems (1 was W98 and the other was a Windows SSL error on a XP SP1 system). I have had 32 of 34 WCG installs go flawlessly.

Its got to be very frustrating at times for the CAs having to support an infinite number of hardware configurations, firewalls, overclocking, AV issues, all compounded by choices users make during installation/operation.

I guess my point is that Murphy's law (Whatever can go wrong will go wrong) is alive and kicking within WCG, but it does not have to affect everyone. It is possible to get it right, so do not despair if you hit a bump in the road.

Started to have large numbers of Inconclusive (aka Pending Revalidation) on my quad for the zero redundancy projects followed with equal numbers of init 2 copies, until solving the mystery. The logs were mostly clean and some showed the infamous Loss of Heartbeat, which gave me the clue of the possible cause. 48 hours later, all ZR projects validate again immediately, no more init 2. The solution, too simple and now knowing that the minibench-maker is sufficiently influenced/impaired to let the validator decide it needed a second opinion for most.

Interest peaked? I'm sure some have come across this before and will share the answer.

Steve WCG,
I think it is one of the possible causes of temporarily switching your computer to double checking mode: when the server (not BM) detects a change of the performance of one device it will check its results by sending a second copy for the first WUs returned after the change and it will use redundancy for the WUs its sends you until it gets confirmation that everything is fine.

When you change the clock speed of your machine you should trigger a new benchmark. First because it is fair, next to have only one phase of redundancy mode. Otherwise you will have two per change. One when the server detects that your machine works faster ot slower than before, and this phase will still exist. But if you don't trigger the benchmark the server will detect a change of credits per hour when the regular scheduled benchmark occurs later, and you will get a second phase in redundancy mode.

Cheers. Jean.

@ JmBoullier and Sekerob

Thanks for the explanations. I had the same behavior when I updated to BOINC Manager 6.6.20 in order to use CUDA for better perfomance. This stopped when 15 new results had been validated.