Message boards :
ATLAS application :
highly variable credit points
Message board moderation
Previous · 1 · 2
Author | Message |
---|---|
Send message Joined: 18 Dec 16 Posts: 123 Credit: 37,495,365 RAC: 0 |
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. |
Send message Joined: 9 Dec 14 Posts: 202 Credit: 2,533,875 RAC: 0 |
another case of major difference in credits: 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... |
Send message Joined: 18 Dec 15 Posts: 1810 Credit: 118,239,996 RAC: 27,344 |
... 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. 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. |
Send message Joined: 28 Sep 04 Posts: 728 Credit: 48,813,554 RAC: 22,208 |
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. |
Send message Joined: 18 Dec 15 Posts: 1810 Credit: 118,239,996 RAC: 27,344 |
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 :-( |
Send message Joined: 15 Jun 08 Posts: 2528 Credit: 253,722,201 RAC: 62,755 |
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. |
Send message Joined: 18 Dec 15 Posts: 1810 Credit: 118,239,996 RAC: 27,344 |
David, any comment on the current situation/problem from your side? |
Send message Joined: 18 Dec 15 Posts: 1810 Credit: 118,239,996 RAC: 27,344 |
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. |
Send message Joined: 13 May 14 Posts: 387 Credit: 15,314,184 RAC: 0 |
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. |
Send message Joined: 15 Jun 08 Posts: 2528 Credit: 253,722,201 RAC: 62,755 |
@ 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. |
Send message Joined: 19 Feb 08 Posts: 708 Credit: 4,336,250 RAC: 0 |
I got a huge credit 3,208.73 on task 157945379 which must have used one core. Tullio |
Send message Joined: 2 May 07 Posts: 2240 Credit: 173,894,884 RAC: 3,757 |
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. |
Send message Joined: 18 Dec 15 Posts: 1810 Credit: 118,239,996 RAC: 27,344 |
11k, 22k than 6k for the last three days. I wonder if there will ever be anybody who can logically explain all this? |
Send message Joined: 18 Dec 15 Posts: 1810 Credit: 118,239,996 RAC: 27,344 |
what I have noticed since yesterday: the current ATLAS tasks yield awfully low credit points. Any idea why so? |
Send message Joined: 28 Sep 04 Posts: 728 Credit: 48,813,554 RAC: 22,208 |
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. |
Send message Joined: 18 Dec 15 Posts: 1810 Credit: 118,239,996 RAC: 27,344 |
... 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. |
Send message Joined: 16 Sep 17 Posts: 100 Credit: 1,618,469 RAC: 0 |
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. |
Send message Joined: 18 Dec 15 Posts: 1810 Credit: 118,239,996 RAC: 27,344 |
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? |
Send message Joined: 16 Sep 17 Posts: 100 Credit: 1,618,469 RAC: 0 |
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. |
©2024 CERN