Message boards :
ATLAS application :
credits for runtime, not for cputime ?
Message board moderation
Previous · 1 · 2
Author | Message |
---|---|
Send message Joined: 15 Nov 14 Posts: 602 Credit: 24,371,321 RAC: 0 ![]() ![]() |
I would make credit (if given at all) as simple as possible, to stop wasting developer time on it. So I would give fixed credit per work unit. If you sell something in the market, you get what the market price for that item is, not how long it took you to make it. It would encourage efficiency, if that matters to you. And maybe the crunchers would stop discussing it too, further reducing wasted time. |
Send message Joined: 9 Jan 15 Posts: 151 Credit: 431,596,822 RAC: 0 ![]() ![]() |
That is good point and mostly like that it would make it simple to developers and make it less complex. It would make it easier to measure hardware and focus on doing them efficiently rather then keep them to run in longer time and slow cpu:s. Only bad side on it some project like this would be target on cherry picking if task have to wide runtime spectrum and users could find a way to filter task/jobs. In already complex applications it might be possible to avoid it but don't know. In the end it might be a way to solve it with to not accept aborting task and give penalty to host if so or work around system to it. Maybe a solutions is to use both. Sixtrack could work work as it is but others application could work fixed credit. |
Send message Joined: 18 Dec 15 Posts: 1735 Credit: 112,365,123 RAC: 51,335 ![]() ![]() |
there is a strange observation I made today on ONLY one of my several systems running ATLAS WUs (none of the settings or anything else was changed): report time: 3 Jan 2022, 20:04:33 UTC - runtime: 44,734.04 - CPU time: 87,020.45 - credit: 1,504.13 report time: 4 Jan 2022, 8:46:23 UTC - runtime: 45,687.04 - CPU time: 88,582.66 - credit: 790.11 whereas I am aware that credit slowly decreases during the duration of a given batch, and may jump up again once a new batch is on air, I am sure that a drop in credit of almost 50% within 12 hours must have other reasons. Even more since on all my other systems which are crunching ATLAS I did NOT notice such a drop. What I also noticed and posted about in the CMS thread was that when the distribution of CMS tasks was resumed few days ago after a previous short downtime, there was also a considerable drop in credit points. More and more it seems to me that at LHC the calculation and granting of credit points is a huge conondrum. Whenever I had brought such issues up in the past years, no one could deliver any reasonable explanation. Also, I have never seen such strange credit issues with any other projects I have been crunching over all the years. |
![]() Send message Joined: 15 Jun 08 Posts: 2473 Credit: 244,960,789 RAC: 170,515 ![]() ![]() ![]() |
Any discussion about BOINC credits within this forum is more or less useless since LHC@home uses the built-in BOINC credit calculation. The only parameter set by the project team is whether to calculate the credit based on CPU usage or based on walltime. More information can be found here: https://boinc.berkeley.edu/trac/wiki/CreditNew or in the BOINC source code: https://github.com/BOINC/boinc Any complaints should also be made there. |
Send message Joined: 2 May 07 Posts: 2174 Credit: 171,558,615 RAC: 167,012 ![]() ![]() ![]() |
Erich56, we are all in the same boat. Cern have hundredthousands of CPU's. We normaly less than hundred. (Really CPU's. no HT) |
Send message Joined: 18 Dec 15 Posts: 1735 Credit: 112,365,123 RAC: 51,335 ![]() ![]() |
computezrmle wrote: Any discussion about BOINC credits within this forum is more or less useless since LHC@home uses the built-in BOINC credit calculation.I was trying to read and to understand this article. Well, this whole credit thing seems to be a science by itself. In any case, I did not manage to find any hints which would explain this strange essential drop in credit from one day to the other. BTW, meanwhile the points have dropped even more; maybe some day next week it will be (close to) zero. |
Send message Joined: 27 Sep 04 Posts: 104 Credit: 7,917,452 RAC: 6,719 ![]() ![]() ![]() |
So if I run one core on a 3.5 Ghz machine, I get the same credit as someone who runs 8 cores or 10 cores on a 3.5 GHz machine? That is totally non-comprehensible, as I'm doing MUCH less work and returning MANY fewer results If this is indeed correct, I can allocate more cores to other projects and get the same credit in Atlas |
![]() Send message Joined: 15 Jun 08 Posts: 2473 Credit: 244,960,789 RAC: 170,515 ![]() ![]() ![]() |
The project server will adjust the peak flops for each computer. Long term - meaning the computer has returned lots of valid results - both setups deliver nearly the same credits. Nonetheless, there will be phases with very low/high credits per task, especially whenever the setup changes or a new app version is out. |
Send message Joined: 2 May 07 Posts: 2174 Credit: 171,558,615 RAC: 167,012 ![]() ![]() ![]() |
This is a mysql analysing from David for the creditpoints: https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=4271&postid=32040#32040 |
©2024 CERN