2022 - queue management for 15e_small

[swellman]

Originally Posted by bur

That seems so low to me. A GNFS 160 takes about 160M raw relations, a GFNS 165 takes about 220 M when I do it with CADO using Curtis' optimized parameters. Is this a result of using very different parameters?

Different parameters and different tools, i.e. GGNFS/msieve vs CADO. Here we are using the historical trend for the recommended # of raw relations needed for msieve on a 30-bit job to form a matrix. But we can always kick up Q if the matrix won’t build at say target density = 110 in postprocessing.

~140M raw relations should be sufficient.

[charybdis]

Originally Posted by bur

That seems so low to me. A GNFS 160 takes about 160M raw relations, a GFNS 165 takes about 220 M when I do it with CADO using Curtis' optimized parameters. Is this a result of using very different parameters?

The number of relations needed is determined by the lpb bounds, not by the size of the number. Increase each lpb by 1 and you ~double the number of relations required. The mfb bounds also have an effect but it is smaller, e.g. using 3LP on one side needs maybe 20% more relations (can't remember exactly how much it is!)

[VBCurtis]

Bur-
When testing params choices on CADO, I find I need 2-3% more relations per digit for a given LP bound choice, and 70% more relations for a given input number for each increase of 1 LPB. 2% per digit adds up when we consider 10+ digit differences- a C170 on 32LP doesn't need nearly as many relations as a C185 with the same large-prime bounds (using larger lims on the C185 adds to this effect).

30LP seems really small for a C175; yield would likely double for 31LP, and 31/32 might be yet faster. Any time GGNFS yield averages below 2.5, chances are very good a larger LP choice is faster.

[swellman]

Originally Posted by VBCurtis

30LP seems really small for a C175; yield would likely double for 31LP, and 31/32 might be yet faster. Any time GGNFS yield averages below 2.5, chances are very good a larger LP choice is faster.

In test sieving I first ran this as a 31-bit job and the yield was great. Would have been a perfectly fine way to sieve this job. But the upper end for 14d is 165-170, a 15e_small at lpba/r of 30 is acceptable for a G-175, and LA takes 1-2 days vs ~a week at 31-bit (system dependent of course). If it’s suboptimal, it’s only just.

Plus it was a nice break from all the monster jobs popping up lately.

[VBCurtis]

Originally Posted by swellman

...and LA takes 1-2 days vs ~a week at 31-bit (system dependent of course)..

I've never noticed this- my matrices seem to depend on input size much more than LP size, until I get to 32LP. I'd be quite surprised to learn that 30 vs 31 is more than 15% larger matrix, for a given input job.

[bur]

I see, so a lower lpb results in fewer relations to be found, but they are more "useful"?

The latter would be due to there being fewer unknowns in the LA problem?

[charybdis]

Originally Posted by bur

I see, so a lower lpb results in fewer relations to be found, but they are more "useful"?

The latter would be due to there being fewer unknowns in the LA problem?

2^lpb is the cutoff for the size of the largest primes/ideals that can appear in relations. Increasing lpb means that you find more relations, because you're allowing larger primes. But you also need more of them to form a matrix, because you need more relations than ideals and you've increased the possible number of ideals.

[bur]

Ah, thanks. Then it makes sense that increasing lpb by 1 doubles the number of required relations.

[VBCurtis]

Originally Posted by bur

Ah, thanks. Then it makes sense that increasing lpb by 1 doubles the number of required relations.

It doesn't. The required number rises by ~75%.
Many test-sievers use "twice as many relations" as their metric, and decide the smaller LPB is faster when it's not. I've completed 32LP jobs with fewer than 300M raw relations, and 31/32 jobs with 200M raw relations (5*2^784-1 required 195M raw relations as a 31/32).

If we look at NFS@home logs, we see that 32LP jobs usually gather twice as many relations as 31LP jobs; however, most of the 32LP jobs are much more difficult than the typical 31LP job, and tougher jobs require more relations. For a given input number, 75% is the right number to use when going up an LPB on both sides, or 1/3 extra when trying a split e.g. 31/32 for LPB.

[swellman]

I’ll throw into the mix that in the past BOINC seemed to have a higher percentage of bad relations than we experience today. More raw relations were needed to reach the desired number of uniques. Definitely could and should be using lower target # raw relations these days in NFS@Home.

[kruoli]

QUEUED AS 2_849p

Cullen number 849 is an SNFS 259 which is ready for sieving.

n: 4693178848105443588405037077689313140090059796932891656436699701239070186072495205194603374565187182301890731865258017239714606914206045688272187831509599345913577655908463514507873092467684232436697919148670185404630805130261264540325092481
skew: 3.22737
# skew by cownoise
size: 259
type: snfs
c6: 1
c0: 6792
Y0: -1
Y1: 2787593149816327892691964784081045188247552
rlim: 178000000
alim: 90000000
lpbr: 32
lpba: 32
mfbr: 94
mfba: 64
lss: 0
rlambda: 3.5
alambda: 2.8

To be sieved on the algebraic side (I tested all other combinations and sieving the rational side, but this one was slightly better). Test sieving blocks of 1k gave

Q	norm. yield
20M	3755
30M	3492
50M	3148
90M	2863
130M	2643
165M	2132
200M	2111
210M	2069

Therefore I suggest sieving Q 30M-195M for 440M+ relations.

I will do the LA.