GPU72 and BOINC a match made in ....

[LaurV]

Originally Posted by KEP

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.

That what Chris says , as he likes to have his constant feed for the LL-ers/PRP-ers. I didn't say anything about 73-77, or 74-77, etc. My argument is solely on the side that the "last bit" should always be done ONLY after we do some P-1. With a "good" card, you can go to 5%, but even with a "not so good" card, at least a 3% P-1 should be done before doing the last bit (I mean, not necessarily by the same card, let other people do it, who have the hardware and like to do P-1).

Also, I am talking solely on the line of GPUs I went over time: gtx580, Titan (classic and black), 1080Ti, 2080Ti. These all cards were always the "good" side (i.e. good FP64 ratio) .

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)?

Exactly.

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?

Here somebody else has to answer.

[chalsall]

Originally Posted by LaurV

My argument is solely on the side that the "last bit" should always be done ONLY after we do some P-1.

As always, it's a little complicated. Basically, what we're dealing with here is a disparate resource management problem.

Thanks to James' analysis, we know that for the more modern cards it is "optimal" to TF to 78 bits before running the FC ***on the same card***. Older cards shouldn't go as high.

But this assumes each and every deployed card will switch between the work types (TF'ing vs. FC'ing) when appropriate. In reality, this doesn't happen, so instead, different people will choose different depths to "pledge" to. And some just like TF'ing, so don't really care if they TF past the optimal for their particular card(s). And, since BOINC isn't issuing FC work, this economic cross-over analysis doesn't really apply.

Now, with regards to P-1'ing, again it comes down to resource availability. Because George sets the B1/B2 bounds as a function of the TF'ed depth, it takes /slightly/ less time (with an associated slightly less probability of finding a factor during the run) the higher a candidate has been TF'ed.

And, of course, whichever work type does the next step (TF a bit, or P-1) and finds a factor helps the other work-type workers, since further work is no longer needed.

With regards to how many P-1 jobs are done per day, that varies widely. R. Propper can do hundreds a day -- I have no idea what his long-term plans are.

[axn]

Originally Posted by chalsall

Thanks to James' analysis, we know that for the more modern cards it is "optimal" to TF to 78 bits before running the FC ***on the same card***.

This is a misconception. The correct way to read that chart is: "It is "optimal" to TF to 78 bits before running two LL (FC & DC) on the same card"

IOW, if your intent is to speed up /only/ the FC (in order to accelerate the next prime find), then you should do 77 bits.

[chalsall]

Originally Posted by axn

IOW, if your intent is to speed up /only/ the FC (in order to accelerate the next prime find), then you should do 77 bits.

Absolutely true.

But, as we all know, James' analysis is an absolute ideal optimization of resources. That simply isn't possible at GIMPS, because of the huge disparity in the completely autonomous (and volunteer) participants.

Short of an omniscient and omnipotent entity stepping forward to manage /all/ the resources, we do the best we can as the simple humans we are.

Further, the opposite argument to yours can be made. If we have TF'ing resources that aren't going to be redirected to FC'ing, should they optimally TF the ranges years ahead of the wavefronts? Or should they instead TF past the optional only a few months ahead?

I would argue the latter, where people are willing.

[LaurV]

Everything nice with what you and axn say, except that you point that link to a T4, which is not a "good" card in my definition - it spits out a lot of TF indeed, but it is very weak at FP64. That is more like a "gaming" card, and it should be used mostly for TF. So, you could be right, but - and here is the but: nobody have such card, and nobody uses one, except Colab, and even that, only seldom (for lucky guys ). How many users play with a T4? Guys who can afford Teslas, won't spoil them at TF. The comparisons should be done for 10xx, 16xx, and 20xx cards as most people play those.

[chalsall]

Originally Posted by LaurV

How many users play with T4? Guys who can afford Teslas, won't spoil them at TF. The comparisons should be done for 10xx, 16xx, and 20xx cards as most people play those.

I'm running three T4s right now...

But, OK... If you want to get into the analysis paralysis domain... It comes down to how many cards of the various Compute Versions are working at what. A Telsa P100 (CV 6.0) should only go to 76, while a GeForce GTX 1080 (CV 6.1) should go to 77, for example.

Would you like to take on the task of providing us with an inventory of the currently deployed kit?

[Prime95]

Originally Posted by chalsall

Thanks to James' analysis, we know that for the more modern cards it is "optimal" to TF to 78 bits before running the FC ***on the same card***. Older cards shouldn't go as high.

And even this is more complicated. James' chart assumes no P-1. Since P-1 will find some of the factors between 2^77 and 2^78, TF'ing from 2^77 to 2^78 is not as profitable as James' chart indicates. In other words, don't switch to 2^78 TF when the chart indicates it to be only marginally profitable.

[Prime95]

Originally Posted by chalsall

Further, the opposite argument to yours can be made. If we have TF'ing resources that aren't going to be redirected to FC'ing, should they optimally TF the ranges years ahead of the wavefronts? Or should they instead TF past the optional only a few months ahead?

I would argue the latter, where people are willing.

I agree 100% with this conclusion.

Arguing about the optimum bit level is a bit silly. 1) There are a wide variety of GPUs participating each with their own optimum, and 2) If you have an excess of TF resources available, put them to work TF'ing past the theoretical optimum bit level.

You have a short term problem. TF resources "fell behind" the first-time testers and Chris is now juggling these cool new TF resources to best feed the 4 wavefronts and the P-1'ers.
Your long term solution is easy. Guess where the cat 4 wavefront is a year from now and TF that range as much as the TF resources allow (depth-first, breadth-first, probably does not matter much).

At some point, we should also look at taking some of the excess TF resources and pointing it at the 100M digit range.

[Uncwilly]

Originally Posted by Prime95

At some point, we should also look at taking some of the excess TF resources and pointing it at the 100M digit range.

Thank you kind sir.

[chalsall]

Originally Posted by Prime95

At some point, we should also look at taking some of the excess TF resources and pointing it at the 100M digit range.

Already modeled. In fact, the code already exists from years ago; I just need to reactivate it.

Also, the DC range, once the FC ranges are comfortable.

[KEP]

Originally Posted by Prime95

At some point, we should also look at taking some of the excess TF resources and pointing it at the 100M digit range.

Maybe the plan, should be to get n<=120M to 78bit, then we should be ahead of FC enough to spread the ressources between DC, 100M and n<120M to as high a bit as possible before the wavefronts catch up. Then take the next 10M n towards 79 bit before returning to DC, 100M and as high a bit as possible before the wavefront catches up.

Originally Posted by chalsall

Already modeled. In fact, the code already exists from years ago; I just need to reactivate it.

Also, the DC range, once the FC ranges are comfortable.

I know it is intriguing to go and throw some ressources at the 100M digit range. It sure is nice to see that some "ancient" code excist to do that job, but untill there is adequate room between the wavefront of TF and the various FC and P-1 wavefronts, I would sure appreciate if we wavered that part of TF for the next time being. But of course, as you and George mention, for the future, once the world gets back to normal and our ressources stabilies it sure is a great suggestion