Is there a way to force Prime95 to do more frequent GCDs? Forgive my feeble grasp of P-1, but I believe factors are only discovered during the GCD process, at the end of each stage, correct? For particularly large P-1 assignments, if I could get it to do a GCD maybe once a week, (is it?) possible I've already come across a factor and I don't need to continue searching?

I think I remember some discussion along these lines from a couple years ago, but I was unable to find the thread (if there was one).

For now, I've replicated the assignment line in worktodo with successively higher bounds, and not deleting the savefiles; is this a reasonable way of faking it?

[QUOTE=James Heinrich;254231]For now, I've replicated the assignment line in worktodo with successively higher bounds, and not deleting the savefiles; is this a reasonable way of faking it?[/QUOTE]Yes.

[QUOTE=James Heinrich;254231]For now, I've replicated the assignment line in worktodo with successively higher bounds, and not deleting the savefiles; is this a reasonable way of faking it?[/QUOTE]

[QUOTE=cheesehead;254267]Yes.[/QUOTE]
The obvious question is why the software doesn't successively increase the bounds (up to the point where it would no longer be worth continuing the search) until a factor is found without this user-induced faking, especially given the highly in-demand status of P-1 factoring and hence the desirability of speeding the process up. Does anyone know if this method can actually hasten the elimination of candidate exponents for the project as a whole by declaring factors faster?

I believe the discussion centred on the overhead involved in doing the GCD vs the time saved by doing multiple GCDs. For smaller exponents I assume it was agreed that the extra overhead wasn't worth the time potentially saved. But as assignments get larger, I think it may be worth re-examining the question?

A typical 53M P-1 test takes (on a P4-3200 with 1750MB allocated to Prime95) roughly 26 hours to do Stage 1, 40 hours to do Stage 2, and each GCD takes less than 5 min. So, unless you proceed by very small increments of B1 and B2 bounds, the overall should be that much.

Correction: I was meaning to write "(...) [U]not[/U] be that much".

The TF wavefront is now more than 30M ahead of the LL wavefront.

Perhaps the "do last bit of TF after P-1" change should be undone in order to effectively halve that gap within a foreseeable timeframe.

And once the gap once again reaches some considerable size - say, 20M - afterwards, perhaps we should even do an additional bit of TF before the P-1 step, cutting the gap in half again.

Just my $0.02, of course. :wink:

[QUOTE=ckdo;256582]Perhaps the "do last bit of TF after P-1" change should be undone...
...even do an additional bit of TF before the P-1 step[/QUOTE]:tu: I'm inclined to agree on both points.

Such new recommendations would obviously have to be managed by the PrimeNet server as it hands out work, but also should be updated on ([url]http://www.mersenne.org/various/math.php[/url], heading Trial Factoring, trial factoring limits), which is also referenced in mfaktc's README.txt file.

The TF limits may also need re-weighting to allow for the huge change in TF productivity due to GPU computing contributions.

The table "for this exponent, TF this far" and that relationship with performing additional TF before / after the P-1 stages is important for the amateurs who want to contribute in a helpful way but are still gaining understanding of the nuances involved. Easy, clear, "do this" instructions are the best.

[QUOTE=ckdo;256582]The TF wavefront is now more than 30M ahead of the LL wavefront.[/QUOTE]
ckdo,

I keep hearing (reading?) about the "wavefront," and I always thought that that meant the leading edge of where each kind of PrimeNet-assigned work is.

Yet my little P233 notebook has been doing TF in the 175M range (automatically assigned), while my Pentium Dual Core is doing first-time LL tests in the 50M range (also assigned automatically). Visually that would appear to be a difference of 125M, not 30M.

I'm sure I have misunderstood something somewhere. What exactly does the "wavefront" constitute?

Thanks!

Rodrigo

[QUOTE=Rodrigo;256611]ckdo,

I keep hearing (reading?) about the "wavefront," and I always thought that that meant the leading edge of where each kind of PrimeNet-assigned work is.

Yet my little P233 notebook has been doing TF in the 175M range (automatically assigned), while my Pentium Dual Core is doing first-time LL tests in the 50M range (also assigned automatically). Visually that would appear to be a difference of 125M, not 30M.

I'm sure I have misunderstood something somewhere. What exactly does the "wavefront" constitute?

Thanks!

Rodrigo[/QUOTE]

If your worktype is TF you will get assignments in the 80M range.
If TF-LMH; then in the 180M range.

Subject to: [url]http://www.mersenne.org/thresholds/[/url]