Tomáš Brada

Yesterday I was upset and wrote a lot.
I highlight the most important.

The SPT project must go on!

I offer two options
1. You transfer control of your server to my colleague.
2. You give my colleague the software and he runs the project on his server.

Please give me an answer.
If you reject both options, I will start the BOINC SPT project with a colleague.

Today I was surprised with a credit score of -76,988.
The loss was all with Prime Tuples, which went to 214,223 from yesterday's 291,211.
All credit scored between 2021-02-26 and 2021-03-15 is gone.

If possible, please submit this issue to https://github.com/BOINC/boinc/ and link it here. If it already exists, also link it here.
Thank you, and I am sorry for the incident.

Several of my machines running SPT WUs at priority 0 on one core have been given 1000 WUs today! I now have nearly half the 11,000 active SPT WUs when I'd expect to have about 20.

The other three cores are running WUs from another project.

Jon

I can not draw :)
I offer a sketch



Tomáš Brada
you can change it as you like.

Assignment of Badges:

the first - 100 K
the second - 300 K
the third - 1 M
the fourth - 3 M
etc.

Also I do not want to attract much more crunchers to this project. It is running off a Banana Pi and single 5400 disk and it's purspose is to develop this application (tot5/padls total) and my other endeavours. One day maybe Ice00 or Progger imports the developed app into their server.

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.

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.

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.

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.