| Author |
Message |
|---|
 Michael Goetz Volunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13951
ID: 53948
Credit: 390,843,979
RAC: 117,525
                               
|
|
I just completed a long PSP LLR WU -- some 200+ hours on a slow computer -- and seem to have received somewhat less credit than would be expected based on the credit given for the shorter PSP LLR WUs.
Judging by what I've seen so far, the credit seems to be along the lines of the average claimed credit * 1.5. There appears to be a limiting cap, however.
For this long WU, one computer claimed 2060 credits and the other claimed 2142. Based upon the amount of credits granted for the shorter PSP WUs, I would have expected somewhere between 2500 and 4000 credits, as this WU ran 3 to 4 times longer than the others. However, the credit that was granted was exactly 1800.
Is there a cap on the amount of credit that's granted, and, if so, is that cap adequate for the WUs currently being generated?
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I haven't seen credits amount for CLLR, WLLR and PSPLLR bigger than 1800 anytime, so I think there is some gap...
SoB is an exception, of course.
____________
 |
|
|
JohnHonorary cruncher
Send message
Joined: 21 Feb 06
Posts: 2875
ID: 2449
Credit: 2,681,934
RAC: 0
                 
|
Is there a cap on the amount of credit that's granted, and, if so, is that cap adequate for the WUs currently being generated?
Yes, there are caps for all projects. We'll review them to see if they remain adequate.
____________
|
|
|
|
|
|
What about these credits? 4+ times the CPU time of another project but the same credit! Why bother doing these if the credits are the same.Have another one coming up and then will uncheck project unless it changes. Thanks
Name
psp_llr_93056457_0
Workunit
195288399
Created
10 Jul 2011 | 11:52:04 UTC
Sent
10 Jul 2011 | 21:57:03 UTC
Received
19 Jul 2011 | 3:34:27 UTC
Server state
Over
Outcome
Success
Client state
Done
Exit status
0 (0x0)
Computer ID
195899
Report deadline
31 Jul 2011 | 21:57:03 UTC
Run time
301,058.76
CPU time
285,896.01
Validate state
Valid
Credit
3,947.42
Application version
Prime Sierpinski Problem (LLR) v6.09
|
|
|
|
|
|
I asked this same question recently and was "attacked" or "politically corrected" with the "It's for the greater good" argument.
Guess admin/cronies here think us CPU crunchers are sheeple. :)
You can draw your own conclusions about empathy for our efforts by visiting this thread: http://www.primegrid.com/forum_thread.php?id=2891&nowrap=true#38462
____________
|
|
|
|
|
|
I think it's time to review the cap on this project. The WUs now take around 4 days to run on an i7 but are limited to 4500 credits. Based on the other projects this should actually be around 6000-7000.
|
|
|
|
|
|
I got 5238.15 credit for a PSP LLR WU recently. The cap on PSP project seems to be changed. |
|
|
|
|
|
Have we hit a credit cap here? I got 6,000 for all my last WUs. |
|
|
|
|
Have we hit a credit cap here? I got 6,000 for all my last WUs.
I think more of an issue than the cap is the huge variability in credits (and not just for PSP) - anywhere from 4700 - 6000 for the same amount of work. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13951
ID: 53948
Credit: 390,843,979
RAC: 117,525
|
|
With regards to the cap, I'm not directly involved, but I know there is a cap, and it needs to be raised periodically. I've let Rytis know about it, but he's been busy with other things right now so I can't guess when this might be addressed. You'll need to be patient.
As for the variability of the credits, yeah, tell me about it. To paraphrase an old saying, "It's the worst imaginable credit system -- except for all the rest."
Essentially there's two ways to grant credit. Either the project determines how much credit each WU is worth, or the client computers measure how much crunching they do and the credit is based on their CPU time multiplied by how fast the CPU is.
By far, the first method is the best method. We use it for the sieves, which are a consistent amount of work so each WU takes the same amount of time and yields the same credit. It's also used for GFN because there's a very reliable formula for estimating the amount of work that needs to be done for each number. We know exactly how much crunching is needed for each WU, so the project assigns the credit, but it's different for each WU.
But that method only works if you can accurately predict how much processing each WU will consume. With LLR, there isn't an accurate way to do that because it optimizes the calculations which results in unpredictable jumps in computation time. Furthermore, the program behaves differently on different CPUs because it's optimized at the assembler level for various CPU architectures. It's therefore impossible for the server to predict how long it will take to compute. We need to use plan B, which relies on A) an accurate measurement of the CPU time used by each computer, and B) accurate benchmark timings on those computers, which is used to determine how fast the computer is.
There's tons of problems with that method, not the least of which is that the benchmarks are awful. They do not represent LLR very well, and they are not consistent between operating systems. The end result is that there's a lot of variability in the credit.
____________
My lucky number is 75898524288+1 |
|
|
|
|
There's tons of problems with that method, not the least of which is that the benchmarks are awful. They do not represent LLR very well, and they are not consistent between operating systems. The end result is that there's a lot of variability in the credit.
hyperthreading is a good example of the problem. CPU benchmarks with hyperthreading on or off are identical.
However with it on the WUs take longer and end up getting more credit.
eg: with HT off I can run 4 PSPs in around 100k seconds and maybe get 3-4000 credits/WU.
with HT on I can run 8PSPs in 200k seconds (so same units / time) but because it appears from the benchmarks to have done twice as much work I will then get on average around 5500 credits/WU.
|
|
|
|
|
....
We use it for the sieves, which are a consistent amount of work so each WU takes the same amount of time and yields the same credit. ...
I beg to differ, see this topic I opened with regards to funky task times in TRP Sieve.
____________
PrimeGrid Challenge Overall standings --- Last update: From Pi to Paddy (2016)
 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13951
ID: 53948
Credit: 390,843,979
RAC: 117,525
|
|
The cap is now 8000. So much for patience.
____________
My lucky number is 75898524288+1 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13951
ID: 53948
Credit: 390,843,979
RAC: 117,525
|
....
We use it for the sieves, which are a consistent amount of work so each WU takes the same amount of time and yields the same credit. ...
I beg to differ, see this topic I opened with regards to funky task times in TRP Sieve.
There's clearly something odd there, but what I said still is true. I suspect there were just some strange WUs in there.
I have no idea what's up with that sieve, but I'll see if I can't get someone interested in answering your question.
____________
My lucky number is 75898524288+1 |
|
|
|
|
But that method only works if you can accurately predict how much processing each WU will consume. With LLR, there isn't an accurate way to do that because it optimizes the calculations which results in unpredictable jumps in computation time. Furthermore, the program behaves differently on different CPUs because it's optimized at the assembler level for various CPU architectures. It's therefore impossible for the server to predict how long it will take to compute.
Well another way could be to somehow count the real computation step done be the client (e.g. number of FFT calculations or depth of those...) and assign those steps a certain credit value. The number of steps could be reported when the WU finishes, ideally somehow encrypted to prevent foul play, and then the server could assign the credit. I neither a very good programmer nor a really good mathematician to guess on the implementation effort or even the feasibility for something like this for PG, but as far as i know it's way it's done at some other projects.
@admins: Thanks for the quick adjustment of the credit cap. Really appreciated. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 13951
ID: 53948
Credit: 390,843,979
RAC: 117,525
|
|
That might be possible, but it would certainly require that Jean Penne modify LLR to support collecting those metrics, and possibly George Woltman would need to do the same for the gwnum library.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I am also guessing that collecting those metrics would slow down the program...which we wouldn't necessarily want to do just so that credit assignment could be more consistent...
____________
 |
|
|
