GPU72 and BOINC a match made in ....

[KEP]

Originally Posted by chalsall

Lastly... If the run-time is really such an issue for BOINC, why not take LaurV up on his offer to provide a version of mfaktc which breaks the bigger jobs down into sub-jobs?

Let's see if that changes. At least now credit will improve, so maybe the oppinion from the few complaining about credit, will change their state of mind. If people still end up complaining about the runtimes, then of course, if it does not mess up the functioning setup that BOINC has now, it could be time to bring LaurV into action with a new version of mfakt(c)(o)

Now, please understand, that GPU72, is a new subproject on a complete different project website. We have already benefit greatly from the credithunters, but it will be a while, before we see that BOINC users only coming to do GPU72 they settle for srbase. Once that settle happens, we will propably see that the users accept crunching for hours and eventually days. But let's wait and see what the future holds.

Personally I feel that BOINC should also be able to pick the low hanging fruits in stead of just doing the heavy lifting. Of course as the situation is now, BOINC ressources is best used to go to 78 bit (eventually higher) and prepare for P-1, but in the long run, we could actually attract more users, especially those with ~100 GHzdays/day hardware (my old GPU).

Those persons with 100 GHzdays/day hardware are having a hard time with these high bit levels and it is not productive in any way - wether being a BOINC project or not - to exclude certain part of users from participating. So whoknows, maybe in the future, we could do much better, by having a lowhanging fruit for the slow hardware and a heavy lifting subproject for GPU72 at BOINC.

That decision still lies in the future, but it could sure meet the demands of both hardwaregroups, if that demand does not become obsolete because we attract hundreds or thousands of TF users, being their from interest in GIMPs more than from a credit perspective

Thanks for your reply, and I do still believe that we should shoot for n<=120M to 78 bit, the ressources are there to accomplish that task

[Prime95]

A BOINC theory question. It seems there are a substantial group of BOINC users that pick projects solely based on maximizing credits earned. What prevents a project from using a credit formula that is a bit more generous than other projects? Since all projects have a similar incentive, why hasn't "credit inflation" set in over the years?

[Prime95]

Originally Posted by KEP

To be honest I don't get it, why most projects don't use BOINC at all. It really shouldn't be hard to set up BOINC and make things working, if you have already made all the initial programming of independent software.

When I looked at BOINC many, many years ago there were several obstacles. 1) It would be a lot of work for me (and Scott). 2) The really long work units were unheard of in the BOINC universe. 3) There were some differences in the workflow (I don't remember what they were) that might cause some current GIMPS users to grumble.

But I think the big reason was this: There was a general feeling among users that it would be appalling for the discoverer of a new Mersenne prime to have no appreciation for what he has discovered.

[RichD]

Originally Posted by KEP

So whoknows, maybe in the future, we could do much better, by having a lowhanging fruit for the slow hardware and a heavy lifting subproject for GPU72 at BOINC.

I don't know anything about BOINC (or BOINC server setup) but could there be two sub-projects for the user to decide? One is GPU72 and the other is GPU82 where TF level 77 and 78 are the low hanging fruit for the long haul, heavy hitters. Guessing GPU cards will only get bigger and better.

[chalsall]

Originally Posted by RichD

I don't know anything about BOINC (or BOINC server setup) but could there be two sub-projects for the user to decide? One is GPU72 and the other is GPU82 where TF level 77 and 78 are the low hanging fruit for the long haul, heavy hitters.

Excellent suggestion.

Over on SRBase there are already different classes of work available for the Sierpinski / Riesel WUs. Short, Long and Average.

The Long class has an average run-time of ~60 hours. This seems it would map well to the GIMPS TF'ing problem space. Reb could reserve blocks as appropriate for each class.

Originally Posted by RichD

Guessing GPU cards will only get bigger and better.

Already empirically demonstrated!

[pinhodecarlos]

Originally Posted by Prime95

A BOINC theory question. It seems there are a substantial group of BOINC users that pick projects solely based on maximizing credits earned. What prevents a project from using a credit formula that is a bit more generous than other projects? Since all projects have a similar incentive, why hasn't "credit inflation" set in over the years?

Nothing prevents them to increase, problem is the boycott from other teams and users, which at the end it can damage the project reputation. Found the link to a boinc stats page which shows the credit comparison between all projects.


https://www.boincstats.com/stats/-1/cpcs

[pinhodecarlos]

Originally Posted by chalsall

That is correct. In fact, the equation I gave above was originally designed for calculating the credit for CPU TF'ing. There was a bit if a lengthly debate years ago about whether there should be scaling applied to give GPUs less credit, because they are ***soooo*** much faster at the work.

On Boinc world it is fair to say that you can credit the GPU app as many times higher than GPU is faster than the CPU app for the common unit of measurement.

[petrw1]

For much of the last week it was 80-100 users.
For the last few hours it has been under 70.

Could it be time of day?
Could it be waning interest?
Could it be people scared off by longer run times of TF78?

I really have no idea; just throwing it out there.

[KEP]

Originally Posted by Prime95

A BOINC theory question. It seems there are a substantial group of BOINC users that pick projects solely based on maximizing credits earned. What prevents a project from using a credit formula that is a bit more generous than other projects? Since all projects have a similar incentive, why hasn't "credit inflation" set in over the years?

To be honest I don't know, but as far as I know, the credit is valued in cobblestones and the cobblestone (at least as it is initially thought to work) should be a possible measurement of the actual computation completed per workunit. I really think that some projects has had "credit inflation" and to the extend that it does not really undermine the whole idea of the cobblestones, it could be okay. As far as I remember, a computer that does 1 GFLOPs produces 200 cobblestones credit a day. Could this in anyway be transformed into GHz days, with that knowledge in hand?

Originally Posted by Prime95

When I looked at BOINC many, many years ago there were several obstacles. 1) It would be a lot of work for me (and Scott). 2) The really long work units were unheard of in the BOINC universe. 3) There were some differences in the workflow (I don't remember what they were) that might cause some current GIMPS users to grumble.

But I think the big reason was this: There was a general feeling among users that it would be appalling for the discoverer of a new Mersenne prime to have no appreciation for what he has discovered.

Well, in BOINC each and every user has their own account, just like in GIMPs and when a user completes a workunit, he/she has a record under his/hers username describing that this and this user found a prime. So credit would still be possible to award to a single user. BOINC really isn't that much different from Primenet, only there is currently 914914 active hosts spread on 145229 active users. Some users not being active might "reactivate" once they see a new BOINC project. As such srbase is not a new project, but GIMPs would deffinently have caught a lot of attention as being a new project. So the big reason is not at all justified. And back then, climateprediction asked users to use 4-6 weeks of their computers to compute weathermodels, no need to say GIMPs dwarf that

Originally Posted by RichD

I don't know anything about BOINC (or BOINC server setup) but could there be two sub-projects for the user to decide? One is GPU72 and the other is GPU82 where TF level 77 and 78 are the low hanging fruit for the long haul, heavy hitters. Guessing GPU cards will only get bigger and better.

Yes, that should be possible, but if I remember correctly, there is a limit how many subprojects that Reb can set up and if there is no free slots for further subprojects, it might not be possible. I however, if it is possible would also like such a feature, at least to give the users with a slow and old GPU a fair chance to not have to work for days to complete imideate work. It will also as mentioned previously keep users at our hand, users that does not prefer the long running workunits and in general give the user some flexibility to flex back and forward between short and fast workunits and long running workunits.

[LaurV]

Originally Posted by chalsall

To put on the table, perhaps going to 78 is a bit too far (literally).

What I am "arguing" for years now, is doing P-1 before the last bit. I can "prove" this saves time. The idea is not mine, George used to incorporate it in the very first versions of P95, long before GPUs entered the arena.

In our case, going to 77 would be fine for the MOST of the cards (see James tables), then wait till at least a 3-5% P-1 is done, and only then, do the last bit (78) for the remaining candidates.

So, 77, P-1, 78.

For the "good" cards, i.e. those with good FP64 speed, which can run P-1/LL/PRP reasonable fast, the process (at 100M+ exponents) should be even "worse": 76, P-1, 77.

I would kinda "waste" my 2080Ti and 1080Ti running the last bits for candidates with no P-1. I can run about 40 P-1 assignments to 3% in the same time I could run 76 or 77 TF to 77 bits, so you see I could find 1.2 factors by P-1 in the same time I can find only 1.0 factors by TF, at this bitlevel.

[KEP]

Originally Posted by LaurV

What I am "arguing" for years now, is doing P-1 before the last bit. I can "prove" this saves time. The idea is not mine, George used to incorporate it in the very first versions of P95, long before GPUs entered the arena.

In our case, going to 77 would be fine for the MOST of the cards (see James tables), then wait till at least a 3-5% P-1 is done, and only then, do the last bit (78) for the remaining candidates.

So, 77, P-1, 78.

For the "good" cards, i.e. those with good FP64 speed, which can run P-1/LL/PRP reasonable fast, the process (at 100M+ exponents) should be even "worse": 76, P-1, 77.

I would kinda "waste" my 2080Ti and 1080Ti running the last bits for candidates with no P-1. I can run about 40 P-1 assignments to 3% in the same time I could run 76 or 77 TF to 77 bits, so you see I could find 1.2 factors by P-1 in the same time I can find only 1.0 factors by TF, at this bitlevel.

Interesting

Now let me see if I understand it correctly. As I read you, we should prioritiez 76-77 then 75-77, then 74-77 and if any remain 73-77 bit, before doing 78 bit on candidates already P-1 tested.

I'm not sure how you have investigated this, but as soon as we go above n=120M, optimum bit will be 79 bit and around 153M it will increase to 80 bit. Is it your interpretation, that the rule of thumb, is for most if not all n as follows:

TF(Optimum bit)-1,P-1 factoring,TF(Optimum bit)?

Does anyone know what the daily need to keep the P-1 factorers satisfied is? In other words, how many tests does the P-1 users complete tests each day?