Message boards : ATLAS application : highly variable credit points
Message board moderation

To post messages, you must log in.

Previous · 1 · 2

AuthorMessage
Profile HerveUAE
Avatar

Send message
Joined: 18 Dec 16
Posts: 123
Credit: 37,495,365
RAC: 0
Message 31955 - Posted: 15 Aug 2017, 17:43:01 UTC - in response to Message 31944.  

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.
ID: 31955 · Report as offensive     Reply Quote
gyllic

Send message
Joined: 9 Dec 14
Posts: 202
Credit: 2,533,875
RAC: 0
Message 31956 - Posted: 15 Aug 2017, 18:18:34 UTC - in response to Message 31944.  
Last modified: 15 Aug 2017, 18:20:08 UTC

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...
ID: 31956 · Report as offensive     Reply Quote
Erich56

Send message
Joined: 18 Dec 15
Posts: 1686
Credit: 100,471,045
RAC: 104,120
Message 31957 - Posted: 15 Aug 2017, 19:33:11 UTC - in response to Message 31956.  

... 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.
ID: 31957 · Report as offensive     Reply Quote
Harri Liljeroos
Avatar

Send message
Joined: 28 Sep 04
Posts: 674
Credit: 43,168,198
RAC: 16,211
Message 31958 - Posted: 15 Aug 2017, 20:07:54 UTC
Last modified: 15 Aug 2017, 20:08:20 UTC

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.
ID: 31958 · Report as offensive     Reply Quote
Erich56

Send message
Joined: 18 Dec 15
Posts: 1686
Credit: 100,471,045
RAC: 104,120
Message 31959 - Posted: 16 Aug 2017, 4:50:35 UTC - in response to Message 31958.  

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 :-(
ID: 31959 · Report as offensive     Reply Quote
computezrmle
Volunteer moderator
Volunteer developer
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 15 Jun 08
Posts: 2386
Credit: 223,022,943
RAC: 136,367
Message 31960 - Posted: 16 Aug 2017, 5:47:14 UTC

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.
ID: 31960 · Report as offensive     Reply Quote
Erich56

Send message
Joined: 18 Dec 15
Posts: 1686
Credit: 100,471,045
RAC: 104,120
Message 31985 - Posted: 17 Aug 2017, 12:26:57 UTC

David, any comment on the current situation/problem from your side?
ID: 31985 · Report as offensive     Reply Quote
Erich56

Send message
Joined: 18 Dec 15
Posts: 1686
Credit: 100,471,045
RAC: 104,120
Message 31988 - Posted: 18 Aug 2017, 14:04:25 UTC - in response to Message 31985.  

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.
ID: 31988 · Report as offensive     Reply Quote
David Cameron
Project administrator
Project developer
Project scientist

Send message
Joined: 13 May 14
Posts: 387
Credit: 15,314,184
RAC: 0
Message 32040 - Posted: 22 Aug 2017, 9:19:42 UTC

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.
ID: 32040 · Report as offensive     Reply Quote
computezrmle
Volunteer moderator
Volunteer developer
Volunteer tester
Help desk expert
Avatar

Send message
Joined: 15 Jun 08
Posts: 2386
Credit: 223,022,943
RAC: 136,367
Message 32041 - Posted: 22 Aug 2017, 9:32:48 UTC - in response to Message 32040.  

@ 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.
ID: 32041 · Report as offensive     Reply Quote
tullio

Send message
Joined: 19 Feb 08
Posts: 708
Credit: 4,336,250
RAC: 0
Message 32529 - Posted: 26 Sep 2017, 17:59:46 UTC

I got a huge credit 3,208.73 on task 157945379 which must have used one core.
Tullio
ID: 32529 · Report as offensive     Reply Quote
maeax

Send message
Joined: 2 May 07
Posts: 2071
Credit: 156,189,624
RAC: 104,260
Message 32564 - Posted: 29 Sep 2017, 15:52:06 UTC

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.
ID: 32564 · Report as offensive     Reply Quote
Erich56

Send message
Joined: 18 Dec 15
Posts: 1686
Credit: 100,471,045
RAC: 104,120
Message 32568 - Posted: 29 Sep 2017, 19:38:49 UTC - in response to Message 32564.  

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?
ID: 32568 · Report as offensive     Reply Quote
Erich56

Send message
Joined: 18 Dec 15
Posts: 1686
Credit: 100,471,045
RAC: 104,120
Message 33875 - Posted: 16 Jan 2018, 6:23:43 UTC

what I have noticed since yesterday: the current ATLAS tasks yield awfully low credit points.
Any idea why so?
ID: 33875 · Report as offensive     Reply Quote
Harri Liljeroos
Avatar

Send message
Joined: 28 Sep 04
Posts: 674
Credit: 43,168,198
RAC: 16,211
Message 33878 - Posted: 16 Jan 2018, 10:26:04 UTC

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.
ID: 33878 · Report as offensive     Reply Quote
Erich56

Send message
Joined: 18 Dec 15
Posts: 1686
Credit: 100,471,045
RAC: 104,120
Message 33887 - Posted: 17 Jan 2018, 11:54:06 UTC - in response to Message 33878.  

... 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.
ID: 33887 · Report as offensive     Reply Quote
AuxRx

Send message
Joined: 16 Sep 17
Posts: 100
Credit: 1,618,469
RAC: 0
Message 33888 - Posted: 17 Jan 2018, 12:08:19 UTC - in response to Message 33887.  

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.
ID: 33888 · Report as offensive     Reply Quote
Erich56

Send message
Joined: 18 Dec 15
Posts: 1686
Credit: 100,471,045
RAC: 104,120
Message 33889 - Posted: 17 Jan 2018, 12:43:24 UTC - in response to Message 33888.  

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?
ID: 33889 · Report as offensive     Reply Quote
AuxRx

Send message
Joined: 16 Sep 17
Posts: 100
Credit: 1,618,469
RAC: 0
Message 33891 - Posted: 17 Jan 2018, 13:31:25 UTC - in response to Message 33889.  

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.
ID: 33891 · Report as offensive     Reply Quote
Previous · 1 · 2

Message boards : ATLAS application : highly variable credit points


©2024 CERN