Hello

variation in credit allocation

17 Feb 2019, 0:45:13 UTC 17 Feb 2019, 4:08:37 UTC Terminé et validé 2,852.65 2,821.89 17.59 Pseudo Associative DLS v2.02
windows_x86_64

17 Feb 2019, 0:45:13 UTC 17 Feb 2019, 5:42:34 UTC Terminé et validé 2,719.02 2,691.28 16.73 Pseudo Associative DLS v2.02
windows_x86_64

17 Feb 2019, 0:45:13 UTC 17 Feb 2019, 10:18:30 UTC Terminé et validé 2,939.18 2,914.47 5.94 Pseudo Associative DLS v2.02
windows_x86_64

17 Feb 2019, 0:45:13 UTC 17 Feb 2019, 10:18:30 UTC Terminé et validé 2,890.60 2,878.14 5.83 Pseudo Associative DLS v2.02
windows_x86_64

why this variation?
thank you

The credit is set to default distribution. Each work-unit is assigned credit calculated like: cpu run time of the task times computer benchmark gflops times constant. If you want, I can disable credit distribution altogether.

Each task checks varying number of DLSs, which is around 200000. The number is not know until the task is started. You can see it in the log:

PADLS Experiment. 3 1 9 7 6 2 4 5
ASS_DLK10A: 99312 in 1.037 s
PSEVDOASS_DLK_NEW: 692957 in 6.113 s
KF DLK: 437103
Split 6/9 Offset 242835 size 48567 t 0.127
Found Fancy DLS: 4 in 2119.16 s

There are 437103 squares to check in this row and 1/9 is checked in this workunit, which is 48567 squares. And while each square usually takes the same time to check (depending on cpu speed - 16/s on my notebook), there are even squares that take much longer (large number of d-transvers-something). So determining exact run time is impossible.

If you want to write validator that will assign credit proportional to a number in log, go ahead and we will use it to assign credit.

https://boinc.berkeley.edu/trac/wiki/CreditNew

Oh, and mentioning tasks without the wu name or task number is useless. Try to post task numbers.

The variation may be caused by inaccurate CPU benchmarks of your computer. I do not know for sure.

I think the default BOINC server implementation uses "credit new" methodology, which is turns out to be nothing more than a fancy random number generator. Credits awarded appear to be irrational.

I think the choices are to live with it as-is, or assign some sort of fixed credits.

---

Reno, Nevada
Team: SETI.USA

I think in the future the credit will be assigned by number of squares checked. This would be done by invalidator, which reading a number form task stderr log. I also found reference to a api call that allows workunit to report it's FLOP used, and seti is supposedly using it, but I cant find documentation to that. Oh and talking about FLOPs is strange, because the only floating point calculation in the task is calculation of progress percent.
Is it good idea to delete and re-assign credit retroactively?

Is it good idea to delete and re-assign credit retroactively?

no it's not a good idea

Is it good idea to delete and re-assign credit retroactively?

no it's not a good idea

Agreed. I recommend picking a method, and implement it going forward.

Also, this is why a one-size-fits-all credit methodology just can't work. Different projects use different computing resources, to differing degrees. Creditnew was supposed to fix that, but failed.

---

Reno, Nevada
Team: SETI.USA

I have 150 task completed and validated, none in pending. Credit allocation is 0.00

I have 150 task completed and validated, none in pending. Credit allocation is 0.00

Thank you for fast processing. I see your results. I posted about new credit in the news thread:

Today I tested a new (first) assimilator for results. This assimilator has, besides from assimilating, new credit awarding algorithm. Credit for completed tasks stays the same, but from today on, credit will not be awarded during validation, but later during assimilation of the batch. Credit will be granted based on the number of Latin squares checked.

Note that the Validation state of task is mostly meaningless. The validator is not validating the results in any way, except that they are present. If we send tasks with quorum>1 then the validator does check that the results match, but computing the same task twice is not desired currently.

I have 150 task completed and validated, none in pending. Credit allocation is 0.00

Thank you for fast processing. I see your results. I posted about new credit in the news thread:

Today I tested a new (first) assimilator for results. This assimilator has, besides from assimilating, new credit awarding algorithm. Credit for completed tasks stays the same, but from today on, credit will not be awarded during validation, but later during assimilation of the batch. Credit will be granted based on the number of Latin squares checked.

Note that the Validation state of task is mostly meaningless. The validator is not validating the results in any way, except that they are present. If we send tasks with quorum>1 then the validator does check that the results match, but computing the same task twice is not desired currently.

I have finished a number of tasks:


Task name
click for details
Show IDs Work unit
click for details Computer Sent Time reported
or deadline
explain Status Run time
(sec) CPU time
(sec) Credit Application
tot5_51c_Sd5PCEWkhB8TkF1Lk1vL4r4LV_2 807073 4231 29 Aug 2019, 13:19:15 UTC 30 Aug 2019, 8:45:21 UTC Completed and validated 23,107.45 12,080.84 57.53 PADLS Total v5.07
windows_x86_64
tot5_51c_SdJN1SNciJhYP8hkVQWEyxkTT_2 807070 4231 29 Aug 2019, 13:19:13 UTC 29 Aug 2019, 20:52:14 UTC Completed and validated 19,182.98 9,898.98 57.54 PADLS Total v5.07
windows_x86_64
tot5_51c_SdRJDRjh4NDc7Lj6PJvZLUYXp_1 741543 4231 29 Aug 2019, 13:19:14 UTC 30 Aug 2019, 1:59:54 UTC Completed and validated 21,585.86 11,268.22 57.52 PADLS Total v5.07
windows_x86_64
tot5_51c_Sdv29i1FxBYSKo89F2yc2VDt2_2 747094 4231 29 Aug 2019, 13:19:13 UTC 30 Aug 2019, 7:51:38 UTC Completed and validated 17,368.62 9,082.50 57.55 PADLS Total v5.07
windows_x86_64
tot5_51c_Se3BEsrWyAmw67zeMQ9vryHJS_1 737297 4231 29 Aug 2019, 13:19:12 UTC 30 Aug 2019, 7:04:39 UTC Completed and validated 21,872.72 11,440.95 57.54 PADLS Total v5.07
windows_x86_64
tot5_51c_SeRcZ2XuTLuBo1XoC1nQfvzSy_1 737279 4231 29 Aug 2019, 13:19:14 UTC 30 Aug 2019, 14:33:28 UTC Completed and validated 19,822.47 10,354.39 57.54 PADLS Total v5.07
windows_x86_64
tot5_51c_Sh8StaufgRUMbqyk21HXxR2st_1 737424 4231 29 Aug 2019, 13:19:14 UTC 30 Aug 2019, 3:20:57 UTC Completed and validated 22,155.16 11,573.03 57.52 PADLS Total v5.07
windows_x86_64
tot5_51c_ShK5fusgHPy8MEhFMLcyDRSwq_1 737467 4231 29 Aug 2019, 13:19:14 UTC 30 Aug 2019, 16:30:33 UTC Completed and validated 24,231.93 12,655.73 57.53 PADLS Total v5.07
windows_x86_64
tot5_51c_SkcNTGYEeLtnzsmqXSXMobng9_1 736808 4231 29 Aug 2019, 13:19:14 UTC 30 Aug 2019, 2:55:28 UTC Completed and validated 22,330.68 11,645.52 57.52 PADLS Total v5.07
windows_x86_64
tot5_51c_SshSvH76nSszHf5v73Czhc9t7_1 737267 4231 29 Aug 2019, 13:19:14 UTC 30 Aug 2019, 0:40:54 UTC Completed and validated 21,050.54 10,857.94 57.51 PADLS Total v5.07
windows_x86_64
tot5_51c_SueqAa9g83CnC89bBALUj32ZS_1 737554 4231 29 Aug 2019, 13:19:15 UTC 30 Aug 2019, 9:45:58 UTC Completed and validated 21,948.81 11,477.77 57.50 PADLS Total v5.07
windows_x86_64
tot5_51c_Suk5nu4TMQknP1gYx9WPrj6T7_1 736975 4231 29 Aug 2019, 13:19:14 UTC 30 Aug 2019, 9:24:59 UTC Completed and validated 23,069.60 12,061.72 57.51 PADLS Total v5.07
windows_x86_64
tot5_51c_SviKs3GjRRe5YaXU4BTrWtf6Z_1 833303 4231 29 Aug 2019, 13:19:13 UTC 29 Aug 2019, 19:10:29 UTC Completed and validated 18,509.50 9,467.03 57.52 PADLS Total v5.07
windows_x86_64
tot5_51c_Sw5BEpGWF79pHifmMAR3YTR6B_1 736764 4231 29 Aug 2019, 13:19:14 UTC 29 Aug 2019, 20:35:35 UTC Completed and validated 23,296.49 11,964.33 57.52 PADLS Total v5.07
windows_x86_64
tot5_51c_SwSeEcecr31bd5BzrSDPqry7f_1 846336 4231 29 Aug 2019, 13:19:15 UTC 30 Aug 2019, 2:40:13 UTC Completed and validated 20,787.45 10,855.23 57.50 PADLS Total v5.07
windows_x86_64
tot5_51c_SzHF2aGQ95ZToTkk5GkJpSAhw_2 807071 4231 29 Aug 2019, 13:19:15 UTC 30 Aug 2019, 13:59:01 UTC Completed and validated 20,939.36 10,916.73 57.50 PADLS Total v5.07
windows_x86_64
tot5_51c_T2MqzTtRpRSiRCXKHJogWGsxD_1 737269 4231 29 Aug 2019, 13:19:14 UTC 30 Aug 2019, 15:39:32 UTC Completed and validated 20,126.20 10,511.47 57.50 PADLS Total v5.07
windows_x86_64
tot5_51c_T4GY5DtnVNEZcA4u2BRcSoGz5_1 737495 4231 29 Aug 2019, 13:19:14 UTC 29 Aug 2019, 19:41:13 UTC Completed and validated 20,216.42 10,363.33 57.54 PADLS Total v5.07
windows_x86_64
tot5_51c_T69BEAgXqLawxBfA4AKfMFofi_1 736960 4231 29 Aug 2019, 13:19:14 UTC 30 Aug 2019, 13:41:21 UTC Completed and validated 22,611.46 11,788.61 57.50 PADLS Total v5.07
windows_x86_64

Most have a run time in the 6 to 7 hours range, some longer and every single one got 57.50 credits!! I can spend less money and get more credits letting them sit idle and not crunching than doing that!! I have no clue what credit system you are using but at the current rate I have moved my cpu's elsewhere!! What you can't see in the above are the tasks I aborted that were at 9 hours and still going!!

Most have a run time in the 6 to 7 hours range, some longer and every single one got 57.50 credits!! I can spend less money and get more credits letting them sit idle and not crunching than doing that!! I have no clue what credit system you are using but at the current rate I have moved my cpu's elsewhere!! What you can't see in the above are the tasks I aborted that were at 9 hours and still going!!

The credit is assigned based on work done. I picked a task from your list: tot5_51c_T69BEAgXqLawxBfA4AKfMFofi_1, the task was idle half the time and for 3h on that processor, 57 credits sounds about right.
The credit is calculated in this file (search for credit). If you spot a mistake, or enough people request higher credit, we can increase the multiplier. But please note, it was established according to Berkeley guidelines.

Most have a run time in the 6 to 7 hours range, some longer and every single one got 57.50 credits!! I can spend less money and get more credits letting them sit idle and not crunching than doing that!! I have no clue what credit system you are using but at the current rate I have moved my cpu's elsewhere!! What you can't see in the above are the tasks I aborted that were at 9 hours and still going!!

The credit is assigned based on work done. I picked a task from your list: tot5_51c_T69BEAgXqLawxBfA4AKfMFofi_1, the task was idle half the time and for 3h on that processor, 57 credits sounds about right.
The credit is calculated in this file (search for credit). If you spot a mistake, or enough people request higher credit, we can increase the multiplier. But please note, it was established according to Berkeley guidelines.

So you ARE using 'credit new' here, that explains it thanks.
As I said in my post I can get more credits elsewhere in ALOT less time so you have a nice day.
mikey

---

we can increase the multiplier. But please note, it was established according to Berkeley guidelines.

I believe this project is the lowest paying of any BOINC project. ODLK and ODLK1 pay very poorly in comparison to other projects but they pay far better than this project.

Once I reach my personal credit goal I will never again run this project. The only reward we volunteers get are the credits/badges awarded by the projects. The credits cost the project nothing.

This is my personal opinion and others may feel differently. However, I'm the one who controls which projects I support. BTW, I also don't support ODLK or Latin Squares for the same reason.

Credit Screw is a random credit generator.

I would like to emphasize that we are NOT using credit_new or any other built-in boinc algorithm. The app keeps counts of key elements in the computation (cf,sn,...) and then the validator assigns credit as a weighted sum of these counts. The weight constants were set based on benchmark on two computers.
There are some projects which give too much credits, much more than the cobblestone recommendation of Berkley. So it is true, that there are projects where you can get more credit.
Instead of being all negative and threatening, you two could already have written a polite request to increase the credit given for work on this project. It costs me nothing to increase that multiplier.

Tomas, I do not see my post as "threatening" and it was not intended that way. It is your project and you may run it anyway you wish and I have no problem with that. You are free to chose the credit level you award to your volunteers. But the fact is that I am a volunteer and I have the option to run whatever projects I like or prefer. That is a fact and not a threat.

This is a hobby for me and I have personal goals. I do not intend to make a lifetime commitment to this project, or any other, to get to a 5, 10, or 25 million credit milestone.

And, I do agree that there are projects that give far more credits than they should. Last week I was running a CPU project for a upcoming team challenge. I was making 8M credits/day. Here I make 170k/day so I think there is a place in between those 2 levels that would be a good compromise for both projects.

If you want to attract volunteers that will run you science for extended periods then I suggest you raise the credit level. That is a personal opinion of course. That also goes to ODLK and ODLK1 as well. ;)

I would like to emphasize that we are NOT using credit_new or any other built-in boinc algorithm. The app keeps counts of key elements in the computation (cf,sn,...) and then the validator assigns credit as a weighted sum of these counts. The weight constants were set based on benchmark on two computers.
There are some projects which give too much credits, much more than the cobblestone recommendation of Berkley. So it is true, that there are projects where you can get more credit.
Instead of being all negative and threatening, you two could already have written a polite request to increase the credit given for work on this project. It costs me nothing to increase that multiplier.

I TOTALLY agree with BL and everything he said!! ALL I said was that I can earn more credits for the cost of my electricity elsewhere and even YOU said "But please note, it was established according to Berkeley guidelines." That my friend is called 'credit new' by us crunchers who YOU want to help you crunch for you. BL is ABSOLUTELY correct in saying that this is YOUR Project and not mine and what YOU says goes here and my opinion does not matter. I posted that I thought the credits were too low when I said I crunched for 6 to 7 hours, in some cases over 9 hours, and only got 57 credits and you said "But please note, it was established according to Berkeley guidelines."

It is MY money paying for the electricity and I can make FAR more credits for it elsewhere so I am!! When YOU pay me to crunch for you then you can tell me where to crunch but until then, or you raise your credits to a more reasonable near midpoint level instead of some pie-in-the-sky idea of 'credit new' then I am not wasting my time here.

BTW 'credit new' was and still is a pie-in-the-sky idea of making every Project pay exactly the same credits so that somehow the different projects are 'more comparable' to each other in regards to credits. The point is we crunchers DON'T CARE about that, we care about being paid fairly for the often hundreds of dollars per month we pay in electricity to make Projects like this one viable. I was going to PM you the other day but decided against it, the idea was to show you that although MOST people sign up for Seti as their original Project under Boinc they only have a 4 percent retention rate. If you pick a Project like Einstein they have a retention rate of 60 some percent....I wonder why that might be? (Stats from BoincStats) I will refrain from posting my thoughts as to why here because they don't really matter. The point is where will THIS Project be in 2 years, 5 years or 10 years? And will any or even most of your goals be achieved? My impression is unless and until you raise your credits to reflect what we crunchers want, it could be a long slow slog for you and your goals.

I am NOT asking you to rival DHEP for credits, they were at the very top end of cpu credits and almost everyone had at least some pc's there until they recently had to close up for lack of funding. Too many credits and crunchers causes it's own set of problems such as Server time for all of us crunchers to get and return our workunits in a timely manner, often meaning bigger hard drives and more and faster Servers and internet speed to handle it. Just shoot for the middle of the pack and you will get plenty of people crunching here, but 6 to 7 hours, or over 9 hours in some cases, of crunching time and only paying 57 credits for it is no where NEAR the middle!!!

It is your Project and you can do whatever your heart desires with it, but my computers are mine and I too will do with them what my own heart desires, and right now that means attaching them to other Projects than this one.

It looks like there are three problems in this thread:
1. you are requesting to increase granted credit
2. a unsolved bug that causes task to get stuck and "run" much longer than they should
3. confusion on what is credit_new

Let me start with the credit_new. CreditNew is defined by Berkley. It covers the previous first and second credit system and well as the (not so) better new system.
We are not using the First system. Neither job cpu time nor the clients whetstone benchmark is used.
We are technically not using the Second system, because the api call to report application FLOP count was removed, so we cant use it.
As for the New system, we indeed supply apriori fpops_est and fpops_bound because it is enforced by BOINC. But we do not compute PFC(j) we do not maintain app_version statistics nor we perform any normalization.
Instead the app is counting number of three key steps in the computation. Each of those was benchmarked on my computer, from this benchmark times, a set of relative weights were assigned to the counters. Lastly the result was rescaled to cobblestone units according to Berkeley recommendation of 200 credits per GFlop.

It looks like there are three problems in this thread:
1. you are requesting to increase granted credit
2. a unsolved bug that causes task to get stuck and "run" much longer than they should
3. confusion on what is credit_new

Let me start with the credit_new. CreditNew is defined by Berkley. It covers the previous first and second credit system and well as the (not so) better new system.
We are not using the First system. Neither job cpu time nor the clients whetstone benchmark is used.
We are technically not using the Second system, because the api call to report application FLOP count was removed, so we cant use it.
As for the New system, we indeed supply apriori fpops_est and fpops_bound because it is enforced by BOINC. But we do not compute PFC(j) we do not maintain app_version statistics nor we perform any normalization.
Instead the app is counting number of three key steps in the computation. Each of those was benchmarked on my computer, from this benchmark times, a set of relative weights were assigned to the counters. Lastly the result was rescaled to cobblestone units according to Berkeley recommendation of 200 credits per GFlop.

You can frame it any way you like, but you are paying 57 credits for 6 to 9 or more HOURS of work and that means I'm crunching elsewhere! A simple programming code could alert you to review the credits awarded for workunits that run longer than expected. The Berkeley credit system is nothing more than a recommendation and you darn well know it as in one of your posts you talked about some projects paying too many credits! YES Berkeley releases the Server side software with that credit system built in, but those projects that choose too have changed it to fit their own needs. You seem to be happy with the way things are going here so I'm done asking for changes or explaining my thoughts, as I said before it's your Project and you can do anything you want with it.
You have a nice day!!

I believe this project is the lowest paying of any BOINC project. ODLK and ODLK1 pay very poorly in comparison to other projects but they pay far better than this project.

No one wrote on the ODLK and ODLK1 project forums that these projects paid poorly.

I don’t want people to run after me for money, I want people to LOVE ME!

I will write about credits in Russian on the ODLK project forum.