Fast Breeding (guru management)

[Dubslow]

I would argue CADO is a better target for CPU-polyselect Boincification. I've no idea how to Boincify things, but I could assist with it (especially with isolating the polsel code).

[debrouxl]

I would argue CADO is a better target for CPU-polyselect Boincification.

If CADO generates better polynomials than msieve in the difficulty ranges we're interested in, like it does for large numbers nowadays, yeah, that would make sense. I suggested msieve because that's what we know best, and using it is easy

I've no idea how to Boincify things, but I could assist with it (especially with isolating the polsel code).

When squalyl BOINC-ified ggnfs-lasieve4I14e for RSALS, it was a matter of calling a number of functions from BOINC's library, to tell BOINC "the program is starting", "the program is entering", calling the watchdog often enough for the application not to be killed, etc.
The unsads URL linked from http://www.mersenneforum.org/showthread.php?t=12458 is no longer valid, but the diff against upstream was less than 100 LoC IIRC. Greg improved on it for NFS@Home, so as to pass the variable arguments onto the command line to augment a common poly file, rather than through a unique input file generated for every WU.


Functionally, we already have most pieces of a dream common infrastructure that yoyo@home, NFS@Home and volunteers could tap into and enrich, but they're scattered:
* projects and FactorDB know everything about the formulas yielding the full-sized composites and their smaller factors, if any;
* Near-repdigit (NR) and yoyo@home know the progress of ECM work;
* FactorDB, project-specific tools (snfspoly for XYYXF, phi for Homogeneous Cunningham, etc.) and YAFU can provide decent SNFS polynomials, most of the time;
* NR has a full-blown reservation system and pretty progress pages;
* NFS@Home holds information about polynomials, reservations and ECM work, but the latter are nowhere near as good as NR;
* multiple community members, e.g. Greg and Tom, have time-proven trial sieving scripts;
* multiple community members can provide excellent estimates of the length of the range of q values, based on trial sieving and past jobs;
* all projects maintain information about factors and who found them.

[swellman]

There is C188_132_125 ready for GNFS. yoyo has run a full t60 on it. Gimarel found a good poly (reposted below).

n: 50273137870496627962619474857651209584588819926907884717658637056035831552476809435481986166176902404920890412162765555466588497900990664373537298713854777126289379520005080044132902865599
# norm 2.562649e-18 alpha -6.202830 e 2.758607e-14 rroots 3
skew: 25794299.29
c0: 12225881829202389469113633294763858052217368
c1: 909252292310151017414975792320341612
c2: 88266555889493914816907699472
c3: -1851197869646162290468
c4: -712927535990181
c5: 2042040
Y0: -1897817074727870197161607354785763325
Y1: 1418223754443542213
rlim: 26800000
alim: 26800000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8

These are my suggested parameters but I have little experience with GNFS jobs this large so "tweaking" may be necessary.

[XYYXF]

And there's also a C173 which survived t55: http://mersenneforum.org/showthread.php?t=18368&page=55

[Dubslow]

For 14e, here's a GNFS-162: GW_3_615.

You may pick from either the two polys posted here, or the five posted here. As far as I know, no one has trial sieved any.

[RichD]

A few other potential (all GNFS) candidates scattered about the forum.

Thanks Dubslow for finding a poly and getting the reference posted above for GW_3_615.

Two Aliquot Sequences.
3366:i2134 has a C151 with a poly here.
3408:i1628 has a C157 with a poly here.

Several more GCW candidates.
W_847 has a C161 with a poly here.
GC_9_274 has a C161 with a poly here.
GW_4_424 has a C165 with a poly here. Thanks to wombatman.

[pinhodecarlos]

Just a quick note. Last 24 hours more than 14k 14e task were processed. I think at this moment NFS can process close to a daily 20k 14e tasks.

[debrouxl]

Sean: I don't have experience for jobs of that size either, but the parameters you gave for C188_132_125 look alright. The current "C190_HP2_4496_296" (internal name) uses:

n: 2463736601122447266257298700393603699043981908096866290769923015377025843584630424369597406016232631749751217215397861267748677508553789649900663934956675572965438394247075872260218511247217
lss: 0
skew: 164406308.24 
Y0: -6122675429695590794594870091405716508
Y1: 811165482525010679
c0: -1094002446677973934687677554322517275899294365
c1: 213239803679241390276248022925209305657
c2: -12858299808518702215380662301317
c3: -131441698551532940592641
c4: 487261347251442
c5: 286344
lpbr: 32
lpba: 32
mfbr: 64
mfba: 96
alambda: 3.6
rlambda: 2.6
alim: 268000000
rlim: 268000000

The 15e part of the grid was starving, so for now, I've expanded the range for C182_933436_12513.
Unless the usual 15e shepherds say "no", I shall queue the polynomial from post #531, possibly mixing in 3LP parameters, despite not knowing what I'm doing: I don't have time for trial sieving.

Andrey: which number / polynomial from that page, exactly ?
That would be food for 15e. And I'll probably queue it before the big GNFS 188.

Bill, Rich, (Paul): reserving GW_3_615, W_847, GC_9_274, GW_4_424. Thanks for the candidates. Could you trial-sieve GW_3_615 ?

Carlos: indeed, because the 30 XYYXF tasks are quite easy.

All: before creating a dedicated topic about a more automated infrastructure, I'd like some feedback on the bottom of post #530, the discussion started at post #526. TIA

[pinhodecarlos]

Syracuse University by itself is processing an average daily of 5k tasks.
By my estimate looking at the stats we have allocated on 14e application more than 600 cores.

[wombatman]

Originally Posted by debrouxl

(snip) All: before creating a dedicated topic about a more automated infrastructure, I'd like some feedback on the bottom of post #530, the discussion started at post #526. TIA

I like the idea of more automation to help smooth things along. One possibility would be a submission form where one could propose a number to be added to the queue. Maybe require the full set of parameters along with a polynomial in that instance so that you don't get (as many) random submissions. Or use a whitelist of trusted people to make the submissions. If they're approved, they get added to the appropriate queue.

On the reservation side, you could do something like the Cunningham numbers, but it may be useful to have some kind of estimate of RAM size needed (and number of relations?) so that a person doesn't try and process something they can't handle. As an example, the C190 for HP2 ended up needing ~22GB, so while I had planned to do it on my laptop, I ended up needing to use my desktop instead.

Lastly, for the ECM declarations, I think you'd again need some kind of whitelist so that you don't have random junk thrown in, but I think it would be a good way to check off numbers that are ready for queuing.

Just some thoughts.

[XYYXF]

Originally Posted by debrouxl

Andrey: which number / polynomial from that page, exactly ?

C173_139_59, the poly will appear in a day or two, I hope.