Your reply confuses me, because BOINC will know exactly how many clock cycles each work unit has received, so it should not matter how many other processes interrupt them or how often: the accounting is not affected by those interruptions.

No, I think this must have more to do with my machine's capability either exceeding or failing to meet that average used to decide what is granted. It's a system I built myself with an Asus AM2 motherboard, M2N-SLI Deluxe, but which has had BIOS upgrades supporting newer AM2+ and even AM3 CPUs. It currently uses a Phenom X4 9850 AM2+ overclocked a bit to 2.8GHz, and has 4GB of DDR2-800 (PC2-6400) RAM. It's still running Windows XP. I'm using WCG BOINC Manager v6.10.18, although I'm upgrading to 6.2.28 as I write this; I had already downloadedlong ago but forgot to execute the upgrade. (Why is there still not auto-updating for BOINC?) In terms of background processes, uTorrent consumes the most cycles behind WCG work units, but it's at least a full two orders of magnitude less (meaning trivial by comparison). The cycles consumed by other processes trails off dramatically past that.

This is the BOINC benchmark result, run with the usual suite of background processes (to represent its real daily capability):

Number of CPUs: 4
2831 floating point MIPS (Whetstone) per CPU
6058 integer MIPS (Dhrystone) per CPU

there could be tons of reasons you are getting short points...

I am assuming this is the same computer.

is there anything on your computer that could be takeing processer time... comptuer game or such... that might be makeing your time show up higher and your resultant results.

alother question i have is do you have a good MALWARE/ anti-V checker... you might have some Malware that is being sneaky and steeling your cycles when you are not looking.

when you crunch other WCG tasks do you see the same discrepancy or is it more 1:1 on the results.

it also could be something silly like you have 4 CPU's... are you crunching 4 of the same type of WU's... it has happened in the past that running more than 1 of the same type of WU has slowed the resultant process speed down.

solution you might try is
1) grab some sets of 4 diffrent types of project
2) have your computer running each of the 4 projects 1 type per cpu
3) check to see if your points improve

I have at least two machines which consistently underclaim, not all of the time, but more often than not. Long ago and far away in some other thread, there were details of the many reasons this happens. If I recall correctly, one of the main reasons was the benchmarks were were over claiming the capabilities of the machine, thus when the results were compared with the over claiming benchmark, they did not measure up, therefore the credit given was less than claimed. One machine is an AMD 2000+ and the other is an Intel Q6600, both stock.

Trying to figure out exactly why they are not being given claimed credit is an interesting intellectual exercise, but the real bottom line is the work units are getting crunched and they are consistently valid. The points are fun, but just try to buy a cup of java with them. Good luck.

Cheers

Specific to HFCC (and FAAH), can offer 2 things to try and improve the closeness of claim and grant:

1. Get the Process Lasso utility (only Windows) and set the zero redundancy science apps to process at 'Below Normal', where the default is 'Idle' priority. I'm changing it on Linux from Nice 19 to Nice 6 and get better grant.

2. Cache up more than a day of work and start BOINC scheduled networking to connect only 1 hour per day or more/less depending on the daily throughput and result upload/download MB volume. Ethernet traffic and WIFI sucks considerable juice which affects the mini[calibration/reference]tests inside these work units during the beginning and end phase which when the network is active always coincides with uploading.

Don't ask me to explain... works for me.