[QUOTE=Dubslow;425429]If you put the CADO poly into a poly file as you quoted it and run [c]yafu "nfs($(cat num))" -ns[/c], it should auto fill some parameters, and I'm hoping as part of that it will also score the poly and print the score. Hopefully. I'm not really sure to be honest.[/QUOTE]

Didn't work. I'm using Windows, maybe it works in Linux? But I appreciate your assistance on this matter. Looks like msieve will run the e-score calculation if I construct a proper .fb file.

Fivemack - thanks for queuing this one (and my other recent nominations). I have a few more 15e jobs coming out of ECM this month but I will hang onto them for a while, let the backlog clear a bit.

And don't lose sight of [url=http://www.mersenneforum.org/showpost.php?p=425167&postcount=365]Wombatman's request[/url]. I can't believe how far we've come in just a few years!

And a blatant self serving bump for [url=http://www.mersenneforum.org/showpost.php?p=423990&postcount=359]my two nominations for 14e[/url]. Sorry, couldn't resist...

2657^73-1 has had ECM to 2/9 the SNFS size by yoyo@home

----------------------------------------

The C168 from [URL="http://factordb.com/index.php?id=1100000000438761714"]P169+1[/URL] needs a polynomial - it has had ECM to 1/3 it's size by yoyo@home

[URL="http://factordb.com/index.php?id=1100000000128038376"]P169[/URL] is the largest factor of [URL="http://factordb.com/index.php?id=1100000000438425995"]P21^11-1[/URL]
[URL="http://factordb.com/index.php?id=1100000000007651667"]P21[/URL] is the largest factor of [URL="http://factordb.com/index.php?id=1000000000043572103"]5^79-1[/URL]

C189_147_41 has withstood ECM to t50+. It is an odd thing though - the Windows binaries for the ggnfs siever produces 0 yield on this particular number for three different polys when sieved on the "best" side (-a or -r). In other words, the theoretically optimal poly produces 0 relations. Switch sieving to the opposite side and get relations, though at a suboptimal speed. The issue is discussed in depth [url=http://www.mersenneforum.org/showthread.php?t=20954]here[/url].

The behavior is repeatable by others using Windows. Linux behaves normally. Presumably the 14e sievers of NFS@Home will have no problems.

The poly is below. Note: it should be sieved on the algebraic side. Thanks.

[code]



n: 205451388964856467807686090421078666750691138189010020165236543387336128283211048921251478839880150378554118455189058228045898855699277369470472121604743428745579798048420314101101241961387
# 147^41+41^147, difficulty: 237.08, anorm: 6.37e+039, rnorm: -1.95e+045
# scaled difficulty: 237.08, suggest sieving algebraic side
# size = 2.485e-012, alpha = 0.000, combined = 2.415e-013, rroots = 0
type: snfs
size: 237
skew: 14.7100
c6: 1
c0: 10131387
Y1: -509111094534718962173411120845918138561
Y0: 1483273860320763
rlim: 48000000
alim: 48000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]

908306476686395841704478413585742205345423^7-1 has had ECM to 2/9 the SNFS size by yoyo@home

[QUOTE=swellman;425725]C189_147_41 has withstood ECM to t50+. It is an odd thing though - the Windows binaries for the ggnfs siever produces 0 yield on this particular number for three different polys when sieved on the "best" side (-a or -r). In other words, the theoretically optimal poly produces 0 relations. Switch sieving to the opposite side and get relations, though at a suboptimal speed. The issue is discussed in depth [URL="http://www.mersenneforum.org/showthread.php?t=20954"]here[/URL].

The behavior is repeatable by others using Windows. Linux behaves normally. Presumably the 14e sievers of NFS@Home will have no problems.

The poly is below. Note: it should be sieved on the algebraic side. Thanks.
[/QUOTE]
About half of the throughput of NFS@home comes from Windows machines, see also the GFLOPS in the app table:
[url]http://escatter11.fullerton.edu/nfs/apps.php[/url]

According to the guidelines near the [URL=http://escatter11.fullerton.edu/nfs/crunching.php]top of the page[/URL], some jobs seem to be moved to Queued for Post Processing prematurely. I'm not sure when to request a job since the number of relations appear to be deficient.

We have been moving them once all of the work units have been issued. If we waited until all of the work units were returned some jobs would never finish.

If we are doing this wrong please let us know the right way to do it.

:help:

[QUOTE=RichD;425783]According to the guidelines near the [URL=http://escatter11.fullerton.edu/nfs/crunching.php]top of the page[/URL], some jobs seem to be moved to Queued for Post Processing prematurely. I'm not sure when to request a job since the number of relations appear to be deficient.[/QUOTE]

[QUOTE=Xyzzy;425787]We have been moving them once all of the work units have been issued. If we waited until all of the work units were returned some jobs would never finish.

If we are doing this wrong please let us know the right way to do it.

:help:[/QUOTE]

It is only a cosmetic thing, and though perhaps a bit confusing to a few people, doesn't affect the operation of the last work units or the post-processors.

[QUOTE=Xyzzy;425787]:help:[/QUOTE]
Also check that the Ending Q is at or slightly above the Recommended ending Q. If not, then increase the Ending Q to 2-4 million above Recommended ending Q rather than moving to Queued for Postprocessing. Also, never lower Ending Q. If it's way above recommended, let me know. I can cancel unneeded wu's manually.

:ttu:

[QUOTE=wblipp;425504]The C168 from [URL="http://factordb.com/index.php?id=1100000000438761714"]P169+1[/URL] needs a polynomial - it has had ECM to 1/3 it's size by yoyo@home

[URL="http://factordb.com/index.php?id=1100000000128038376"]P169[/URL] is the largest factor of [URL="http://factordb.com/index.php?id=1100000000438425995"]P21^11-1[/URL]
[URL="http://factordb.com/index.php?id=1100000000007651667"]P21[/URL] is the largest factor of [URL="http://factordb.com/index.php?id=1000000000043572103"]5^79-1[/URL][/QUOTE]

Here's a fairly good poly.
[CODE]N: 109800299836832861614722358938022014452185024181019548309070147153799884708739996097329534313790875159492217854027145667262706110536135516528592925677790160947374436961
# expecting poly E from 4.69e-13 to > 5.40e-13
R0: -420015045927257576153745055960628
R1: 1674845350092611
A0: -1140516300614188620431478667076658929618195625
A1: 25720805995153281415552126837834627275
A2: 82087890455127715444803184895
A3: -1313093240490504663491
A4: -3065166184942
A5: 8400
skew 221539873.65
# skew 221539873.65, size 2.577e-16, alpha -9.496, combined = 4.973e-13 rroots = 3[/CODE]