mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > PrimeNet > GPU to 72

Reply
 
Thread Tools
Old 2017-01-16, 02:11   #1
mattmill30
 
Aug 2015

4610 Posts
Default SievePrimes is too big for the current assignment

I was curious as to whether testing M100069 and M106033 to ^72 would uncover any factors for these as yet completely unfactored exponents.

I started running M106033 TF ^66-^71 in stages on mfakto and I received the following message, but the test progresses: "SievePrimes is too big for the current assignment, lowering to 10108".

Why is 10108 the sieve maximum for this exponent?

Secondly, I can't run the test M106033 ^71-^72 on mfaktc with GPU sieving, because I receive the following error, even after making the recommended change: "GPU sieve requested but current settings don't allow exponents below 1055144. You can decrease the value of GPUSievePrimes in mfakto.ini to lower this limit". I note sieving on CPU removes the error.

Can someone explain the reason why reducing the GPUSievePrimes to below 100069 continues to display this error?

I'm aware people have said sieving to this range on small exponents is inefficient and ECM would be much more effective, but could someone clarify that it is a possibility that TF could find a factor at these levels for the exponents.

Finally, what is the bitlevel limit of the two exponents?
mattmill30 is offline   Reply With Quote
Old 2017-01-16, 03:24   #2
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

111038 Posts
Default

Both those numbers have had a t35 of ECM performed. ECM is probabilistic; when we say "t35 is done", there is a 1/e chance that a 35-digit factor was missed (if one exists). However, a t35 is roughly 6 * t30, so there's only a 1/(e^6) = 0.24% chance a 30-digit factor was missed (if one exists). 30 digits is roughly 100 bits, while 35 digits is around 116 bits.

TF won't find a factor below 95 bits, is very very unlikely to find one at 95-105 bits, and perhaps maybe could find one in 105-120 bits (say, 1/3 as likely as if no ECM had been done). I'd say that qualifies as "TF is hopeless". Note ECM is not hopeless; running curves at 3e6 isn't too resource-intensive.
VBCurtis is offline   Reply With Quote
Old 2017-01-16, 12:48   #3
mattmill30
 
Aug 2015

2×23 Posts
Default

Quote:
Originally Posted by VBCurtis View Post
Both those numbers have had a t35 of ECM performed. ECM is probabilistic; when we say "t35 is done", there is a 1/e chance that a 35-digit factor was missed (if one exists). However, a t35 is roughly 6 * t30, so there's only a 1/(e^6) = 0.24% chance a 30-digit factor was missed (if one exists). 30 digits is roughly 100 bits, while 35 digits is around 116 bits.
So how have you determined from the ECM records that T35 ECM has been completed?
mattmill30 is offline   Reply With Quote
Old 2017-01-16, 13:40   #4
axn
 
axn's Avatar
 
Jun 2003

23×607 Posts
Default

Quote:
Originally Posted by mattmill30 View Post
So how have you determined from the ECM records that T35 ECM has been completed?
Use http://www.mersenne.org/report_ecm/
axn is offline   Reply With Quote
Old 2017-01-17, 00:16   #5
mattmill30
 
Aug 2015

2×23 Posts
Default

I've read the simple explanation for ECM on the mersenne wiki, but I'm still not clear how ECM works.

But, looking at M106033 the majority of the 216 ECM results submitted were 3 curves within the same bounds, with one substantially greater result of 113 curves.

Why if all the ECM tests are of the same bounds with the same number of curves can it be said that the exponent has been thoroughly tested?

Does each ECM allocation include the number of previously completed curves to ensure each curve is different by using a incremental algorithm to select a different modulus?

How can PrimeNet be certain that every possible factor has been tested for an exponent, if a methodical bitlevel factorisation isn't performed?

Last fiddled with by mattmill30 on 2017-01-17 at 00:16 Reason: included "ECM simple explanation" link
mattmill30 is offline   Reply With Quote
Old 2017-01-17, 01:38   #6
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

52×11×17 Posts
Default

Quote:
Originally Posted by mattmill30 View Post
Does each ECM allocation include the number of previously completed curves to ensure each curve is different by using a incremental algorithm to select a different modulus?

How can PrimeNet be certain that every possible factor has been tested for an exponent, if a methodical bitlevel factorisation isn't performed?
1. No. The modulus is a ~64-bit number; ECM may run a few hundred thousand curves for a particularly stubborn number. What are the chances the same modulus is chosen? If it happens once or twice, how much work is wasted? Compare with the data demands of tracking that modulus for every single curve that's run, while that tracking is only useful if every invocation of ECM has the file on hand.

2. Why would PrimeNet care about certainty? That is, what exactly is it you think one should optimize for when looking for factors of known-composite mersenne numbers?
For each mersenne number, there's a bitlevel where ECM will find a factor faster than TF, if there is a factor to be found. ECM is probabilistic, so there is a known chance of a missed factor, but further ECM runs will eventually catch such a "miss" (that is, running curves useful for finding 40 or 45 digits factors will also find <35 digit factors, just not as quickly as running curves intended for 35 digit factors would). TF has a chance of missed factor too- false reports, GPU errors, bitflips, etc. ECM will find those possible TF misses, while pressing ahead on more TF won't.
VBCurtis is offline   Reply With Quote
Old 2017-01-17, 12:35   #7
mattmill30
 
Aug 2015

568 Posts
Default

For M106033, the report says the 50,000 bound required 280 curves, but the mersenne.ca report says only 21 curves were completed in this band.

Have I misinterpretted the meaning of 'curves to test' on report_ecm, against 'numcurves' on mersenne.ca?
mattmill30 is offline   Reply With Quote
Old 2017-01-17, 14:44   #8
thyw
 
Feb 2016
! North_America

2·3·13 Posts
Default

IIRC there were a post somewhere explaining something like "doing a curve with higher bounds will count (more) towards the lower ones by primenet"
Rephrase: So doing x curves with higher bounds will appear in the report_ecm as doing y (x<y) curves on lower bounds. To fill it up from the bottom.
It will "convert it" to the requied bound range count in the progress table. ^^Casual explaination.

Last fiddled with by thyw on 2017-01-17 at 14:48
thyw is offline   Reply With Quote
Old 2017-01-22, 00:37   #9
TheJudger
 
TheJudger's Avatar
 
"Oliver"
Mar 2005
Germany

11·101 Posts
Default

Quote:
Originally Posted by mattmill30 View Post
I started running M106033 TF ^66-^71 in stages on mfakto and I received the following message, but the test progresses: "SievePrimes is too big for the current assignment, lowering to 10108".

Why is 10108 the sieve maximum for this exponent?
Lazy developer?! (read below)

Quote:
Originally Posted by mattmill30 View Post
Secondly, I can't run the test M106033 ^71-^72 on mfaktc with GPU sieving, because I receive the following error, even after making the recommended change: "GPU sieve requested but current settings don't allow exponents below 1055144. You can decrease the value of GPUSievePrimes in mfakto.ini to lower this limit". I note sieving on CPU removes the error.

Can someone explain the reason why reducing the GPUSievePrimes to below 100069 continues to display this error?
Because it is the number of primes used for the sieve, not the value of the biggest prime number in the sieve.
Sieving with primes >= 2kp+1 would remove valid factor candidates from the list of factor candidates to test. Ofcourse this could be fixed but actually: who cares? I've choosen the simple approach for this case. TF on numbers that small is just a waste of time and energy.

Oliver
TheJudger is offline   Reply With Quote
Old 2017-01-27, 02:06   #10
mattmill30
 
Aug 2015

2×23 Posts
Default

Quote:
Originally Posted by TheJudger View Post
Lazy developer?! (read below)
Would you be able to advise why the following two 'backups' resulted in the following errors, and what could checksums could correctly be provided in order to progress the TFs?

M106033.ckp.bad-548CDAF8:
106033 67 68 4620 mfakto 0.15pre6-Win: 1815 0 C6551A27
returned
'Cannot use checkpoint file "M106033.ckp": Content "106033 67 68 4620 mfakto 0.15
pre6-Win: 1815 0 C6551A27
" does not match expected "106033 67 71 4620 ".
Renamed bad checkpoint file "M106033.ckp" to "M106033.ckp.bad-548CDAF8"'

M106033.ckp.bad-4C16797F:
106033 67 68 4620 mfakto 0.15pre6-Win: 1820 0 A098B6D2
returned
'Cannot use checkpoint file "M106033.ckp": Content "106033 67 68 4620 mfakto 0.15
pre6-Win: 1820 0 A098B6D2
" does not match expected "106033 67 71 4620 ".
Renamed bad checkpoint file "M106033.ckp" to "M106033.ckp.bad-4C16797F"'
mattmill30 is offline   Reply With Quote
Old 2017-01-27, 03:39   #11
VBCurtis
 
VBCurtis's Avatar
 
"Curtis"
Feb 2005
Riverside, CA

10010010000112 Posts
Default

Or, you could take the unsubtle hint that TF on exponents below 1M is a waste of time and energy. The program is untested below 1M, and not intended for use in that range.

You really should be doing ECM instead to find a factor for this number.
VBCurtis is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Mfaktc sieveprimes=5000 OK? NBtarheel_33 GPU Computing 34 2012-07-27 10:41
Current Effort R.D. Silverman Cunningham Tables 63 2009-04-28 17:18
Current status fivemack NFSNET Discussion 97 2009-04-17 22:50
Current status fivemack NFSNET Discussion 90 2006-11-13 13:37
Current Status moo LMH > 100M 0 2006-09-02 01:15

All times are UTC. The time now is 00:35.

Wed Mar 3 00:35:36 UTC 2021 up 89 days, 20:46, 0 users, load averages: 2.15, 2.43, 2.61

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.