Credit granted seems unrelated to work done.
Examples...
751.51 694.75 30.00
499.31 450.13 60.00
734.21 690.28 30.00
715.04 685.98 30.00
724.05 680.55 30.00
/ 
Reply
Quote
rebirtherVolunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 2 Jan 13
Posts: 7497
Credit: 44,029,375
RAC: 32,894
Credit granted seems unrelated to work done.
Examples...
751.51 694.75 30.00
499.31 450.13 60.00
734.21 690.28 30.00
715.04 685.98 30.00
724.05 680.55 30.00
You can find the amount of credits in the bases load thread, there are some bigger jumps in range changes. All the credits are precalculated for every bases based on iterations / runtime.
/ Reply
Quote
What the job is doing is not the issue, you have used my system. Credit should reflect the amount of work actually done. It does not appear to be the case.
/ Reply
Quote
rebirtherVolunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 2 Jan 13
Posts: 7497
Credit: 44,029,375
RAC: 32,894
What the job is doing is not the issue, you have used my system. Credit should reflect the amount of work actually done. It does not appear to be the case.
There could be an exception with a lower k value in a higher n range.
/ Reply
Quote
What I am talking about is the actual amount of CPU time the jobs have used. Sticking to the examples I quoted above, four of the jobs used 700+ CPU seconds and got credited 30, and the other used nearly 500 seconds and got credited 60. What the job actually did is not really a factor.
/ Reply
Quote
rebirtherVolunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 2 Jan 13
Posts: 7497
Credit: 44,029,375
RAC: 32,894
What I am talking about is the actual amount of CPU time the jobs have used. Sticking to the examples I quoted above, four of the jobs used 700+ CPU seconds and got credited 30, and the other used nearly 500 seconds and got credited 60.
Yes, that was I mentioned before.
/ Reply
Quote
It is interesting isn't it. You look at it from your point of view and see nothing wrong, I look at the same figures from my point of view and see nothing right.
It seems clear we will not be able to resolve it, so I will detatch, end of issue. I had only atatched this machine, so it is easy for me to do this.
Good luck with your project.
/ Reply
Quote
rebirtherVolunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 2 Jan 13
Posts: 7497
Credit: 44,029,375
RAC: 32,894
It is interesting isn't it. You look at it from your point of view and see nothing wrong, I look at the same figures from my point of view and see nothing right.
It seems clear we will not be able to resolve it, so I will detatch, end of issue. I had only atatched this machine, so it is easy for me to do this.
Good luck with your project.
Sorry to hear that, if you can provide me with the numbers not the runtime we can do an analyse. Otherwise these values are useless.
/ Reply
Quote
I've no idea which they were, but a very quick look at my results page reveals further examples...
217520576 213480690 19176 24 Apr 2017, 1:33:58 UTC 24 Apr 2017, 1:53:58 UTC Completed and validated 747.97 725.47 30.00 Riesel Base v0.20
218078215 214021622 19176 24 Apr 2017, 1:28:40 UTC 24 Apr 2017, 1:41:30 UTC Completed and validated 746.13 724.38 60.00 Sierpinski / Riesel Base - average v0.20
... here, for example, are two units that were adjacent on my results page. Their CPU times are less than two seconds different, yet one gets twice the credit as the other. You see one is Riesel, the other Sierpinski and your view point may be this is totally reasonable. To me, I see one job has used the same time as the other, but gets twice the credit.
/ Reply
Quote
Work done are not necessarily measured in CPU time. Each task presumably completes an equal k range hence assigned the same credit locally. There are spikes along the curve hence the admin chooses to normalize the credit per task in each section.
When I calculate the credits given in a long term the credits seemed to correlate with CPU time in contrast to your 'example' just from a few tasks, and you don't even bother to crunch for some more.
____________
/ Reply
Quote
rebirtherVolunteer moderator
Project administrator
Project developer
Project tester
Project scientist
Send message
Joined: 2 Jan 13
Posts: 7497
Credit: 44,029,375
RAC: 32,894
I've no idea which they were, but a very quick look at my results page reveals further examples...
217520576 213480690 19176 24 Apr 2017, 1:33:58 UTC 24 Apr 2017, 1:53:58 UTC Completed and validated 747.97 725.47 30.00 Riesel Base v0.20
218078215 214021622 19176 24 Apr 2017, 1:28:40 UTC 24 Apr 2017, 1:41:30 UTC Completed and validated 746.13 724.38 60.00 Sierpinski / Riesel Base - average v0.20
... here, for example, are two units that were adjacent on my results page. Their CPU times are less than two seconds different, yet one gets twice the credit as the other. You see one is Riesel, the other Sierpinski and your view point may be this is totally reasonable. To me, I see one job has used the same time as the other, but gets twice the credit.
ok, between these 2 apps there is a difference in the range we are searching:
60-100k vs. 100-150k, thats why the credits are higher.
/ Reply
Quote
Some odd stuff here too;
http://srbase.my-firewall.org/sr5/workunit.php?wuid=215291496
:)
/ Reply
Quote