LHC@home

I have observed the same: on all my 3 computers the allocated credits are either "as before" or nearly half. It started some 3 days ago. I have not been able to identify any difference between those tasks. It seems random from what I see, but surely there are some explanation.

---

We are the product of random evolution.

another case of major difference in credits:

task 153600868 - runtime 12.679 secs - CPU time 22.983 secs - points: 250,92

task 153601314 - runtime 12.920 secs - CPU time 24.032 secs - points: 147,67

both 2-core tasks were from August 13. I have seen this also with tasks from the days before: some yielded higher points, some lower points.

any explanation for this inconsistency?

I agree that with just looking at the numbers you posted here it does not make much sense.
BUT in my opinion it is much more important that the developers and scientist use their valuable time to fix bugs/improve efficiency/develop new modells/etc... regarding the physical and computational problems/questions. They should not "waste" there time on how much credits a volunteer gets, because:
I understand that with the credit system a little competition within the volunteers is started which can lead to more computation time for the projects, but i think the majority of the volunteers are here to support great, important, and in my opinion extremely fascinating experiments and NOT to have more average credit per day than someone else.
But just my opinion...

... I understand that with the credit system a little competition within the volunteers is started which can lead to more computation time for the projects, but i think the majority of the volunteers are here to support great, important, and in my opinion extremely fascinating experiments and NOT to have more average credit per day than someone else.
But just my opinion...

I wouldn't that much see it from the point of competition between the volunteers (although this may play a role for some people, which is okay), but I'd rather see it as some kind of reward for the all of us who dedicate our time, our equipment and part of our electricity bill to keep a project alive.

And as there is this credit system exists, it makes only sense when it works properly.
If this cannot be assured (for what reason ever), it would be better to eliminate it.
Sorry for these strong words, but this is my opinion.

I have seen also the same variation on the credit as was posted as an example. And my latest task here: https://lhcathome.cern.ch/lhcathome/workunit.php?wuid=73586544 gave me 381.75 credits for the same run time and CPU time as the tasks giving about 145 or 275. Makes you wonder what is going on.

---

153571612 - runtime: 12.757 secs - CPU time: 23.726 secs - 365,88 points

153617987 - runtime: 12.950 secs - CPU time: 23.516 secs - 110.58 points

something's definitely out of order :-(

I suspect the credit miscalculation could be caused by a wrong <rsc_fpops_est> setting on the project server.

An unwelcome secondary effect of a wrong <rsc_fpops_est> is the miscalculation of the estimated runtime on the client.
This could end up in
- preventing other projects from downloading new WUs ("job cache full")
- downloading too much ATLAS work due to a very short ETA

Thus <rsc_fpops_est> should be checked and corrected by the project team asap.

David, any comment on the current situation/problem from your side?

task 153747540 - runtime 13.463 secs - CPU time 11.654 secs - 105.49 points

it's getting worse and worse :-(

for the time being, I've switched to other projects.

The estimated CPU time for tasks is estimated upstream and we translate this into a FLOPS estimate by multiplying by 3*10^9 (assuming 3 GHz processors). We have different batches of tasks in the system at the moment and they have different CPU estimates which may or may not be accurate, so this is why you can have tasks with similar CPU time but different FLOPS estimate and hence different credit.

Here you see number of tasks with each FLOPS estimate:

mysql> select rsc_fpops_est/1000/1000/1000, count(*) from workunit where appid=14 group by rsc_fpops_est;
+------------------------------+----------+
| rsc_fpops_est/1000/1000/1000 | count(*) |
+------------------------------+----------+
| 16020 | 5853 |
| 24300 | 4 |
| 33480 | 4 |
| 36000 | 8 |
| 36900 | 189 |
| 41040 | 1104 |
| 43200 | 2145 |
+------------------------------+----------+

I realise it can be annoying to get unpredictable credits but on average everyone is getting the same credits per WU.

@ David

The most annoying fact is that the local client estimates the WU's runtime based on flops and rsc_fpops_est.
If those values are unreliable it affects work fetch for other projects (non CERN).
In addition the real runtimes are sent back to the server and affect the individual flops value of the sending host (at least on a standard BOINC server).

Therefore it is important to send out flops and rsc_fpops_est as accurate as possible.

I got a huge credit 3,208.73 on task 157945379 which must have used one core.
Tullio

11k, 22k than 6k for the last three days.
For me 3 native apps and three windows apps. Allways the same configuration.

Example of Wenjing WU 1032k, 583k than 231k for the last three days.

11k, 22k than 6k for the last three days.
For me 3 native apps and three windows apps. Allways the same configuration.

Example of Wenjing WU 1032k, 583k than 231k for the last three days.

I wonder if there will ever be anybody who can logically explain all this?

what I have noticed since yesterday: the current ATLAS tasks yield awfully low credit points.
Any idea why so?

The tasks are also shorter than last week but that does not compensate the credit difference. You get about 2/3 of last weeks credit for same crunching time.

---

... You get about 2/3 of last weeks credit for same crunching time.

these low credits, plus the ongoing upload problems, have made me decide to choose projects other than ATLAS for the time being.

One cannot deny that ATLAS tasks achieved 2-3 times above average credit per day in the last months leading up to December. With the server issues that affect ATLAS more than Sixtrack, ATLAS has become less interesting, but this credit adjustment (if there was such a thing) would level the ground.

One cannot deny that ATLAS tasks achieved 2-3 times above average credit per day in the last months leading up to December.

The question is: what is the "average credit" for ATLAS?
Also: why is the credit for ATLAS that much volatile? Wouldn't it make more sense for everybody involved to have a straight figure, instead of up and down all the time? What are these changes good for?

The easiest and most meaningful way is to compare how much credit your system received for a certain time frame, i.e. day. CPU time is a limited resource after all.

The algorithm for credit is based on several variables and has been dissected a lot. But what counts -- at least for me -- is what you get at the end of the day (24h). And for similar CPUs and similar GFLOPS or duration I saw other users getting way less credit with other sub-projects.

I would also factor in the reliabilty of the project, the duration of tasks as an indicator of the risk to loose progress and so on. You can even fool the system to receive more credit than you have earned, but that defeats the point in my mind.

I went from 6000+ a day to 4000- when I switched from ATLAS to Sixtrack in November/December.

Volatility is introduced with varying GFLOPS, but please take the time to read up on how BOINC generates credit to learn the specifics. I only skimmed over the topic to answers the questions I had at the time.