[QUOTE=xilman;441212]The work curve has a very flat minimum. It doesn't matter very much whether you run more curves at a lower B1 or fewer at a higher one, as long as you don't push it too far. To an excellent approximation, the product B1*#curves is the figure of merit.[/QUOTE]

Does the above apply only to stage one?

What about the B2 bound?

For P−1, I think it normally doesn't find factors beyond the bound B2, unless exceptionally by Brent-Suyama extension.

Does ECM routinely find factors beyond the B2 bound? What is the effect of increasing the B2 bound, does it merely increase the probability of finding a factor within the B2 bound?

I don't think that it will be possible to factor completely any more Fermat numbers with the current technology.
Either computational power needs to be increased either by using multiple computers or by using micro processor speed or improvements with in factoring algorithms need to be made or quantum computers - Shor's algorithm should need to be built out effectively and then efficiently up (Integer Factorization Problem Improvements ⇔ Discrete Logarithm Problem Improvements)! (Google Search Engine features much more symbols than character map).
If 2,1024+ did not drop off a small 40-digit factor, it would be only factored recently, right now. 2,1039-, first kilo bit SNFS factorization had been done how ever as early as Monday 21 May 2007.
It had been very lucky enough that the 564 digit cofactor of 2,2048+ is being prime number candidate, or it would also have been infeasible - computationally out of reach too, right now! Given that fixed penultimate prime factor candidate of 2,2048+ which is being a smaller number candidate - not - not - larger number candidate!

[QUOTE=Raman;442973]I don't think that it will be possible to factor completely any more Fermat numbers with the current technology.
Either computational power needs to be increased either by using multiple computers or by using micro processor speed or improvements with in factoring algorithms need to be made or quantum computers - Shor's algorithm should need to be built out effectively and then efficiently up (Integer Factorization Problem Improvements ⇔ Discrete Logarithm Problem Improvements)! (Google Search Engine features much more symbols than character map).
If 2,1024+ did not drop off a small 40-digit factor, it would be only factored recently, right now. 2,1039-, first kilo bit SNFS factorization had been done how ever as early as Monday 21 May 2007.
It had been very lucky enough that the 564 digit cofactor of 2,2048+ is being prime number candidate, or it would also have been infeasible - computationally out of reach too, right now! Given that fixed penultimate prime factor candidate of 2,2048+ which is being a smaller number candidate - not - not - larger number candidate![/QUOTE]
In reality it is just a matter of luck. We find a few fermat factors each year. Any one of these could leave a prp cofactor. This happens for Mersenne numbers. The issue is that the fermat numbers get bigger much quicker and less factors are found.
I don't know whether the cofactor has to be proven prime here. That would limit us to rather a small number of candidates.

I ran two curves on F25 and Prime95 reported on 19 September, but the counter on the ECM Report page has not incremented from 450.

[Mon Sep 19 18:41:52 2016]
UID: richs/Rich_-_Laptop, F25 completed 2 ECM curves, B1=1000000, B2=1000000, We4: 64119540, AID: B36AA7689965395BB40858081FC4****

What did I do wrong?

Looks like there was no stage 2 run. Two curves at B1=1M were not enough to count as 1 curve at B1=1M, B2=100M

I'm still pursuing a particular approach to a (new) completed Fermat number factorization but the solution timeline is now tenuous. Is there any optimism, probabilistically speaking, of obtaining a factorization via conventional approaches?

Ok. Asked and answered.

[QUOTE=jwaltos;443701]I'm still pursuing a particular approach to a (new) completed Fermat number factorization but the solution timeline is now tenuous. Is there any optimism, probabilistically speaking, of obtaining a factorization via conventional approaches?[/QUOTE]

Monitor the [URL="http://www.mersenne.org/report_ecm/?txt=0&ecm_lo=2&ecm_hi=1000&ecmnof_lo=2&ecmnof_hi=1000"]ECM progress page[/URL] and you'll see the number of curves tested increasing by a few (less than ten) on most days. However, it will probably need tens of thousands of curves or hundreds of thousands.... so it's liable to take a while, and that's a necessary but not necessarily sufficient condition.

On a 2.4 GHz Haswell machine, each curve for F12 takes maybe 3 hours and each curve for F13 takes maybe an hour (using mprime).

In a few hours I will finish a run of 10 curves for F12. Will Prime95 automatically submit the results into server despite the fact that I didn't setup my client ID on it or should I manually submit them onto Prime95 webpage at ''MANUAL TESTING/RESULTS'' submission form?

Also how can I set on the txt files stage 2 to use 4GB? Running two cores on a 16GB machine.

Thank you in advance.

[QUOTE=pinhodecarlos;443787]In a few hours I will finish a run of 10 curves for F12. Will Prime95 automatically submit the results into server despite the fact that I didn't setup my client ID on it or should I manually submit them onto Prime95 webpage at ''MANUAL TESTING/RESULTS'' submission form?
[/QUOTE]

By default, your prime.txt file will say UsePrimenet=1, unless you set it differently. If so, the results will be automatically submitted.

[QUOTE=pinhodecarlos;443787]Also how can I set on the txt files stage 2 to use 4GB? Running two cores on a 16GB machine.[/QUOTE]

If you are asking how to use GMP-ECM for stage 2, I think it involves setting GmpEcmHook=1 as described in undoc.txt, and some [URL="http://www.mersenneforum.org/showthread.php?t=20092"]discussion can be found in this thread[/URL].

I've uploaded 10 curves for F12. More to come next week.

[CODE]
[Thu Sep 29 19:34:22 2016]
F12 completed 5 ECM curves, B1=800000000, B2=80000000000, We4: D02C2838
F12 completed 5 ECM curves, B1=800000000, B2=80000000000, We4: D02C2838
[/CODE]