GNFS targets which need more ECM
 

Here we'll collect potential GNFS targets which need some more ECM work. Usually ECM is stopped when the expected factor size is about 31% of GNFS difficulty.

Sean Wellman already suggested some candidates. There's a small table with work-to-do information (r means reserved):
[CODE] Composite | 300M |
-------------|--------|
C194_144_91 | done | fivemack 07-Jan-2017; 23040 completed 24-Jan-2017, no factor
C195_130_121 | r/25k |
C195_148_83 | r/25k | fivemack 01-Feb-2017; 25600 completed 25-Feb-2017, no factor
C196_135_124 | r/30k | fivemack 20-Mar-2017; 30720 completed 07-Apr-2017, no factor
C196_146_83 | 0/30k |
C197_149_70 | 0/35k |
C198_143_115 | 0/40k |
C198_143_98 | 0/40k |[/CODE]
As soon as ECM is done on some target, it will be moved to the [url=http://www.mersenneforum.org/showthread.php?t=19353]nearby thread[/url].

There are also some larger targets: [url]http://www.mersenneforum.org/showpost.php?p=438053&postcount=66[/url]

Any ECM help will be greatly appreciated :-)

I will throw 18000@110e6 at C177_127_126

C182_147_125 will go to NFSNET without any 850M?

I believe yoyo@home did a t60 on C182_147_125, though I can no longer find it in the logs. In any case I'm happy to go to GNFS.

From the XY queue.
[CODE]DONE(1431617275) C182_147_125 42000 260000000 12093067009074704252675846002984141121780806423978283707584938383776570609066866061171700718946230640458535178724274435114415218181957483177454610233405802361841498168902737677281291[/CODE]

I'll run ECM on C173_146_90 for 18k curves @B1=110.

Factor 23172365109205234480749903714762635294556007388744597227 found for C177_127_126

Running some@110e6 on C175_131_96

[url=http://www.factordb.com/index.php?id=1000000000044709170]C173_146_90 is fully factored[/url]

prp53 = 47267995382581897196022456493523794792603190460855617
curve 689 stg2
B1=110000000
sigma=1435980417

C190_149_91
 

I will run ECM on this number for 18000 curves. Thanks.

[CODE] Composite | 110M | 260M | 850M |
C175_131_96 | 0/18k | 0/30k | |
C190_149_91 | 0/18k | 0/42k | 0/60k |
[/CODE]

I am a bit unsure about your calibration for these numbers.

On the hardware here, sieving C175_131_96 using a polynomial that results from only two hours of polynomial search would take about 300M relations to be gathered in about 42 million thread-seconds, whilst one curve at 110M takes 943 seconds and at 260M takes about 2200 seconds; 30k curves at 260M would be a lot longer than the sieving!

For C190_149_91, one curve at 850M is 6200 seconds, and 500M relations with a quickly-sought polynomial is about 650 million seconds, so the proposed ECM would take something like 75% as long as the sieving; still a bit much. Maybe 20k@850M rather than 60k to get the ECM time in case of failure down to a third of the sieving time.

I overestimated the sieving time. Now it looks better probably.

C190_149_91 survived 18000 curves @B1=110M with no factors found. Releasing number.

Throwing 20000@1e8 at C177_148_94

I'll take C188_140_113 up to t55. Thanks.

Added C188_149_78 to the table.

[QUOTE=fivemack;411577]Throwing 20000@1e8 at C177_148_94[/QUOTE][QUOTE=swellman;411636]I'll take C188_140_113 up to t55. Thanks.[/QUOTE]Marked them as done, right?

[QUOTE=XYYXF;413860]Added C188_149_78 to the table.
[/quote]

Thanks. I've identified 14 other likely GNFS candidates. I'll post them another day.

[quote]
Marked them as done, right?[/QUOTE]

No, still running ECM on C188_140_113. t55 strains my resources (and truth be told, my patience at times) but it is cranking away.

Anyway, there's still work to do at 260M before sieving, so there's no much confusion in the "done" mark. Take it this way: the distribution of the t55 task is done :-)

Hope a factor will fall out soon.

Supplemental list of GNFS candidates
 

Based on comments made by [URL="http://www.mersenneforum.org/showpost.php?p=407837&postcount=151"]fivemack[/URL] and others, I have identified the following possible additional GNFS candidates using test sieving:


C173_145_56
C173_139_59
C174_136_69
C174_136_75
C175_128_97
C177_132_91*
C178_133_71
C178_131_81*
C179_136_87
C181_147_62
C181_133_103
C181_130_109
C183_144_73
C184_135_106
C188_149_78 (t55 done)

*Difference between GNFS and SNFS sieving times is marginal. Needs more detailed GNFS test sieving.


Since I don't have a GPU rig, the estimated GNFS sieving times were based on extrapolation of previous work, i.e. sieving time doubling every 5 digits in length. However the estimates for GNFS for most of these ended up being 1/5-1/2 of the time for SNFS (with the two noted exceptions).

I could not find any other likely GNFS candidates. A graph of some SNFS ETAs is attached. Very noisy indeed.

C173_145_56 still needs t50.

[QUOTE=XYYXF;414111]C173_145_56 still needs t50.[/QUOTE]

No, I reported running it to t50 [URL="http://www.mersenneforum.org/showpost.php?p=394244&postcount=105"]here[/URL].

Of course all but one need t55 or more!

Oops, my fault. Thanks for pointing out :-)

I've done 64 Xeon core-days of polynomial selection on C185_142_141; just doing the post-processing to find the one that sieves best.

I'll take C184_135_106 for ECM to t55.

Based on [url=http://www.mersenneforum.org/showpost.php?p=425451&postcount=373]recent comments by Fivemack[/url], it seems we could have a few potential C18X GNFS candidates for the 15e queue of NFS@Home. Can anyone here run ECM to the required levels in the OP prior to attempting GNFS? Or is this something for yoyo?

Even individuals running some curves at the t55 level will be very helpful.

I think yoyo would definitely help with t60.

Additional GNFS Numbers
 

Further test sieving has identified the following list of GNFS candidates:

C193_136_129
C193_143_93
C196_135_124
C193_131_124
C185_134_99
C190_147_80
C194_144_91
C197_141_86
C183_127_118
C188_132_125
C195_130_121
C186_145_72
C191_143_75
C192_139_81
C182_125_121
C191_143_76
C183_134_69
C187_142_59

For all of these, test sieving by SNFS is considerably slower than the [I]estimated[/I] GNFS sieving time. All have been run up to the t50 level for ECM.

Thank you Sean.

[QUOTE=swellman;427073]For all of these, test sieving by SNFS is considerably slower than the [I]estimated[/I] GNFS sieving time.[/QUOTE]How about C177_132_91 and C178_131_81? Are they definitely GNFS targets?

[QUOTE=XYYXF;427129]Thank you Sean.

How about C177_132_91 and C178_131_81? Are they definitely GNFS targets?[/QUOTE]

I'm not sure. We need to generate a good poly and run some test sieving comparing S/GNFS. And that is not worth doing until all ECM is run.

Personally, I hope ECM factors both of them!

ETA: When do you plan to push the five numbers that have survived t55 over to yoyo for higher ECM? Just curious.

Currently 15e is loaded enough, maybe a bit later :)

I am about to have spare GPU resource to do 10k@6e8 on some number (this will take all of March).

Which number should I pick? Current thought is either C190_149_91 or C193_136_129, which are the numbers of that digit count with highest SNFS:GNFS difficulty ratio.

[QUOTE=fivemack;427575]I am about to have spare GPU resource to do 10k@6e8 on some number (this will take all of March).

Which number should I pick? Current thought is either C190_149_91 or C193_136_129, which are the numbers of that digit count with highest SNFS:GNFS difficulty ratio.[/QUOTE]

Bump. Not sure XYYXF has seen this posting.

If this were a poll (which it is not), I would go with C190_149_91. It has already seen t55 and is ready for the big stuff.

I'd also prefer C190.

OK, 416*25 curves started on C190_149_91

[QUOTE=swellman;425659]I'll take C184_135_106 for ECM to t55.

[/QUOTE]

Completed 18000 curves @B1 = 11e7 with no factors found. Releasing number.

10400 stage-1 curves run on C190_149_91, 84% of them taken to stage 2, found a P55 but it turns out that it had already been submitted :bob:

C177_148_94 was suggested as GNFS, but its SNFS difficulty is not too high:

Difficulty 248: 4879681*(47[sup]24[/sup])[sup]6[/sup] + 29986576*(2[sup]6[/sup]*37[sup]15[/sup])[sup]6[/sup] = 58008018918812545143463727211454278525294078099759247887923759309261425 * C177

Difficulty 254: 1369*(47[sup]25[/sup])[sup]6[/sup] + 35344*(2[sup]6[/sup]*37[sup]16[/sup])[sup]6[/sup] = 175423268180778312831796670198430324228190852757122036482075886926082969832425 * C177

C177_148_94 is on the list of possible GNFS candidates because the best SNFS poly I could find using Yafu would take an estimated 247M core-seconds to sieve versus ~85M core-seconds using GNFS. If my estimates are off then perhaps GNFS is not the best path forward.

Can anybody provide a quick and dirty GNFS poly we can test with?

Using an ECM rule of thumb of 0.31*GNFS gives ~t55, which this number has already survived. The 5000 curves @B1=26e7 listed in this thread may be unnecessary though certainly prudent (for peace of mind if nothing else).

Best SNFS poly I found follows:

[code]
n: 509324937687618809222445320276337252810119679947032399409215533120195327608346172383916906170272967333837017570484086026229163006167878198943819573285050609840596958297287281873
# 148^94+94^148, difficulty: 248.37, anorm: 3.92e+033, rnorm: -1.41e+055
# scaled difficulty: 251.97, suggest sieving rational side
# size = 1.438e-017, alpha = 0.000, combined = 7.015e-014, rroots = 1
type: snfs
size: 248
skew: 20.7443
c5: 1
c0: 3841451
Y1: -3096263264537031876137686856267255616967297523567
Y0: 159982589693655584703558945119488
rlim: 57000000
alim: 57000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]

The sextic SNFS polynomial produced by snfspoly has hideous coefficients, yeah... but a quintic of that SNFS difficulty is no piece of cake either.

[QUOTE=swellman;430943]

[code]
n: 509324937687618809222445320276337252810119679947032399409215533120195327608346172383916906170272967333837017570484086026229163006167878198943819573285050609840596958297287281873
# 148^94+94^148, difficulty: 248.37, anorm: 3.92e+033, rnorm: -1.41e+055
# scaled difficulty: 251.97, suggest sieving rational side
# size = 1.438e-017, alpha = 0.000, combined = 7.015e-014, rroots = 1
type: snfs
size: 248
skew: 20.7443
c5: 1
c0: 3841451
Y1: -3096263264537031876137686856267255616967297523567
Y0: 159982589693655584703558945119488
rlim: 57000000
alim: 57000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code][/QUOTE]

Was this the winner of the automated test sieving in yafu? For numbers of this size it is probably worthwhile to do more test sieving, especially if the sextics were close performance-wise. Chunks of 2 to 5k special-q in several locations throughout the estimated sieve region.

[QUOTE=bsquared;430976]Was this the winner of the automated test sieving in yafu? For numbers of this size it is probably worthwhile to do more test sieving, especially if the sextics were close performance-wise. Chunks of 2 to 5k special-q in several locations throughout the estimated sieve region.[/QUOTE]

It is the optimal Yafu answer. I've done several hundred of these, and the decision on whether a Yafu generated poly is optimal is usually an obvious yes/no or "it doesn't matter", meaning two polys are so close in performance that even if the ultimate winner turns out to be slightly suboptimal it's so close to the optimal solution that the total sieving time difference is near negligible. Just my opinion of course.

I have found a lot of scatter when plotting sieving times vs SNFS difficulty - hardly surprising - and this particular case is especially hideous as Lionel notes. It's just a case where the ugly SNFS poly can likely be beat by a decent GNFS poly.

That said, of course we can use SNFS to factor this number. My list is hardly authoritative - it's just a set of candidates that are [i]likely[/i] best solved via GNFS.

[QUOTE=swellman;430979]It is the optimal Yafu answer. I've done several hundred of these, and the decision on whether a Yafu generated poly is optimal is usually an obvious yes/no or "it doesn't matter", meaning two polys are so close in performance that even if the ultimate winner turns out to be slightly suboptimal it's so close to the optimal solution that the total sieving time difference is near negligible. Just my opinion of course.
[/QUOTE]

You've used it a lot more than I have :smile:. Just pointing out that if two polynomials are "nearly the same", then the differences are magnified when applied to very large sieving tasks. You're right that the better question in this case is probably SNFS vs. GNFS.

I'll let a GPU run a few hours to get an "in the vicinity" poly for your comparison task this evening. We can estimate the improvement for a full poly-search using the estimated-good poly score that msieve produces in case the test is inconclusive.

Agreed. Before embarking on a big factoring job, one should definitely perform extensive test sieving. 1% difference in performance is negligible when it's a 1000 hour job, not so much when it's 200000 hours.

So back to an earlier question - does anyone have a quick and dirty GNFS poly so we can decide a path forward?

ETA: thanks VBCurtis!

2 GPU-hr produced this:
[code]N 509324937687618809222445320276337252810119679947032399409215533120195327608346172383916906170272967333837017570484086026229163006167878198943819573285050609840596958297287281873
SKEW 44744195.26
R0 -15372279160491459270723477022022637
R1 42075573946251179
A0 -28036751366398061170413492158368626575647616
A1 2446095126548667802453043510317136360
A2 132445682988042341783594025606
A3 -4958312126359633450937
A4 102677914180448
A5 593340
skew 44744195.26, size 2.117e-17, alpha -7.554, combined = 1.104e-13 rroots = 3[/code]
Msieve says target score is 1.22e-13, but this poly exceeds the previous best found for a c178 on the forum, so it's at least decent. I'd guess 7-10% improvement for a full search.

I ran some test sieving using a Win64 box with an i5-3340M processor. Results follow, but GNFS is the clear winner.

poly siever lpbr/a a/r ETA (wks) yield a/rlim (M) spec_Q0 (M) spec_Q range
gnfs 15e 31 a 55 1.70 120 40 4000
gnfs 14e 31 a 61 0.78 120 40 4000
gnfs 15e 31 a 56 1.58 150 50 4000
gnfs 14e 31 a 65 0.74 150 50 4000
snfs 15e 31 r 108 1.32 57 28.5 4000
snfs 14e 31 r 83 0.58 57 28.5 4000
snfs 14e 31 r 82 0.58 57 28.5 10000
gnfs 15e 31 a 49 1.68 150 50 10000

Do we need to run more ECM (5000 curves @B1=26e7) prior to starting GNFS?

[QUOTE=swellman;431043]I ran some test sieving using a Win64 box with an i5-3340M processor. Results follow, but GNFS is the clear winner.

gnfs 15e 31 a 49 1.68 150 50 10000

Do we need to run more ECM (5000 curves @B1=26e7) prior to starting GNFS?[/QUOTE]

Could you try another test-sieve with these parameters but 32-bit LP? Even if NFS@home will run it as 31, I'd like to know how much time 32 would save.

A t55 should be plenty of ECM for this number. I'm still running the C195 from the poly request thread, so I won't be able to improve this poly for another week or so.

[QUOTE=VBCurtis;431044]Could you try another test-sieve with these parameters but 32-bit LP? Even if NFS@home will run it as 31, I'd like to know how much time 32 would save.[/quote]

Done.

gnfs 15e 32 a 66 3.16 150 50 10000

[quote]A t55 should be plenty of ECM for this number. I'm still running the C195 from the poly request thread, so I won't be able to improve this poly for another week or so.[/QUOTE]

Ok.

Let's strew some 110M curves on C177_132_91 and C178_131_81. Once they survive, test sieving will clear up their status (GNFS/SNFS).
[code]// C178_131_81
9665594746635471193631401610305223441026454871232104654184978793903680411628939306459447967671907712555259632196378072766508008145078274293025707034749562219382254626268701104791

// C177_132_91
155559677364893070934785846580006701224317170617385105940830204750196640320067857569016305699618930674035553847614928335155387093050358174227213931437141745113915559030979450653[/code]

[QUOTE=XYYXF;432413]Let's strew some 110M curves on C177_132_91 and C178_131_81. Once they survive, test sieving will clear up their status (GNFS/SNFS).
[code]// C178_131_81
9665594746635471193631401610305223441026454871232104654184978793903680411628939306459447967671907712555259632196378072766508008145078274293025707034749562219382254626268701104791

// C177_132_91
155559677364893070934785846580006701224317170617385105940830204750196640320067857569016305699618930674035553847614928335155387093050358174227213931437141745113915559030979450653[/code][/QUOTE]

Bump. I can help with these in a couple of weeks but a group ECM effort would speed things up.

I'll do the 18k curves on C173_139_59.

I will start towards a full t55 on C177_132_91. It will take awhile.

[QUOTE=swellman;432829]I will start towards a full t55 on C177_132_91. It will take awhile.[/QUOTE]

Fully factored by ECM

[code]
p60 = 142605715251108746997064499457693518817992625513392698520987

B1=11e7
B2=gmp-ecm default
Sigma=2405137795
[/code]

Reserving C178_131_81 for ECM to t55.

Reserving the following for ECM to t55:

C178_133_71
C187_142_59
C173_145_56

Thanks.

C173_139_59 withstood 18k+ curves at 110M.

C178_131_81 and C178_133_71 both survived 18000 curves @B1=11e7 with no factors found.

C173_145_56 survived 12000 curves @B1=11e7, now Fivemack is factoring it. Please transfer the reservation to him.

C187_142_59 is still under ECM towards t55. Estimate ~2 weeks to finish it.

Thank you.

Now it's time to find a good poly for C178_131_81 to ensure that it's not an SNFS target :)

I've started working on C174_136_69 at B1=110e6.

[QUOTE=XYYXF;437092]Now it's time to find a good poly for C178_131_81 to ensure that it's not an SNFS target :)[/QUOTE]

Should 10k curves @B1=26e7 be run first? Same thing with C178_133_71? Maybe yoyo will negate the need for poly searching. One can hope.

The chance to find a factor is small. But who knows, indeed...

I intend to run 20384 or so curves at B1=3e8 on C184_146_89

[QUOTE=swellman;437273]Should 10k curves @B1=26e7 be run first? Same thing with C178_133_71? Maybe yoyo will negate the need for poly searching. One can hope.[/QUOTE]

C178_133_71 will take less than three CPU-years to sieve.

A quick Bayesian analysis using a uniform prior and the approximations, good for N>=45, of

P(success at N digits for one 11e7 curve) = 16139*exp(-0.356N)
P(success at N digits for one 26e7 curve) = 9669*exp(-0.331N)

says that the probability of success for 10k curves at 26e7 after 18k curves at 11e7 is 7.5%, so it's worth spending 2000 hours but no more.

(in fact, this argument leads to one that it is only worth spending *any* curves at 26e7 after 18k curves at 11e7 if the GNFS takes longer than running 90,000 curves at 26e7, i.e. 45k hours or about 180 digits)

(likewise that it's only worth running any curves at 11e7 after 8000@43e6 if the GNFS takes longer than running 50,000 curves at 11e7, i.e. 12k hours or 172 digits)

I'm well aware that RDS has been talking about Bayesian analyses for years, but I was stalled because I thought it was necessary to use exact success probabilities: but the exponentials fit so well that I am reasonably happy with this vastly easier approach.

[QUOTE=XYYXF;437092]Now it's time to find a good poly for C178_131_81 to ensure that it's not an SNFS target :)[/QUOTE]

Noticed your request for GNFS polys over in the msieve forum. I've got the optimal SNFS poly and will run a comparison test sieve once msieve generates a poly.

I've started working on C174_136_75 at B1=110e6. The Stage 1 curves from C174_136_69 have been sent to Sean to carry out Stage 2.

[QUOTE=fivemack;437482]I intend to run 20384 or so curves at B1=3e8 on C184_146_89[/QUOTE]

Fairly quickly found a P52, I've mentioned it on the ECM thread.

Looking at C182_136_109 next; if I believe my new implementation of how-much-ECM then it needs about 5000 curves at B1=3e8, which will take about a week, before being ready for polynomial selection. I am running these.

At the risk of smothering the GNFS efforts currently underway, I am proposing seven more candidates for the OP.

C195_148_83
C196_143_111
C196_146_83
C197_149_70
C198_143_115
C198_143_98
C200_139_113

All appear to be GNFS per test sieving and the methodology discussed previously.

These are not the only GNFS candidates I've identified, but I used an arbitrary cutoff of C200. There are 20 more composites so far that are very slow in SNFS and would seem better suited to GNFS. Size range is C201 to a breathtaking C230. 😳 I am not sure if there are clear lines of demarcation between hard to sieve, really hard and forget it but my list definitely strays into "here be dragons" territory.

Dragons
 

Here is the remainder of my list. Not sure which (if any) are practical GNFS targets.

C201_137_134
C202_147_116
C203_145_119
C203_146_107
C203_147_104
C203_137_127
C203_142_87
C204_147_118
C206_139_123
C207_143_127
C208_145_99
C211_137_135
C213_147_128
C213_141_113
C214_143_135
C214_143_119
C218_142_133
C222_149_141
C228_145_141
C230_149_136

[QUOTE=swellman;437069]
C187_142_59 is still under ECM towards t55. Estimate ~2 weeks to finish it.
[/QUOTE]

Completed 18000+ curves @B1=11e7 on ver 6 of GMP-ECM with no factors found. I guess it's ready for yoyo etc.

I have a shiny new GTX1080 on the table downstairs, which ought to be quite good at GPU-ECM. May I reserve C200_139_113 ?

My ecm-toy tool suggests (on the assumption that it's already had 7610@43e6) a recipe of 5700@43e6 then 1400@110e6 then 34200@260e6 then 2500@850e6 - though my tool does not know about GPUs so may have a different recipe once I've done some timings on the GTX1080.

[QUOTE=wombatman;437794]I've started working on C174_136_75 at B1=110e6. The Stage 1 curves from C174_136_69 have been sent to Sean to carry out Stage 2.[/QUOTE]

C174_136_75 has been fully factored in Stage 2 using Ben's Stage 1 results..

[code]
Using B1=110000000-110000000, B2=776278396540, polynomial Dickson(30), sigma=3:2930077740
Step 1 took 0ms
Step 2 took 189135ms
********** Factor found in step 2: 49944378186590670787707675987630380113819949603
Found probable prime factor of 47 digits: 49944378186590670787707675987630380113819949603
Probable prime cofactor ((75^136+136^75)/7367054022024847648487749442785036214607516444205627891167308884527791057041545443)/49944378186590670787707675987630380113819949603 has 127 digits
[/code]

Found this factor in less than a day, thanks to Ben's heavy lifting, All credit goes to him!

I am still working Stage 2 of C174_136_69.

Reserving C197_141_86
 

I am going to ECM C197_141_86 to t55. Thanks.

Reserving C175_128_97
 

I'll get started on the 18k curves needed at B1=110e6.

[QUOTE=swellman;438116]C174_136_75 has been fully factored in Stage 2 using Ben's Stage 1 results..

[code]
Using B1=110000000-110000000, B2=776278396540, polynomial Dickson(30), sigma=3:2930077740
Step 1 took 0ms
Step 2 took 189135ms
********** Factor found in step 2: 49944378186590670787707675987630380113819949603
Found probable prime factor of 47 digits: 49944378186590670787707675987630380113819949603
Probable prime cofactor ((75^136+136^75)/7367054022024847648487749442785036214607516444205627891167308884527791057041545443)/49944378186590670787707675987630380113819949603 has 127 digits
[/code]

Found this factor in less than a day, thanks to Ben's heavy lifting, All credit goes to him!

I am still working Stage 2 of C174_136_69.[/QUOTE]

Sweet! Always good to get confirmation that my GPU curves are coming out properly. :smile:

4992 curves completed at B1=3e8 B2=3178599824416 on 136_109, no factor.

Will do polynomial selection once C254_125_111 has had 4992 curves at 3e8

C185_134_99
 

Ryan is running GNFS on C185_134_99.

[QUOTE=swellman;438399]Ryan is running GNFS on C185_134_99.[/QUOTE]


[url=http://factordb.com/index.php?id=1000000000044718158]Ryan solved this in 3 days using GNFS. p70*p115[/url]

[QUOTE=wombatman;438318]Sweet! Always good to get confirmation that my GPU curves are coming out properly. :smile:[/QUOTE]

Yes it was sweet. And WraithX's [url=http://www.mersenneforum.org/showpost.php?p=437855&postcount=92]Python driver for GMP-ECM[/url] made it easy to run.

Just email me the next file whenever Stage 1 is done. I may lag you a bit but I'll (eventually) run Stage 2 on anything you send me. This includes any unreserved GNFS and even the [url=http://www.mersenneforum.org/showthread.php?t=21243]SNFS numbers needing more ECM thread[/url], if that interests you. Thanks.

Preparing Stage 1 curves on C179_136_87 at B1=110e6.

Stage 2 of C174_136_69 completed for all 18,000 curves with no factors found.

[QUOTE=fivemack;438065]I have a shiny new GTX1080 on the table downstairs, which ought to be quite good at GPU-ECM. May I reserve C200_139_113 ?

My ecm-toy tool suggests (on the assumption that it's already had 7610@43e6) a recipe of 5700@43e6 then 1400@110e6 then 34200@260e6 then 2500@850e6 - though my tool does not know about GPUs so may have a different recipe once I've done some timings on the GTX1080.[/QUOTE]

Not sure if Andrey saw this, but bumping it in case fivemack still wants to work on C200_139_113.

It did previously survive 7600 curves @B1=43e6.

[QUOTE=swellman;438053]Here is the remainder of my list. Not sure which (if any) are practical GNFS targets.

[code]
C201_137_134
C202_147_116
C203_145_119
C203_146_107
C203_147_104
C203_137_127
C203_142_87
C204_147_118
C206_139_123
C207_143_127
C208_145_99
C211_137_135
C213_147_128
C213_141_113
C214_143_135
C214_143_119
C218_142_133
C222_149_141
C228_145_141
C230_149_136
[/code]
[/QUOTE]

Where should we draw the line on GNFS? I believe the 16e siever of NFS@Home has handled upwards of 220 digits but that's a huge undertaking that Greg may not want to entertain.

Is 208 inclusive a feasible value? I really have no idea.

Ryan is reserving C182_125_121.

[QUOTE=swellman;438863]Ryan is reserving C182_125_121.[/QUOTE]

Factored by ECM. [url=http://factordb.com/index.php?id=1000000000044740149]p59*p123[/url]

[code]
Input number is
19638514892326880715049637947667358096563021648596014807027282348855860502922717331324961311298405146927437844559477346581035562867109341355691061338230447718948577630638933884125463
(182 digits)
Using MODMULN [mulredc:0, sqrredc:1]
Using B1=850000000, B2=15892628251516, polynomial Dickson(30), sigma=4292114945
dF=524288, k=5, d=5705700, d2=17, i0=132
Expected number of curves to find a factor of n digits:
35 40 45 50 55 60 65 70 75 80
15 47 168 661 2867 13623 69471 381778 2221086 1.4e+07
Step 1 took 5118300ms
Using 22 small primes for NTT
Estimated memory usage: 2153M
Initializing tables of differences for F took 6930ms
Computing roots of F took 87963ms
Building F from its roots took 42180ms
Computing 1/F took 15769ms
Initializing table of differences for G took 565ms
Computing roots of G took 68832ms
Building G from its roots took 43427ms
Computing roots of G took 68996ms
Building G from its roots took 44366ms
Computing G * H took 8462ms
Reducing G * H mod F took 8758ms
Computing roots of G took 72232ms
Building G from its roots took 45154ms
Computing G * H took 8519ms
Reducing G * H mod F took 8729ms
Computing roots of G took 72215ms
Building G from its roots took 46696ms
Computing G * H took 9187ms
Reducing G * H mod F took 9270ms
Computing roots of G took 76390ms
Building G from its roots took 44273ms
Computing G * H took 8164ms
Reducing G * H mod F took 8647ms
Computing polyeval(F,G) took 77520ms
Computing product of all F(g_i) took 330ms
Step 2 took 886306ms
[/code]

Carrying out 18k Stage 1 curves on C183_127_118.

C175_128_97 Factored
 

[QUOTE=wombatman;438317]I'll get started on the 18k curves needed at B1=110e6.[/QUOTE]

Factor found:

[code]
11:25:53 UTC Using B1=110000000-110000000, B2=776278396540, polynomial Dickson(30), sigma=3:2314982299
Sat 2016/07/30 11:25:53 UTC Step 1 took 0ms
Sat 2016/07/30 11:25:53 UTC Step 2 took 408988ms
Sat 2016/07/30 11:25:53 UTC ********** Factor found in step 2: 18741935848981531171662457713083107476972826270465020497
Sat 2016/07/30 11:25:53 UTC Found prime factor of 56 digits: 18741935848981531171662457713083107476972826270465020497
Sat 2016/07/30 11:25:53 UTC Prime cofactor ((97^128+128^97)/32654503840898125243550881908880946943525344683424710216799046973981058120030697)/18741935848981531171662457713083107476972826270465020497 has 120 digits
[/code]

Thanks Ben! I'm starting Stage 2 on C179_136_87.

C179_136_87 Factored
 

[QUOTE=wombatman;438518]Preparing Stage 1 curves on C179_136_87 at B1=110e6.[/QUOTE]

Another hit!

[code]
Using B1=110000000-110000000, B2=776278396540, polynomial Dickson(30), sigma=3:4188775375
Tue 2016/08/02 07:49:28 UTC Step 1 took 0ms
Tue 2016/08/02 07:49:28 UTC Step 2 took 414089ms
Tue 2016/08/02 07:49:28 UTC ********** Factor found in step 2: 563655256452453087659366036867672874699806549622983
Tue 2016/08/02 07:49:28 UTC Found prime factor of 51 digits: 563655256452453087659366036867672874699806549622983
Tue 2016/08/02 07:49:28 UTC Prime cofactor ((87^136+136^87)/17772265331222093600920463956534435557326871232293582567248130632028948864220420721011)/563655256452453087659366036867672874699806549622983 has 128 digits
[/code]

Reserving C183_138_97 for Stage 1 work which will be sent on to Sean for Stage 2.

C179_148_87
 

C179_148_87 is a composite cofactor (stub) from a yoyo ECM effort on C223_148_87. See [url]http://factordb.com/index.php?id=1000000000044706172[/url].

After ECM to t55, it should be a straightforward GNFS.

Ben - shall we enqueue this number for our Stage 1-2 process?

Sure. I can throw that one on next. Does it just need the t55?

I have started 12800@3e8 on C200_139_113 which should take about two weeks (it's running on half a GTX1080, the other half of which is doing cudalucas - the GTX1080 is really a very fast device, flat-out it's about equivalent to 8 cores Xeon Haswell at cudalucas). I think it deserves 38400@3e8 before going to polynomial selection.

I've decreased the amount of ECM in the work-to-do table: [url]http://www.mersenneforum.org/showpost.php?p=404530&postcount=1[/url]

C179_148_87
 

[QUOTE=wombatman;439816]Sure. I can throw that one on next. Does it just need the t55?[/QUOTE]

Yes t55 should be enough. Thanks for queuing it.

[QUOTE=wombatman;438963]Carrying out 18k Stage 1 curves on C183_127_118.[/QUOTE]

Stage 2 run for full t55 with no factors found. Guess it's ready for yoyo@Home?

Either way, releasing number.

C183_138_97 and C179_148_87
 

I'm currently running Stage 2 of t55 for C183_138_97 and C179_148_87. Results expected before the end of the month.

Just to change it up a bit, reserving C200_139_113 for Stage 1 curves. Will do 18k at B1 = 110M. :smile:

[QUOTE=wombatman;440165]Just to change it up a bit, reserving C200_139_113 for Stage 1 curves. Will do 18k at B1 = 110M. :smile:[/QUOTE]

[url=http://www.mersenneforum.org/showpost.php?p=439822&postcount=89]Cough cough[/url]😎

Knew I should have searched the thread first. Whoops. :davieddy:

Will instead work on C183_144_73. I searched the thread and no claims came up, so hopefully this one will be alright! :smile:

Reserving C184_134_119 for 18k curves at B1=110M.