This is rough, but first column shows exponent range (millions), second column is number of known factors small enough to have been found by TF, third column is number of known factors too big to have been found by normal TF limits:[code]40 43736 868
41 43048 911
42 43283 909
43 42964 924
44 43417 976
45 43332 1011
46 42886 1012
47 42966 982
48 42640 997
49 43012 903
50 43234 1082
51 43536 1258
52 42829 676
53 42707 1547
54 42758 396
55 42702 378
56 42378 247
57 42184 286
58 42003 275
59 41965 163[/code]It's rough because the cutoff changes from 2^68 to 2^69 around M49M, and TF limits have changed over the years, but it should give you some idea.

edit: attached is a more detailed breakdown of the number of factors of each bit depth for each of the 20 exponent ranges.

Many thanks for the data:

[url=http://mersenneforum.org/showthread.php?p=266558#post266558]Here are my deductions therefrom[/url]

David

[QUOTE=petrw1;261083]Before George decided to add another TF bit in the 53-59M range the P-1'ers had almost 18,000 exponents ready for LL in the 53M range. We should see a similar number back in the LL Available column in a few days once the 53M TF is done that extra bit.

Then we can watch if the LL available number grows or drops in the coming months as an indication of whether P-1 is keeping up or not.[/QUOTE]

Well 2 months and 10 days later and the extra (now 2) bits of TF are past 53M ... and in the 53-55M range where most P-1 are being assigned currently we are down to ONLY about 9,700 exponents ready for LL .... DEFINITELY NOT KEEPING UP.

As I suggested a couple weeks ago I am a few weeks away from attempting to run enough cores on P-1 to sustain a rate of 10 completions per day for the remainder of 2011 ... ANYONE ELSE?

[QUOTE=petrw1;267075]Well 2 months and 10 days later and the extra (now 2) bits of TF are past 53M ... and in the 53-55M range where most P-1 are being assigned currently we are down to ONLY about 9,700 exponents ready for LL .... DEFINITELY NOT KEEPING UP.

As I suggested a couple weeks ago I am a few weeks away from attempting to run enough cores on P-1 to sustain a rate of 10 completions per day for the remainder of 2011 ... ANYONE ELSE?[/QUOTE]

You, I and others (eg Jacob and those magnificent gerbils on
their flying machine) are on the same wavelength here.

We hope people embark on [B]and complete[/B] LL tests as frequently as possible.
Having to start with P-1 may constitute a deterrent: nuisance value,
memory, not appreciating its value etc. but at least the CPU LL tester
can profitably do it. This doesn't apply to TFing to the "Mad Max" anymore
since GPUs have made TFing their sole preserve.

I requested that a mod move a few (at the time) posts to this thread.
Instead, George (I guess) started a new thread entitled
"TF on GPUs and its impact on P-1", and placed it in the lounge
despite my opinion that the subject was a bit deeper than "coffee talk".
If you haven't done so already, I think that if you peruse it, you will
spot the relevance to this post and this thread in general.

David

I did tell another core to do P-1 this week...but it's not going to do even 1 per day.

Is it better to do 2 cores of P-1 with relatively limited (500M) memory per core or 1 core with less limited(1000M) memory per core? If the latter is the case, I can squeeze a bit more P-1 out of my 7 machines

From my individual searcher perspective, P-1 has been quite profitable...15 or 20 factors found, that's more than I'd have been able to do on LL tests in the same time.

[QUOTE=Christenson;267107]I did tell another core to do P-1 this week...but it's not going to do even 1 per day.

Is it better to do 2 cores of P-1 with relatively limited (500M) memory per core or 1 core with less limited(1000M) memory per core? If the latter is the case, I can squeeze a bit more P-1 out of my 7 machines

From my individual searcher perspective, P-1 has been quite profitable...15 or 20 factors found, that's more than I'd have been able to do on LL tests in the same time.[/QUOTE]

Unlike TF, I think one needs to get P-1 bounds right (i.e. optimized
with LL in mind) first time. Otherwise, you either have to live with it
or start from scratch.

May I politely remind you that LL tests never find a factor?*

:smile:

David

*Thanks to Sod's Law, they invariably take a long time
to confirm what we already knew - it's composite.
Can't think why we bother really.

I'm running P-1 on 7 of 8 cores (leaving 1 for mfaktc) across my two machines.
However, my focus is on the "missed" exponents, which could be anything from 50M exponents that have had 1 L-L but no P-1 at all, to [url=http://v5www.mersenne.org/report_exponent/?exp_lo=100000049]large[/url] or [url=http://v5www.mersenne.org/report_exponent/?exp_lo=10106741]small[/url] exponents that are flagged as having P-1 done, but done very poorly (e.g. B1=B2=50000 on a 100M exponent).

[QUOTE=Christenson;267107]Is it better to do 2 cores of P-1 with relatively limited (500M) memory per core or 1 core with less limited(1000M) memory per core?[/QUOTE]More memory will (slightly) increase the selected bounds, which will (very slightly) increase the chance of finding a factor, and will also (slightly) increase the runtime for P-1 on that exponent. Adding a second core basically double your throughput. And under normal circumstances the two workers should be able to alternate the 1000MB much of the time (if one is in stage1, and the other in stage2, the stage2 one can grab all 1000MB; it's only when they're both in stage2 that they'll get 500MB/ea). Making up some numbers (for illustrative purposes only):
2 cores fixed at 500MB/ea: 2x 5.0% chance over 3.2GHz-days
2 cores sharing 1000MB: 2x 5.1% chance over 3.4GHz-days
1 cores fixed at 1000MB: 1x 5.1% chance over 1.7GHz-days

So I will ask another core here to do P-1...hope it helps....

[QUOTE=James Heinrich;267118]And under normal circumstances the two workers should be able to alternate the 1000MB much of the time (if one is in stage1, and the other in stage2, the stage2 one can grab all 1000MB; it's only when they're both in stage2 that they'll get 500MB/ea).[/QUOTE]

Use MaxHighMemWorkers=1 to ensure that both cores aren't ever in stage 2 at the same time. If you find yourself accumulating a backlog of uncompleted stage 2 work, either take out this directive until your backlog is clear, or run a second instance of the client. What I do in practice is use the second instance method whenever I know I'm going to be away from the computer for a while. I don't touch the (already optimised) memory settings of the primary instance, but shut down the graphics subsystem (I have a Linux box; Windows users can't do this) to increase the free memory available for the second instance.

Provided both cores are getting an antiquate amount (finger-in-the-air guesstimate, about 300MB each), contention for memory space is not the major issue when running multiple stage 2s in parallel; contention for memory bandwidth is*. When I do the above, even without changing the primary instance's memory settings, I find it runs significantly slower. So I have another trick to reduce the need for parallel stage 2s: When running with just one core in stage 2, I run it at high priority. This works for me because I use my computer for other things that consume a fair amount of processing (mostly watching streaming TV), but not so much that the experience is degraded significantly by restricting these processes to just the one core. If your computer usage is different, this trick may be infeasible or ineffective.

*At least, this is true on my venerable Core 2 Duo box. This may or may not be an issue with other processor/chipset/memory setups.

[QUOTE=James Heinrich;153813]As an illustration, P-1 on 100,000,000-digit numbers (e.g. M332203901 that I'm working on) takes 838MB plus 163MB for each relative prime it processes in each batch). So, to process 10 relative primes you need >=2468MB available.

Fortunately, only crazy people like myself are working on P-1 this far up the available-work spectrum right now; by the time it's mainstream these hardware requirements will seem trivial :smile:[/QUOTE]

[QUOTE=James Heinrich;154297]After a couple more P-1 observations, it seems that you need approximately:
* FFTsize * 50 base memory, plus:
* FFTsize * 8 memory per relative prime processed

So (for examples) to process 20 relative primes you'd need, depending on the size of the exponent tested:[code]
* M 5,000,000 [256K FFT] = (0.25 * 50) + (0.25 * 8 * 20) = 53MB
* M 25,000,000 [1.5M FFT] = (1.5 * 50) + (1.5 * 8 * 20) = 315MB
* M 50,000,000 [ 3M FFT] = (3 * 50) + (3 * 8 * 20) = 630MB
* M100,000,000 [ 6M FFT] = (6 * 50) + (6 * 8 * 20) = 1260MB
* M333,000,000 [ 20M FFT] = (20 * 50) + (20 * 8 * 20) = 4200MB
* M500,000,000 [ 28M FFT] = (28 * 50) + (28 * 8 * 20) = 5880MB
[/code]I make no claim to the exactitude of these numbers, nor is there anything magical about processing 20 relative primes; I simply provide the above as a very rough guide to the approximate magnitude of RAM that is (or possibly should) be involved in P-1'ing a particular size of exponent.[/QUOTE]

So, what is the current upper limit for P-1 exponents, and corresponding RAM requirements? I think I stepped above it with an M667,xxx,xxx exponent (similar error for both Prime95 x64 version 26.5b5 and 26.6b3).

PFactor=xxxxxxxxxxx,1,2,667xxxxxx,-1,80,2

Win7-x64 Pro, i7-840QM, 16GB RAM, Prime95 x64 Version 26.6b3

[code]
[Main thread Jul 31 22:36] Mersenne number primality test program version 26.6
[Main thread Jul 31 22:36:55] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 256 KB, L3 cache size: 8 MB
[Main thread Jul 31 22:36:56] Logical CPUs 1,2 form one physical CPU.
[Main thread Jul 31 22:36:56] Logical CPUs 3,4 form one physical CPU.
[Main thread Jul 31 22:36:56] Logical CPUs 5,6 form one physical CPU.
[Main thread Jul 31 22:36:56] Logical CPUs 7,8 form one physical CPU.
[Main thread Jul 31 22:36:56] Using AffinityScramble2 settings to set affinity mask.
[Main thread Jul 31 22:36:56] Starting workers.

[Jul 31 22:36:56] Worker starting
[Jul 31 22:36:56] Setting affinity to run worker on logical CPU #1
[Jul 31 22:36:56] Optimal P-1 factoring of M667xxxxxx using up to 14336MB of memory.
[Jul 31 22:36:56] Assuming no factors below 2^80 and 2 primality tests saved if a factor is found.
[Jul 31 22:37:04] Optimal bounds are B1=6255000, B2=190777500
[Jul 31 22:37:04] Chance of finding a factor is an estimated 5.76%
[Jul 31 22:37:04] Cannot initialize FFT code, errcode=1002
[Jul 31 22:37:04] Worker stopped.
[/code]

[QUOTE=S34960zz;268146]So, what is the current upper limit for P-1 exponents, and corresponding RAM requirements? I think I stepped above it with an M667,xxx,xxx exponent[/QUOTE]You did. The upper limit is an exponent <596,000,000 which is the upper limit for 32MB FFT, which is the largest currently in Prime95 code. That means that [url=http://v5www.mersenne.org/report_exponent/?exp_lo=595999000&exp_hi=596000000]M595999993[/url] is the largest that can be P-1'd or L-L'd (or ECM, I suppose). Trial factoring is not constrained by this limit, and mfaktc (I'm not sure about Prime95) will do TF up to 2^2^32, but PrimeNet doesn't track any exponents above M999,999,999.

But if it hypothetically did work, it would look something like this:[quote]M667,000,000, factored to 80 bits, with B1=4,280,643 and B2=102,735,432
Probability = 5.000000%
Should take about 385.749074 GHz-days (using FFT size 36,672K)
Recommended RAM allocation: min=5,928MB; good=17,663MB; max=144,400MB; insane=707,674MB;[/quote]