with
GPUSieveSize=32


GPUSieveProcessSize=7
[code]
got assignment: F46 bit_min=96 bit_max=97
Starting trial factoring F46 from 2^96 to 2^97 (k range: 300000000000000 to 3250
00000000000)
k_min = 299999999999700
k_max = 325000000000000
Using GPU kernel "mfaktc_barrett108_F30_61gs"

found a valid checkpoint file!
last finished class was: 1081
found 0 factor(s) already

class | candidates | time | ETA | raw rate | SievePrimes | CPU wait
1083/4620 | 5.41G | 31.173s | 12h40m | 173.59M/s | 53 | n.a.%

1083/4620 | 5.41G | 11.912s | 4h51m | 454.27M/s | 50485 | n.a.%

1083/4620 | 5.41G | 11.487s | 4h41m | 471.08M/s | 99893 | n.a.%

1083/4620 | 5.41G | 11.324s | 4h37m | 477.86M/s | 150069 | n.a.%

1083/4620 | 5.41G | 11.277s | 4h36m | 479.85M/s | 200245 | n.a.%

1087/4620 | 5.41G | 11.249s | 4h35m | 481.04M/s | 250421 | n.a.%

1087/4620 | 5.41G | 11.267s | 4h35m | 480.27M/s | 300597 | n.a.%

1087/4620 | 5.41G | 11.240s | 4h35m | 481.43M/s | 349749 | n.a.%

1092/4620 | 5.41G | 11.320s | 4h36m | 478.03M/s | 399925 | n.a.%

1101/4620 | 5.41G | 11.554s | 4h41m | 468.35M/s | 500277 | n.a.%
[/code]

then
GPUSieveSize=128

[code]
1110/4620 | 5.41G | 11.158s | 4h31m | 484.97M/s | 250421 | n.a.%
[/code]

and lastly

GPUSieveProcessSize=14

[code]
1128/4620 | 5.41G | 6.927s | 2h47m | 781.16M/s | 250421 | n.a.%
[/code]

reducing GPUSieveSize to 16 lead to

1131/4620 | 5.41G | 7.023s | 2h49m | 760.32M/s | 250421 | n.a.%

After that , change of GPUSievePrimes provided no speed boost.

[QUOTE=c10ck3r;310802]Implausible thought of the day: by definition, any factor of MM43112609 would be a world record prime :P[/QUOTE]

To be pedantic, any factor of MM24036583 would suffice, or even factors of MM13466917 with k>1... :smile:

Luigi

sorry for the many edit of the avbove post. reserving FermatFactor=46,325e12,375e12

with the 'new speed' i think it will be good ;p

[QUOTE=firejuggler;310807]
and lastly

GPUSieveProcessSize=14[/QUOTE]


[SIZE="6"]ABORT!!![/SIZE]

I designed GPUSieveProcessSize to be a power of 2. I'm worried this setting is causes some factors to go untested.

I need to study the code and run some tests before anyone should try a GPUSieveSize or a GPUProcessSieveSize that is not a power of 2.

[QUOTE=Prime95;310819][SIZE="6"]ABORT!!![/SIZE]

I designed GPUSieveProcessSize to be a power of 2. I'm worried this setting is causes some factors to go untested.

I need to study the code and run some tests before anyone should try a GPUSieveSize or a GPUProcessSieveSize that is not a power of 2.[/QUOTE]

Can we continue if we use a power of 2?

[QUOTE=flashjh;310820]Can we continue if we use a power of 2?[/QUOTE]

Yeah, that's fine.

MMFF and fermatsearch.org
 

George, Luigi: here are some thoughts for the de facto restriction on MMFF use for Fermat factoring. Let's use F50 as an example.

1. MMFF with
[B]FermatFactor=50,150e12,300e12[/B]
is not strictly equivalent to a fermatsearch.org search with N=52. It is a search for a) odd k values with N=52 [U]plus[/U] b) a search for odd k values with N=53 (but with k in [75e12,150e12] [U]plus[/U] c) a search for odd k values with N=54 (but with k in [375e11,75e12], etc etc. All but the first case (a) will be [I]under[/I] the existing limits/reservations; i.e. they will be either wasted or sort of poaching/encroaching into other people's reservations.

2. MMFF with
[B]FermatFactor=50,150e12,300e12[/B]
will not check for k*2^52+1 being factors of F49, F48, F47 etc (could miss a result).

What do you think? Can these be written around? (I could probably hack into my local copy to use only odd k's for now, just to avoid issue #1. And I probably will.) Issue #2 makes the reservations with N=m+2 misleading and incompatible with the existing body of work on fermatsearch.org, it seems.

EDIT: link to existing limits - see region 52<=N<=64 (and higher); all ~1e14, 1.5e14 :
[URL]http://www.fermatsearch.org/stat/n.php[/URL]

[QUOTE=Batalov;310822]George, Luigi: here are some thoughts for the de facto restriction on MMFF use for Fermat factoring. Let's use F50 as an example....[/QUOTE]

It wasn't until today that I realized the N in the Fermat factoring reservations table *not* Fermat number N, but rather the power of two in the factor candidate.

I now see the theoretical reason why it is done this way -- a factoring candidate k*2^N+1might divide any of N-2 Fermat numbers and one powering test can discover this.

I can rework the Fermat kernels to work the way the previous Fermat programs worked. I'll talk to Luigi about this.

[SIZE="4"]For now, stick to double-Mersenne reservations.[/SIZE] Thanks for everyone's patience and understanding while we sort this out.

Need some help (I'm still learning). This is my assignment: MMFactor=127,179,2.5e15

How do I break this down so I can get faster results and fine tune the settings?

The mmff.ini file says this:

[CODE]Once you have an assignment, set worktodo.txt to a smaller range of k's so
# that you get relatively quick feedback. Then try various GPUSievePrimes values
# until you find the best setting, delete the *.ckp checkpoint file, and restore
# worktodo.txt to the full range of k's you've signed up for[/CODE]

Just need help doing that.

Thanks!

[QUOTE=flashjh;310833]Need some help (I'm still learning). This is my assignment: MMFactor=127,179,2.5e15

How do I break this down so I can get faster results and fine tune the settings?[/QUOTE]
An equivalent assignment, in terms of k, would be:
MMFactor=127,2251799813685249,2.5e15

You can do the translation yourself, but it's messy. (I think the k-values should be reported on your console when you start mmff using the assignment you quoted above. If you don't see it, try the -v2 option for more verboseness.) For Mersenne numbers, all factors are of the form f=2*k*p+1. In the case of this Double-Mersenne prime, p=2^127-1. The start of your range is f=2^179. So, you can calculate k=(f-1)/(2*p). The result of this calculation is k=2215799813685248.000000...0000001323. So, the last k-value in *my* range (2^178 to 2^179) is k=2215799813685248. The first k-value in *your* range is 2215799813685249.

If you go to the [URL="http://www.moregimps.it/doublemersennes/mm127.php"]reservations page[/URL], your 2^179 starting limit has been translated to a k-value of 2,251,799,813,681,880. (I would assume a minor rounding issue causes a tiny overlap into my range.)


To cut your range down to size, you might try:
MMFactor=127,2.4999e15,2.5e15

(Tweak the number of 9's in 2.4999 up or down to get prompt feedback, while still doing enough work to measure the effect of changes to GPUSievePrimes. Then, as the comments in the .ini suggest, tweak GPUSievePrimes up or down to maximize performance. Finally, discard your .ckp file, restore your proper range, and let it go. Based on my experience, I suggest you tune the h/o digit of GPUSievePrimes (800000 or 700000 or 900000). Then tune the second digit, to max out performance (810000 or 820000 or 830000). I don't think there's much practical value to tuning more accurately than two significant digits.)

Edit: If your starting k isn't precisely as I defined above, it appears mmff decreases the starting k to a multiple of 4620. Since k mod 4620 determines the class number, it makes sense that mmff is simply adjusting your range to start with an element of class number zero.

Thanks man!