Fast Breeding (guru management)

[pinhodecarlos]

Forget the pub tonight and feed the 14e queue. I'll drink a doom bar for you.

[xilman]

I can put in a good number of S250+ numbers but they are rather difficult for the 14e queue and there's a good chance of p48-p55 factors to be found.

[pinhodecarlos]

Originally Posted by xilman

I can put in a good number of S250+ numbers but they are rather difficult for the 14e queue and there's a good chance of p48-p55 factors to be found.

I see a SNFS254 on the queue but there's no clue on how much ecm was done.

[debrouxl]

Lionel, that's not an excuse

I know, but whether you like it or not, the current situation on 14e has something to do with the upcoming size contest.

Please just add the rest of the numbers to the queue.
...
Forget the pub tonight and feed the 14e queue

You're asking so kindly
But yeah, that's what I needed to do, and in fact, started doing before you posted the second post.


FYI, AFAICR, I went to a local "bar" about twice in the past five years, with work colleagues. I have near-zero social life, you see. Integer factoring is a more minor contributor to that state of fact than the TI graphing calculators community, which is, as you know, the reason why I became part of the integer factoring community - but still.
The pain of feeding 14e (and recently 15e twice) is growing (not just for me !), and .... size contests which raise the workload of everyone (pre-processers, mainly myself for feeding the grid though e.g. Paul helps with the GCW numbers, post-processers) are not the best way to raise my motivation
At least, you're providing advance notification about them. And someone else (Mike ?) takes care of most expansions of the initial, intentionally short q ranges, and updates the page with a subset of the reservations and results.

[pinhodecarlos]

Boinc Pentathlon will not choose NFS for any of the disciplines, not this year I think.

Doom bar...

[wombatman]

Maybe some of the numbers from Kamada's Wanted list could be used? There's a wide range of SNFS and GNFS numbers. The SNFS polynomials are usually pretty good (although I've only done the smaller numbers before). No idea on the GNFS.

http://stdkmd.com/nrr/wanted.htm#nofactorknown

[debrouxl]

Indeed. I've already made a dent into the SNFS 225-230 and 245-250 numbers from that particular page, and Dmitry Domanov is pre-processing a couple *_248 NR numbers for me

[wombatman]

I should have figured as much.

[jyb]

Originally Posted by debrouxl

The pain of feeding 14e (and recently 15e twice) is growing (not just for me !), and .... size contests which raise the workload of everyone (pre-processers, mainly myself for feeding the grid though e.g. Paul helps with the GCW numbers, post-processers) are not the best way to raise my motivation.

So what would be the best way to raise your motivation? Or really, what would be the best way to help you so that the pain will be less acute for you?

Some things which occur to me:

1) Try to hit the sweet spot on difficulty. There have been a bunch of low-difficulty numbers lately, and that must increase the load on you, since they don't last very long in the queue. What would you say is the ideal SNFS/GNFS difficulty for 14e right now? 15e?

2) Have somebody else set up the polynomial and do trial sieving to set parameters. For GNFS jobs I think other people have been finding the polynomial, but for SNFS jobs you can require that whoever proposes the number also provide the polynomial for it. That's usually not hard, but it's still a barrier to actually getting the number into the queue. And setting parameters probably takes you some time as well, time which you can possibly outsource to others, either the proposer or any willing volunteers.

Any other ideas?

[debrouxl]

* for 14e, the sweet spot on difficulty is SNFS 236-~250 and GNFS 16x. A SNFS 254 task recently produced decent yield even with 31-bit LPs, but that was a flare.
* for 15e, from what I can see (normally, I'm not taking care of it, though I have access to both the 14e and the 15e management forms), the sweet spot is SNFS 27x and GNFS 18x. GNFS 190-195 work, 195+ stretch 15e to its limits.

As we know, tasks of those difficulties require quite a bit ECM preparation work if we want to try and follow the usual rules of thumb for ECM work wrt. NFS work. And GNFS tasks require additional polynomial selection work.
For ECM work, the rules were already relaxed a bit over the past few months; despite that, NFS@Home 14e and 15e clients are still stretching the pool of ECM resources.
Non-Aliquot GNFS tasks are a rarity on 14e, though available in fairly large supply at multiple projects, because I don't want to create more work load for the relatively few persons finding GNFS polynomials...

Therefore, indeed, we have to tap into easier numbers which have received the adequate amount of ECM work. And yeah, they increase the load, though Sean was kind enough to provide 30 ready-made SNFS polynomials (which probably took him several hours of work).


So what to do ?
1) I think that in the short term, we need to find a way to build a bit of a queue by deep ECM work on select numbers, as is currently being done for XYYXF GNFS 18x tasks suitable for 15e through yoyo@home. Perhaps Ryan Propper could lend a hand for the 15e queue ?
SNFS difficulty 24x tasks / GNFS 16x for 14e are harder to come by in a form which minimizes ECM misses, and they don't feed the grid for very long - a testimony to the increasing computing power available to individuals, anyway

2) for sustainability in the longer term, I think that we need to further raise cooperation between projects, and somehow raise automation of the process of:
* reserving numbers from projects / projects proposing numbers;
* declaring ECM work;
* performing ECM work (that one is taken care of at scale by yoyo@home);
* selecting GNFS polynomials (new BOINC task type based on msieve for -np1, and centralized -nps on the best hits ?);
* queuing numbers (the existing interface, derived from squalyl's original management form for RSALS's 14e, is quite a good foundation);
* trial-sieving (could be done in an automated fashion, server-side ?);
* adjusting the q ranges (it could be automated);
* reserving numbers for post-processing (usually, posts on MF copied by mainly myself into the management interface - we can do better);
* declaring results (ditto).

Essentially, a functional superset of the RSALS 14e / NFS@Home 14e+15e and Near-repdigit interfaces. Needless to say, building such an infrastructure takes time, and Greg is pretty busy.

We need wider brainstorming and programming help

[swellman]

Originally Posted by swellman

Andrey has identified C215_121_81 as SNFS ready.

Also, C198_124_71, C203_130_102, C223_122_77 and C199_142_60 appear ready as well (I gave them a small burst of ECM @t55).

All xyyx composites, and of course we've done a lot of those lately, just something for the back of the queue/stockpile. Thanks.

Attached are the polynomials for my nominations quoted above. In future I will publish these with any composites I suggest.