GPU72 and BOINC a match made in ....

[Chuck]

Originally Posted by chalsall

No assignments have yet been fetched by SRBase, so that's why you're not seeing it in any of the lists. Hopefully soon...

How are these BOINC results being reported to Primenet? Under one userid? SRBase? I can't find any results on GPU72 or Primenet.

[KEP]

Originally Posted by Chuck

How are these BOINC results being reported to Primenet? Under one userid? SRBase? I can't find any results on GPU72 or Primenet.

They are coming, as soon as all 1000 results has been completed and is going to be under 1 username. The BOINC user gets the credit for completing the assignment and the project gets the credit at primenet.

We are in a testing phase still, so Reb wants to have all work currently in progress returned, so he can check if something is not right (It appears that for windows everything works flawlessly).

Once we go into full production phase, I hope that the suggestion of returning results for partial completed ranges and reserving and loading new worklines before the last few slow results is submitted - is going to be effectuated. That should thereby make us "never" run out of work and a more regular increase in the credit will be seen.

[chalsall]

Originally Posted by KEP

Once we go into full production phase, I hope that the suggestion of returning results for partial completed ranges and reserving and loading new worklines before the last few slow results is submitted - is going to be effectuated.

Yes... That is going to be important, particularly considering Reb has asked for (and I have provided) the ability to reserve 10,000 assignments at a time.

It doesn't make sense to have to wait for every last assignment to complete in such large assignment blocks before submitting the results to Primenet. His initial test batch of 1,000 assignments (from Primenet, in 102M) has been held up for days because of (currently) 73 outstanding work-units.

[KEP]

Originally Posted by chalsall

It doesn't make sense to have to wait for every last assignment to complete in such large assignment blocks before submitting the results to Primenet. His initial test batch of 1,000 assignments (from Primenet, in 102M) has been held up for days because of (currently) 73 outstanding work-units.

I can't give you the explanation, but it was also what we did back when we worked on setting CRUS up at srbase. Those last stragglers can take their time. But hopefully in 48 hours, we will be ready for production phase. That will hopefully attract some users that only runs SRbase with their GPUs and thereby speed up the processing.

If I did understand Reb correctly (and I'm sure I did) and if Reb understood my reply correctly (I'm sure he did), then because the server removes the completed worklines from an active reservation and leave those with no results remaining, turning in results from partially tested ranges and load new work before we reach 0 and more importantly load more work before we have cleared everything - should be possible To be honest I can't really see why it shouldn't happen that way, especially with your new coding. I'm like Reb glad that your new code hands out tests with the same bit, this reduces the preprocessing, since credit is almost or entirely the same for each test

Now we all have to show a little more patience, and then hopefully in the weekend, the last tests with Linux is done and we are good to go with production mode. Anyway how it ends up looking, we will see a huge production increase once we go live

[chalsall]

Originally Posted by KEP

I'm like Reb glad that your new code hands out tests with the same bit, this reduces the preprocessing, since credit is almost or entirely the same for each test

As usual, it's more complicated than that. Credit on Primenet (and GPU72) is a function of both the Exponent as well as the factor depth(s) done.

Here is some Perl code I use to calculate credit (this was adapted from some PHP code James provided to me several years ago):

sub CalculateGHzDaysTF {
   my ($Exp, $From, $To) = @_;
   my ($GHzDays, $Cnt);

   $GHzDays = 0;

   for ($Cnt = $From + 1; $Cnt <= $To; $Cnt++) {
      $GHzDays += (0.00707 * 2.4) * (2 ** ($Cnt - 48)) * 1680 / $Exp;
   }

   return $GHzDays;
}

I don't know if Reb can use this for BOINC credit issued to his workers, but there it is.

[Prime95]

Does the BOINC server send out each assignment twice (once for double-checking)? If so, can the server be configured to not do that?

[pinhodecarlos]

Originally Posted by Prime95

Does the BOINC server send out each assignment twice (once for double-checking)? If so, can the server be configured to not do that?

Quorum is set to one, no double-check.

[pinhodecarlos]

The issue might be on the wu deadline, might be too long.

Trying to find those outstanding wus on the project side to confirm wus deadline.

Final edit: deadline is set to 4 days.

[KEP]

Originally Posted by chalsall

As usual, it's more complicated than that. Credit on Primenet (and GPU72) is a function of both the Exponent as well as the factor depth(s) done.

I know it is more complicated than that. But for now we know that there is for an exponent n~=105330000 1500 in BOINC credit. From that Reb can calculate backwards and forward using this calculation:

If N is lower than 105330000 then:

(105330000 div average n of testrange)*1500 = credit for each test

If N is higher than 105300000 then:

(105330000 div average n of testrange)*1500 = credit for each test

This should in the first case for n=98000000 to n=99000000 give this calculation:

(105330000 / 98500000)*1500 = 1604 credit per test from 72 to 73 bit

This should in the second case for n=109000000 to 110000000 give this calculation:

(105330000 / 109500000)*1500 = 1443 credit per test from 72 to 73 bit

It all corresponds to the results in the calculation for credit for TF: https://www.mersenne.ca/credit.php and matches the less effort it takes to calculate 1 bit as n increases (Half the effort every doubleing of n)

The calculation is the same as above, if we calculate from 73 to 74 bit, then Reb has to multiply by 2. This means that in case 1, 3208 credit is given per test in BOINC and in case 2, 2886 credit is given per test in BOINC

I've plans to send Reb a more accurate calculation up to n=1,000,000,000 and maybe all the way up to 92 bit - wich I understood long ago is the limit of mfakt(o)(c). Maybe I'll just sent him a calculator or maybe both things, or something else that can make accurate credit for each n possible. I'll discuss that with Reb as we get everything flying. For now, it will be almost accurate credit and most users will end up having the exact same average one way or another, because they stay along for the entire range

@George: No the quorum is 1, it will stay like that

[rebirther]

Here a short update:
- the deadline was set to 3d but have forgot the grace_periode +1 option, in this case this means if you are over the deadline there will be no send a new task to another host as long as the first host is sending the result back in time if it was over the deadline
- the quorum is 1
- for these bits (credits) I can easily test it how much time is needed for a range

[chalsall]

Originally Posted by rebirther

Here a short update: ... for these bits (credits) I can easily test it how much time is needed for a range

Thanks for the update. Can't wait to see production!

For my own edification (I truly don't know a thing about BOINC)... Why are you doing empirical for the temporal domain? The time it takes for each run will approximately double for each bit level, while decreasing the higher the candidate. As in, a 95M will take more time than a 102M to the same bit level (on, of course, the same GPU). This is what is codified in the Perl I gave you.

There is considerable difference in run times between different GPUs on the same work. Does BOINC consider "wall-clock-time" the "value" (regardless of throughput), unlike GIMPS which awards credit as a function of the work done?

Consider me a (somewhat strange) stranger in a strange land...