[QUOTE=James Heinrich;279372]Actually no: The credit is based solely on FFT size and bounds:[code]// $timing is from a precalculated lookup table based on exponent size
return ( $timing * ( 1.45 * $B1 + 0.079 * ($B2 - $B1) ) / 86400.0 );[/code]All exponents between M58,520,000 and M60,940,000 should use FFT size of 3200K and so if the [I]same bounds[/I] are chosen for each exponent then the credit will be exactly the same. Of course, the credit for a L-L test does vary directly with the exponent so it's quite possible that Prime95 would choose different bounds and therefore give different credit for similar assignments, but if the exponents are close enough together it's reasonable to assume that identical bounds would be chosen and therefore identical credit given.[/QUOTE]

I've actually seen the fourth digit vary.

[QUOTE=davieddy;279745]Whether or not a factor is found by P-1 is determined purely by the bounds, right? The amount of memory available just affects the speed. Right?[/quote]For [i]fixed bounds[/i], the amount of available memory just affects the speed, not the chance of finding a factor.
Of course, the speed differences with different amounts of memory usually dictate the choosing of different bounds for optimal efficiency, but that's another discussion.

[QUOTE=davieddy;279745]If we decide on the optimum TF and P-1 bounds, it is of marginal importance when we do the P-1, since most of the time no factor will be found. So GPUs should go all the way on TF without waiting
for the P-1 which won't get done anyway. Right?[/QUOTE]I assume you're referring to the concept of leaving a bitlevel or two of TF for [i]after[/i] P-1.
My opinion is that (especially considering the relative surplus of TF power now available) the split-TF approach could safely be abandoned: Do TF up to a GPU-reasonable level (e.g. 2^72 per [i]chalsall[/i]'s new project's name). After that, assuming no factors found, then us P-1'ers come in and try and do a decent test before the exponent gets unleashed on the L-L'ers (who may or may not do a reasonable P-1 (or any at all)).

It's possible that the last bit of TF could obviate the P-1 test, or vice versa; overall I don't think it makes much difference which is done first, although I suspect overall the GPU-TFs are still cheaper and should be done first. Note that this is because of the lower cost of GPU-TF. Throwing out some number for 60M-range exponents: it takes about 5GHz-days for a good P-1 (~4.5%) and 15GHz-days to TF 2^68 to 2^72 (~5.75%). So you get a somewhat higher chance of factor for 3x the apparent effort, but it translates to considerably [i]less[/i] effort since GPUs bring 5x-50x the power of CPUs.

Many thanks James.
Exactly my thoughts.
But the LL tester intent on finishing it (regrettably a minority apparently)
would be barmy not to do P-1 first if it hadn't been done aleady.

David

PS the "overlap" of P-1 and TF ~30%

[QUOTE=James Heinrich;279748]My opinion is that (especially considering the relative surplus of TF power now available) the split-TF approach could safely be abandoned: Do TF up to a GPU-reasonable level (e.g. 2^72 per [i]chalsall[/i]'s new project's name). After that, assuming no factors found, then us P-1'ers come in and try and do a decent test before the exponent gets unleashed on the L-L'ers (who may or may not do a reasonable P-1 (or any at all)).[/QUOTE]

James et al... If I may give some (very) raw data of what I know:

[CODE]mysql> select count(*) from GPU where Status<9 and P1=1;
+----------+
| count(*) |
+----------+
| 15539 |
+----------+
1 row in set (0.02 sec)

mysql> select count(*) from GPU where Status<9 and P1=1 and B1=B2;
+----------+
| count(*) |
+----------+
| 5254 |
+----------+
1 row in set (0.01 sec)[/CODE]

This tells me that approximately one third of those LL and DC candidates currently held by "GPU to 72" which had P-1 work done on them were done "poorly". As in, the B1 was the same as B2 which (if I understand it correctly) means phase 2 of the P-1 process was not done because of lack of memory.

From this, then, would it be desirable of some P-1 workers to rework such candidates before releasing them to LL / DC workers?

We have had many P-1 workers complain they couldn't get P-1 work which had already been TFed to 2^72. And, to my surprise, the project has a [B][I]lot[/I][/B] of very serious P-1 fire-power.

[QUOTE=chalsall;279756]As in, the B1 was the same as B2 which (if I understand it correctly) means phase 2 of the P-1 process was not done because of lack of memory.[/quote]Correct. If insufficient memory is available, only stage1 will be done [i]but[/i] it will have a much higher B1 chosen to compensate (such that the probability vs effort remains proportionate).

[QUOTE=chalsall;279756]From this, then, would it be desirable of some P-1 workers to rework such candidates before releasing them to LL / DC workers?[/QUOTE]No, not for this definition of "poorly".
There's "good" (B2 > B1 and plenty of RAM available for good bounds) ~= 5-6% probability.
There's "adequate" (B2=B1 due to lack of RAM) ~= 3-4% probability.

And then there's "poor", where the user overrode the default bounds and picked something silly. For example, some of the [url=http://mersenne-aries.sili.net/p1small.php?worst=1]worst offenders[/url]. I've cleaned up most of the worst offenders over the last few years, things like B1=30,B2=100 and nonsense like that. Unfortunately PrimeNet accepts any P-1 as being "done", even if it has an infinitesimal probability (I'd prefer to see PrimeNet reject any no-factor P-1 result that has <2% chance of factor to prevent these follies).

If there's a surplus of P-1 workers, give them exponents that have been LL'd but not DC'd and not P-1'd (I'm not sure if you look for these currently?). If there's none of that, better use of resources to do normal pre-LL P-1 rather than spend same 5GHz-days for a 1-2% incremental chance of factor over the previous P-1.

[QUOTE=James Heinrich;279757]And then there's "poor", where the user overrode the default bounds and picked something silly. For example, some of the [url=http://mersenne-aries.sili.net/p1small.php?worst=1]worst offenders[/url]. I've cleaned up most of the worst offenders over the last few years, things like B1=30,B2=100 and nonsense like that. Unfortunately PrimeNet accepts any P-1 as being "done", even if it has an infinitesimal probability (I'd prefer to see PrimeNet reject any no-factor P-1 result that has <2% chance of factor to prevent these follies).[/QUOTE]

Thanks for that clarification James.

[QUOTE=James Heinrich;279757]If there's a surplus of P-1 workers, give them exponents that have been LL'd but not DC'd and not P-1'd (I'm not sure if you look for these currently?).[/QUOTE]

The system has never encountered a DC candidate which hasn't been P-1'd.

[QUOTE=James Heinrich;279757]If there's none of that, better use of resources to do normal pre-LL P-1 rather than spend same 5GHz-days for a 1-2% incremental chance of factor over the previous P-1.[/QUOTE]

That's what is happening now for those workers who are willing to work on candidates TFed to less than 72 "bits". But they have to explicitly ask for such work by changing the "Minimum TF level" from 72 to 71 on the request form.

Otherwise they're told "Sorry -- no such work available".

[QUOTE=davieddy;279745]Whether or not a factor is found by P-1 is determined purely by
the bounds, right? The amount of memory available just affects the speed.
Right?[/QUOTE]Usually right, but not always.

James's explanation is fine as far as it goes, but doesn't mention the Brent-Suyama extension.

When there's a [U]lot[/U] of available memory (more than even some dedicated P-1ers allocate) for P-1 stage 2, prime95 will use the Brent-Suyama extension to extend the factor search much higher than the specified B2, at the cost of much memory space.

(If I find a simple explanation, I'll add a link. Alex Kruppa has written a thesis with "[t]he main ideas of the Brent-Suyama extension ...". See [URL]http://www.mersenneforum.org/showthread.php?t=8190[/URL])

[QUOTE=chalsall;279759]The system has never encountered a DC candidate which hasn't been P-1'd.[/quote]There's [url=http://mersenne-aries.sili.net/p1small.php?prob=2&min=44700000&max=44800000&onlystage1=0&ignorenop1=0&showassigned=0]hundreds of them[/url] (change the dropdown from "ignore LL tests left" to "1 LL test left" to see the counts and ranges).

[QUOTE=chalsall;279759]Otherwise they're told "Sorry -- no such work available".[/QUOTE]A single-click link to re-post the form with the max bitlevel reduced by one would be a good idea, methinks. Or possibly leave the max bitlevel field blank by default, and only restrict it to that if explicitly entered, otherwise return from the whole pool in descending order of bitlevel, that way if a 72-bit assignment is available then great, otherwise it will automatically fall back to 71 or 70 or whatever.

[QUOTE=James Heinrich;279763]A single-click link to re-post the form with the max bitlevel reduced by one would be a good idea, methinks.[/QUOTE]

Was "1-click" not patented by Amazon.com? I would hate to be sued by the "big boys".

(That's meant to be funny, and serious, at the same time.)

I appreciate your suggestion. It's a good one.

[QUOTE=James Heinrich;279763]There's [url=http://mersenne-aries.sili.net/p1small.php?prob=2&min=44700000&max=44800000&onlystage1=0&ignorenop1=0&showassigned=0]hundreds of them[/url] (change the dropdown from "ignore LL tests left" to "1 LL test left" to see the counts and ranges).[/QUOTE]

I don't disagree with you.

I've simply said my system has never encountered any.

These statements are not in opposition.

(If I may say again, I really enjoy working with really smart and attentive people. :smile:)

How hard would it be to implement something in P95 to say "no B1-smooth k, do stage 2"? As far as I know stage 2 doesn't need the stage 1 memory file as long as the result is known.