There's no point in posting the C185 poly, since the composite has been cracked by ECM (a super lucky P64!! B1=15e7).
Here's the C186 poly:
[code]n: 125418306344861354009234099530308115054784168571883448806721469548914177231420519441798023737607334329713323208573857202696013549660750242809155498156388725322000613487876897998654482601
# norm 4.533796e-18 alpha -7.809465 e 3.924e-14 rroots 3
skew: 130330238.00
c0: 8339214993797526944993529885793799309294890700
c1: -63561529637263770761265457071882653685
c2: -2951388700503543950513260732195
c3: -1957472655093592217376
c4: 77952353155253
c5: 550788
Y0: -743832744056353011728142095392992537
Y1: 100213462976318491[/code]
Edit: -npr was still running when I posted about the 3.86. Seems it wasn't the best of the run! Two good polys suggest more may be in store; when a single poly is 10% better than all the others and the previous record, I'm more inclined to think it's the magic outlier.

C186
 

I can't spin the above poly, sorry. But I'd love to see all your results above 3.4e-14, some of them might jump above 4e-14. If you still have the .m or .ms file, I'll process all the suspects today, promise.

C205 testing:
[QUOTE=VBCurtis;488469]Nice work, Max!
I'll test-sieve a few of these sometime this week; if the 2.2 sieves well, I think we have a winner. Once I have some stats on estimated Q-ranges, we can query fivemack and/or frmky to determine if this should be placed on 16e or 15e queue. This would be a record for GGNFS 15e, but such a record comes with a matrix more difficult than it would be on 16e.

On the GPU search, I'll complete 20M-36M by 1 June.[/QUOTE]

I finally got around to test-sieving on 15e. The results were... impressive (in the "oh, we're not worthy" way). I tested three polys, of scores 2.210, 2.215, and 2.214 (the latter two were brothers, and sieved nearly identically).
The 2.210 had the best yield:
[code]15e test, sieved -a side; bounds listed r first
alim=268M, rlim=536M 33-33/66-96, lambda = 2.7/3.9:
poly c: 2.210e-15, dQ=500, skew 230M
Q=50M 0.847 sec/rel, 418 rels
Q=150M 1.058 sec/rel, 491 rels
Q=250M 0.868 sec/rel, 558 rels
Q=350M 1.101 sec/rel, 424 rels
Q=450M 1.146 sec/rel, 387 rels
Q=550M 1.310 sec/rel, 340 rels
Q=650M 1.284 sec/rel, 467 rels
Q=750M 1.381 sec/rel, 418 rels
Q=850M 1.307 sec/rel, 405 rels
Q=950M 1.372 sec/rel, 353 rels
Q=1050M 2.458 sec/rel, 368 rels
Max Q = 1073M, expected relations for 50-1073M = 825M[/code]
825M relations isn't enough, and 15e crashes with a notice that max Q is ~1073M. So, we won't be sending this one to the 15e queue as-is.
I tried loosening lim's for better yield:
[code]poly c, 33/66-96, alim=536M, rlim=800M
Q=150M 0.974 sec/rel, 515 rels
Q=250M 0.969 sec/rel, 574 rels
Q=1050M 1.898 sec/rel, 398 rels[/code]
That's about 7% better yield, but 15e uses 1.3GB memory with bounds that loose! Too much for our BOINCers, and 900M relations isn't sufficient anyway.
That leaves a couple of options, listed in order of personal preference:
1. Ask Greg if he's interested in adding this to the 16e queue. A billion relations should take something like Q=50-600M, as 16e yields are usually very close to double 15e yields. Greg prefers lim's of 268M, which would hurt yield just a bit.
2. Run 200m-1073M on 15e queue, with 20-200 done as a forum project on 16f.
3. #2, but with the forum subproject run on CADO.

#1 seems best by far, as C205 is just a bit beyond our reach. I'd like to find a C202-203 to try with 15e, though!

C204?
 

> I'd like to find a C202-203 to try with 15e, though!
C204 maybe? It's the last cofactor of 10^870+1.
[URL]http://factordb.com/index.php?id=1100000000032341587[/URL]

Well, to be safe we need to be able to get 1B relations. That means 15-20% better yield than the C205 polys I just tested. I doubt a single digit change in size will grant that, though it's certainly possible.

Let's see if frmky accepts the C205 on 16e before we do another 4-6 GPU-month poly select effort.

[QUOTE=Max0526;492840]I can't spin the above poly, sorry. But I'd love to see all your results above 3.4e-14, some of them might jump above 4e-14. If you still have the .m or .ms file, I'll process all the suspects today, promise.[/QUOTE]
Here is the next-best scoring, a 3.53:
[code]n: 125418306344861354009234099530308115054784168571883448806721469548914177231420519441798023737607334329713323208573857202696013549660750242809155498156388725322000613487876897998654482601
# norm 3.864200e-18 alpha -7.296188 e 3.539e-14 rroots 3
skew: 123979954.45
c0: 5824060757220315571138706415403379352377998455
c1: -52903445616385967662787687024298089601
c2: -2939266247742570530676372043885
c3: -2503560777758982355724
c4: 72970010279393
c5: 550788
Y0: -743832744056534314818741498541036516
Y1: 100213462976318491[/code]

C186 poly
 

[QUOTE=VBCurtis;492938]Here is the next-best scoring, a 3.53:
[code]n: 125418306344861354009234099530308115054784168571883448806721469548914177231420519441798023737607334329713323208573857202696013549660750242809155498156388725322000613487876897998654482601
# norm 3.864200e-18 alpha -7.296188 e 3.539e-14 rroots 3
skew: 123979954.45
c0: 5824060757220315571138706415403379352377998455
c1: -52903445616385967662787687024298089601
c2: -2939266247742570530676372043885
c3: -2503560777758982355724
c4: 72970010279393
c5: 550788
Y0: -743832744056534314818741498541036516
Y1: 100213462976318491[/code][/QUOTE]
This is the same c5/Y1 pair as 3.924e-14, it doesn't grow any higher. If you post your 3.86 (it was a different c5/Y1 poly I assume), we might have a chance to spin it up past 3.92.

There wasn't a 3.86, alas; I think I noted the norm value rather than the score from this poly when I scanned the screen output.

C196
 

[QUOTE=swellman;492801]The C196 cofactor of aliquot sequence 3366 has almost completed a [url=http://www.rechenkraft.net/yoyo/y_status_ecm.php]full ECM to t60 courtesy of Yoyo@Home[/url], as well as a t55 previous to that. It still has about 475 curves remaining as of this post, but it could be a fun next project.

Suggest anyone interested in searching for a poly start claiming search ranges by the weekend.

[code]
n: 8915368211656556990371631798977588135050731989294422390223244172093242398883796971202480932743367251871592723703242961940017754237147099943136947760081921684863663687415781282804315570869806914839[/code]

Taking 2-3M, though I won’t start searching until later this week.[/QUOTE]

Bump. I’ve started searching 2-3M.

[QUOTE=VBCurtis;492868]C205 testing:

That leaves a couple of options, listed in order of personal preference:
1. Ask Greg if he's interested in adding this to the 16e queue. A billion relations should take something like Q=50-600M, as 16e yields are usually very close to double 15e yields. Greg prefers lim's of 268M, which would hurt yield just a bit.
2. Run 200m-1073M on 15e queue, with 20-200 done as a forum project on 16f.
3. #2, but with the forum subproject run on CADO.

[/QUOTE]

What about raising LPB[AR] to 34? That should raise yield but would also raise the number of relations needed to build a matrix (and would 15e support it?)

Another option would be to sieve on both sides. Sieving on the -r side might yield half as many relations as the -a side, a third of which would be duplicates. But that might get enough relations from 15 to build a matrix.

Chris

[QUOTE=chris2be8;493077]What about raising LPB[AR] to 34? That should raise yield but would also raise the number of relations needed to build a matrix (and would 15e support it?)

Another option would be to sieve on both sides. Sieving on the -r side might yield half as many relations as the -a side, a third of which would be duplicates. But that might get enough relations from 15 to build a matrix.

Chris[/QUOTE]

15e supports 34+ lpb only with a recompile; henryzz has pointed out it's a simple change in the code, but the BOINC-client version is compiled with the 33-bit max. In principle, we could recompile the current 15e siever as 15f, which provides 3 main benefits:
1. Q to 4G
2. 34+LP
3. Sieving below the factor base, so low-Q yields improve dramatically.

To me, NFS@home would be more efficient and more capable with 14e queue having -J 14 permanently enabled (40% better yield, from sieve region 2^14 by 2^14) and 15e turned into 15f. But I don't have any idea how much work either of those would take, and I am in no position to provide the labor.

Since that recompile is not happening soon, sieving both sides should provide us enough relations; I'll do a little testing on the "wrong" side for yields.
Thanks for the ideas!

EDIT: The 15e queue currently has a job scheduled to Q=1200M. If that doesn't cause errors on the clients, I just have a too-old 15e binary and this job could be done with Q of ~50M-1250M and perhaps no sieving on the other side.