Why are you using BOINC client 7.0.27? That's from June 2012. Many bug fixes since then, and several security patches.

Why are you using Debian 7 (Wheezy)? LTS expired in May 2018. No security updates at all since then, of which there have been numerous severe vulnerabilities.

I have an Ivy Bridge generation CPU as well, an i5-3570, but I run Debian 10 (Buster) and BOINC 7.14.2 on it. No reason not to keep it up to date, to be honest.

I'm not sure how to explain the runtime differences; e.g., running for 31 minutes but claiming over 6 hours. It could be the RAM failure like you said. I'd still do a clean install of the OS and put the latest and greatest on it.

The old boinc-client is the one in the now-defunct Debian 7 repository.
Re upgrading Linux from version 7: apt-get update / upgrade doesn't work.
No-one is going to bust in if it's only used for crunching WCG anyway.
The other day I did a clean install of Deb 10.3 on another machine.
Every SCC WU crashes immediately with a segmentation violation.
[Edit]: See workaround in thread Getting a lot of Errors Lately . Update: Workaround needed for SCC and worked OK for me on Deb10 [/Edit]
Deb 9 works OK. Deb 10 is a slow fat turkey on a USB stick, too.

And I'm busy battling hardware alligators ... I decided to fire up 4 devices that haven't crunched for a few months, ready to do some OpenPandemics work. 1 ran for a few days, then died with a dead RAM stick (the one overclaiming runtimes). Another went for 2 weeks, then dead as a dodo and it's not RAM. Motherboard I think. On another, mb RAM channel B is dead. The other had a dead RAM stick when I tried to start it. They had all run 18/24x7 happily for several years before their little holidays.

I have just replaced the dissimilar RAM combo with a 2 x 4GB pair, and it's back online.

@Rickjb,

I took a look at your computer and the jobs that had returned recently. It is matching successfully when verification copies are sent out. We also have checks inside each workunit that test both floating point and integer computations in order to make the job both resistant to replay attacks as well as to protect against memory flaws or miscomputations from overclocked machines. Based on what I see I do not have concerns about the correctness of the results being produced by your machine.

As far as the credit award goes, it is our position that credit is "for fun" and correct or incorrect awarding of it is not related to achieving the goals of the project (other than the benefit it gives from gamification or competition).

Our position on this stems from fact that the problem of assigning credit is really difficult. Awarding credit is an attempt to assign a value to an unknown and varying amount of work processed by a untrusted computer that reports its own assessment of its computing power and its own measurement of how long the job took to run. This is a problem and challenge that has existed since beginning of volunteer computing. It has also been EXTENSIVELY debated and discussed.

The system that is in place now works well enough on average over time. This is not to say that it is anywhere close to perfect (it isn't), but it works well enough most of the time. In your case, since your computer was "overclaiming" the system will have lowered the efficiency rating" of your computer and will thus lower the amount of credit per cpu sec it estimates as what your computer should be awarded going forward. Thus even though you got bonus credit now, you will get a little less credit going forward until it reaches a new equilibrium. Note that the "efficiency rating" is being updated on each result returned/validated so it is a continually adapting number. Thus your over-claim is mitigated overtime.

Since I have discussed credit here, the immediate response is likely to be for people to bring out their favored proposals to change the credit system. We are not looking at modifying the credit system at this time.

If there are people who have proposals to improve the credit system, they are encouraged to work with the BOINC project to make those changes. Note that many systems have been proposed over time and the overwhelming majority of them perform much worse then the current system. As a result, if you bring a proposed solution to them, you would need to be able to provide data and simulations of the performance of the proposed mechanism. The proposed solution would need to consider the range of BOINC projects as well as the existence of bad actors who try maximize points through ill means. It also needs to consider the fact that some projects use mostly integer based computations while others using floating point computations. Some run on GPUs and some on CPUs. Some are IO intensive and some use little IO. Some can run entirely in the CPU cache and some make extensive access to main memory. The proposed solution has to handle all of that complexity.

So IBM think's this is a game??? That's easy to say for someone who is being paid a salary, having their employer pay the electric bill, provide internet & software licenses and hardware and that 800,000 OPN WUs are being returned a day by "idle computers."