Aren't credits set a bit to high? ~ 70k daily from 7threads sounds little overpaid. Same host in well paid Enigma@home (with optymalization on) can reach ~ 20k daily. Please do not make credit system worthless.

I use standard BOINC credit system. Where to set it? There's always an option to switch to fixed credit per work unit, since work units are pretty consistent and uniform now.

P.S. According to this table: https://boincstats.com/en/stats/-1/cpcs project credit level can vary dramatically between projects, sometimes one project gives almost 100 times more credits than another. I don't understand how exactly a credit for work unit is computed. Even looking at the source code doesn't help much.

Hello i agree with tito

The credits are really too high

thank you

I will pass that thread to admin of Universe@home. He should be aware of matter.
Re vary of credits between projects - my opinion is to TRY keep everything equal, but in smart way. SETI "creditnew" system is terrible. Overpaying is also not good.

I've directly modified sample_bitwise_validator and added a scaling factor there to reduce credits. It'll give 2.5 times less credits per WU from now on. Please give feedback here.

P.S. According to logs, it's giving less credits now: https://sech.me/boinc/Amicable/workunit.php?wuid=11429

I don't know what level is considered to be 'normal', so you can greatly help me by replying here.

Hello,
My name is Krzysztof 'krzyszp' Piszczek, I'm Universe@Home admin and tito ask me to join this disscusion :)

I had load of problems with setting correct points for WU's in past, so I decide to check execution "referal" machine well know for me and set is as "0 level" for points.
Currently my E3-1230v2 on Windows 7 makes about 2.2k points daily on single thread (with multithreading) and I think it is average amount of points in most projects.
Obviously I ser points-per-wu in generator.

2.5 times less may still be over crediting from what I've been seeing. I've made over 800k in the last 3 days and my systems have not been fully dedicated to the project. I cannot come anywhere near that amount of credit on CPU's at any of the other projects. At most I probably would typically earn between 75k and 100k depending on project and how focused I am on that project. And again that would be over the course of 3 days time. I personally don't care what the points are. I just know that there are quite a few that took notice and are monopolizing on this opportunity.

---

I'm getting lost in numbers. At the current scale, my Xeon CPU E5-1650 v3 (6 cores) generates ~35k credits a day running 12 threads. Is it normal or too much?

There is also a question about optymalization of Your application. Remember that sometimes somebody can squize much more more from the code - eg TN-Grid where one of our collegues optymized application so it became 4 times faster.
~35k from Your CPU sounds still little too much. Personally I would target it to ~ 28k. Still above protein projects but fair for math.

You could say the same about Collatz as well http://boinc.thesonntags.com/collatz/result.php?resultid=125538173


Amicable Numbers
Run Time 3,390.83 CPU Time 50,972.52 Credit 985.71
Run Time 2,486.41 CPU Time 77,604.84 Credit 3,777.12
Run Time 20,754.45 CPU Time 35,612.59 Credit 11,402.79
Run Time 1,466.71 CPU Time 0.33 Credit 38,986.66 Collatz

And then look at Look at Rosetta @ home 5-6 hours work for less than 100 Credits

---

Crunching@EVGA The Number One Team in the BOINC Community.
Folding@EVGA The Number One Team in the Folding@Home Community.

There is also a question about optymalization of Your application. Remember that sometimes somebody can squize much more more from the code - eg TN-Grid where one of our collegues optymized application so it became 4 times faster.
~35k from Your CPU sounds still little too much. Personally I would target it to ~ 28k. Still above protein projects but fair for math.

Everyone is welcome to try optimizing it: https://github.com/SChernykh/Amicable/tree/boinc-version
But I doubt that it's possible at all. 1-2%, maybe 5% improvement, but not 4 times faster.

I did a test run of Primegrid in January, it gave me a set of 12 "The Riesel Problem (Sieve)" tasks, and when they got validated, I received 7208 credits for just 2.5 hours of work, so it's ~69.2k per day on the same CPU on another math project.

In sieve Yes. If You Try LLR it would be half of it. BTW does Your aplication use AVX/FMA/AVX2 ?

Half of it would be exactly what it is here now. My application uses only integer arithmetic. Floating point just can't represent 64-bit integers without losing precision.

I believe that the best option is to take one reference machine. Crunch for 24 hours for one project similar to Yours. Then approximate the results. It would be fair.

How does the credit system work out the multithread?

If I use 12 cores on a task and my buddy user uses one for the same task do we get the same credit? If we do which seems to be the case, the user running on one task gets a windfall. I think because one uses 12 cores it should get 12 times the credit of the one using one core. If I was a normal BOINC project I would be returning 12 tasks to the other users one and therefor get 12 times the points.

I might be wrong but I am sure someone will let me know.... Old timers sets in sometimes this early in the morning.

---

Proud Founder and member of



Have a look at my WebCam

How does the credit system work out the multithread?

If I use 12 cores on a task and my buddy user uses one for the same task do we get the same credit? If we do which seems to be the case, the user running on one task gets a windfall. I think because one uses 12 cores it should get 12 times the credit of the one using one core. If I was a normal BOINC project I would be returning 12 tasks to the other users one and therefor get 12 times the points.

I might be wrong but I am sure someone will let me know.... Old timers sets in sometimes this early in the morning.

The credit is based on CPU time spent, so your client counts total time spent on all 12 cores for you, your buddy's client counts time spent on one core. Then both clients report to the server: "I spent X CPU seconds and claim Y credit", then server does math and other checks and awards both clients with equal credit which is a minimum of two claimed credits to limit cheating.

Edit: actually, clients report number of floating point OPs performed, not just CPU seconds.

Then both clients report to the server: "I spent X CPU seconds and claim Y credit", then server does math and other checks and awards both clients with equal credit which is a minimum of two claimed credits to limit cheating.

Edit: actually, clients report number of floating point OPs performed, not just CPU seconds.

So if it "awards both clients with equal credit which is a minimum of two claimed credits " why would I ever use all my cores, I am better off using one core and get the same points?

https://sech.me/boinc/Amicable/workunit.php?wuid=22718

This is a Work Unit that I picked at random and is the 12 core machine but not sure if I was running all 12 then, my Run time 51 min 53 sec CPU time is 10 hours 21 minutes 10 seconds and my buddy Run time 1 hours 39 min 28 sec CPU time is 4 hours 58 min 11 sec yet we get the same credit of 566.02.
I do not know how much I or he claimed but it does not seem correct that we get the same credit.

Here are two Work Units from the same machine (374) and processed about the same time and get vastly different credit of 566.02 and 2591.14 credits,

https://sech.me/boinc/Amicable/workunit.php?wuid=22648
https://sech.me/boinc/Amicable/workunit.php?wuid=22715

So it all depends on who you get paired with which does not seem to be fair or logical.

When everyone is running the same work unit on one thread the credit system works OK but not when one is running 12 cores and someone else 4 cores.

---

Proud Founder and member of



Have a look at my WebCam

This credit system logic is definitely weird. I guess the better option would be to switch to fixed credit per work unit.

So it all depends on who you get paired with which does not seem to be fair or logical.

When everyone is running the same work unit on one thread the credit system works OK but not when one is running 12 cores and someone else 4 cores.

One issue may be that this project is memory intensive and thus will run out of memory bandwidth before you run out of cores on a 12 core machine.

I see it all the time with my collection of machines. I have an i5 with four cores at the same clock speed as my xeon with 12 cores. The i5 core finishes a work unit in half the time as the xeon, but the xeon does more of them at the same time. You can get good scaling if the main loop of your application fits in processor cache, but if it does not then all cores are competing for access to main memory.

So, yes, it DOES depend on who you get paired with. A couple of machines with lots of cores and slow memory will get more credit for doing the same work as a leaner, meaner machine. That is because credit is based on cpu seconds * cpu benchmark. And the cpu benchmark is computed with an algorithm that, you got it, fits in cache ;)

Many projects facing this issue pick a reference system and run work on it to get representative credit. They then assign fixed credit to the work units based on how their reference system performs. Some people hit the jackpot if their systems are more efficient than the reference system. Others are not as happy.

Oh, and it should make sense that it doesn't matter whether you are running a multi-threaded app which runs 4 or 12 cores or a single threaded app and you run 4 or 12 parallel work units. The end result is the same. The advantage of the multi-threaded app is the programmer is doing the work of identifying what can be shared between the threads instead of making the operating system. This can have a marked affect in projects like this one that want a lot of memory that can be shared between threads.

Yes, it's better to run just one work unit on all cores because threads share common data and cache miss rate is low. Those who run multiple instances are generally a bit slower because CPU cache gets exhausted.