Well, based on your numbers, some of the conclusions seems to be:
1: For Vina, error-rate Amd >> error-rate Intel.
2: For all projects, error-rate Amd >> error-rate Intel.

The error-rate being higher for Amd is as you expected, but not sure all of the following results is as expected:
3: Total Error-rate for Vina is the same as total error-rate all projects. (1.88% and 1.89% is equal).
4: Error-rate Linux >> error-rate Windows. This is especially apparent for Vina.
5: Total error-rate during summer is much higher than total error-rate during winter. Winter is as mentioned 0.44% while summer is 4.58%.

If higher temperature is significant or if it's just an unlucky combination with the current batches of work being done during summer is difficult to know.

For what it's worth, I have 0 invalids and 0 errors in my results returned for however long it goes back, I would imagine thousands of results. I run at least 4 systems 24/7, 2 intel i7 and 2 AMD opteron, 40 cores total between those systems.

Its interesting how some are getting errors and some are not.

Hi,
I appreciate the various feedback.
However, the initial question is:
Why a reliable system (over years) based on AMD (Athlon II or Phenom II) architecture operating Ubuntu 10.04 x64 does generate more invalid results for VINA-based projects than for non-VINA based projects?

If the system would generate only invalid or error results, it would be probably easier to understand the problem root cause.
In my specific case (nonetheless it seems that I am not the only one), we have to understand what happens by 3.5% of the cases.
I am still thinking that the trouble is caused by an over-sensibility of the validator; maybe caused by cumulative rounding failures? ...

I am not willing to switch the concerned systems to Windows at least for the following reasons:

• License cost
  
• Computational efficiency
  
• Efficiency by memory management
  
• Maintenance work

Based on the different feedbacks, it seems that AMD Bulldozer CPU's do not experience similar troubles, likewise for Opteron.

Have a nice Sunday,
Yves

Seeing messages along the lines of "stable" overclock with project ABC but nothing but errors with project XYZ until decrease/remove the overclock isn't uncommon to see. This just shows that different applications uses cpu, cache, memory and hd differently, and all computers has a weakest spot. Even if you're not overclocking, it's possible Vina more frequently uses your computers weakest spot and this can more easily bring it over the edge and an error happens.

As for why Linux having more errors?
If not overlooked anything, you're running XP-32bit and Linux-64bit. For one thing this means Linux can use registers in CPU what's never used under windows-32bit. For another the 64bit-version is AFAIK faster and therefore will likely increase the heat on possibly the "wrong" spot for your system and bring it over the edge.

Even if you're also running 64-bit windows, the Linux and Windows-applications isn't the same and it's possible Linux is still faster and uses the "wrong" part of your system.


Another possibility is as you've indicated a buggy validator and it's not really anything wrong with any of your systems.

Now I'm not sure how the FAAH-Vina-results are, this can be:
a: Running same wu on same computer gives always the same result, bit-by-bit.
b: Running same wu on same computer gives always the same result, except time-stamps but results is saved as "human-readable" so can easily filter-out these different time-stamps.
c: Stopping and continuing a wu from checkpoint can give different results from running without re-start from checkpoint.
d: A random seed is choosen at start or during running and this can give completely different results.
e: Running same wu on same computer gives always the same result, but it includes a time-stamp and result is encoded so different time-stamp gives completely different result on disk.

If FAAH-VINA uses d or e, where's no method for you as an user to verify if your computer crunches correctly or is ocassionally generating garbage. If a or c on the other hand it's fairly easy to verify for yourself if it's the computer doing an error or something else. b is more time-consuming to handle but is also possible to verify. So, if assumes a, one method to verify is something like:

1: Download a couple days of VINA-work on a computer.
2: Disable network in BOINC, and stop BOINC.
3: Make backup-copy of your BOINC data-directory.
4: Re-start BOINC, and crunch through your work, but without uploading anything.
5: Stop BOINC again and make a new backup of your BOINC data-directory. Do not overwrite the other backup.
6: Re-start BOINC, upload & report the results.
7: Check if any of the results fails validation. If no errors, repeat from #1.

8: Then you do get one or more invalid results, stop BOINC and make a new backup of your current data-directory.
9: Restore your backup from #3.
10: Select to run only the tasks you had invalid results for.
11: After the invalid results is done, stop BOINC again.
12: Compare the new result-files with the ones from the backup in #5.

Assuming FAAH-VINA follows method a, difference in step #12 indicates a problem with your computer, either the hardware, the OS or possibly a buggy application. If you somehow manages to get the exact same result on the other hand, a problem with the validator or work-distribution pairing incompatible systems is more likely.

Also running some of the tasks that was validated to check how the results are can be an advantage. If all results is different this indicates FAAH-VINA probably uses either d or e and if this is the case where's really no way for you to verify with FAAH-VINA if you've got a computer-problem or not.

Using Mint 14 Cinnamon here and am happy with it but then again I don't own any amd just now..... and Mint is just another ubuntu clone.

I tried Mint 15 but that was during my set up phase with the new rig...It seemed to run OK but I was getting lesser benchmarks for some reason.

Tried playing with 12.04 lts a while back but CLI is tough for me. Maybe it is that thing about old dogs and new tricks. I certainly feel like an old dog.

Maybe you should just look for what is using the latest kernel in the hope that some tweak or other fixes your issue??

EDIT: Not to miss anything, turn off "Cool'n'Quiet in bios by the way