2022 “small” 15e post processing reservations and results

[kruoli]

If you had sieved a larger Q range with the high yield, duplicates still would have occurred more often, but of course this means it would have been greatly oversieved.

[VBCurtis]

Originally Posted by bur

So in a way, the higher the raw yield is, the higher the uniques:duplicates ratio will be?

Duplicate rate appears most correlated with the ratio of Q-max to Q-min.
In this case, your outcome suggests you left a little speed on the table by starting with Q a bit too high- lower Q are faster to sieve, but will produce more duplicates.

I didn't look up the params and q-range you used, so I can't be more precise.

[chris2be8]

You said to sieve from 25M to 100M, with lims of 134M. Sieving from about 100M to 175M should have got enough relations with a lower duplicate rate. (Of course you would have to have test sieved up to 175M first.)

Sieving below the lims (factor base sizes) produces a higher yield, but more of them will be duplicates the lower you go. So sieving about half each side of the lims usually works best. Obviously if the yield drops fast with higher Q then sieve as low as necessary to get enough relations.

[VBCurtis]

Another way to phrase Chris' advice is that if your highest Q is below lim, your lim is too big.

Sieving from 25M to 100M means lim should be 67M on the sieve side. 67/100 or 67/134 with the smaller lim on sieve side would likely have been faster for this job, and Q from 20-95M hits both my rule-of-thumb for Q-max to be 5x to 6x Q-min and Chris' guidance to have sieve-side lim about in the middle of the Q range. SNFS jobs work fine with Q-max a higher multiple of Q-min, so Q=15-95M is fine for SNFS.

Note that GGNFS slows down a bit when lim's grow above a power of two, which is why specifically 67M and 134M are such common lim choices; in general, 67M will always be faster than 80M because 80M is barely above a power of two. I never use lim's between 33M-45M, 67M-95M, and 134-180M for this reason.

[bur]

Ok, thanks, that's unfortunate, but very good advice. I was wondering how to estimate the q-range without doing a full sieve and look at the duplicate ratio.

have got enough relations with a lower duplicate rate. (Of course you would have to have test sieved up to 175M first.)

But how would I know the duplicate ratio from the test sieving? The raw relation yield per q-range from GGNFS was more or less constant. At least compared to what I'm used to from CADO. There I usually find a very strong decrease of yield per q-range with increasing q. Not at all here:

MQ     norm_yield
25     3647
50     3791
75     3759
100    3498
125    3366

So just from the raw yield it seemed good to sieve that range.

I took the params for this specific number straight from CADO but the Q-range from general nfs@home experience for numbers that size. Apparently it didn't match.

[bur]

Results for aliquot C174_1992_1695 (didn't loose the 7):

p82 factor: 3624621364325232093251368039886141925793212945379537167589424077672470583327124917
p93 factor: 129831914655437243002636324508831589681241737727491941396935308448015013059011667938456214033

Thanks for getting this sieved at nfs@home and the help with setting it up.

[kruoli]

4_430m is done! It splits as:

p68 factor: 60460248666934940458806521783893530240379067017235037404134666098433
p189 factor: 114036829378480016981222258595031044238787130701816847117534396072226125060455954819230028534439203604683952601623241750062475969768637379406861448640753325928202256154633651815331944481759

This was the first one where I used the new OpenMP branch of msieve, it rocks!
Not yet in FactorDB because of their power outage; please remind me to put the factors there if I forget.

[VBCurtis]

Originally Posted by bur

Ok, thanks, that's unfortunate, but very good advice. I was wondering how to estimate the q-range without doing a full sieve and look at the duplicate ratio.
But how would I know the duplicate ratio from the test sieving?

We cannot know the duplicate range in advance. However, GNFS jobs all behave very similarly, so a bit of experience (ok, a lot of experience) guides us to the right number of raw relations to target that will give us a decent matrix. Sometimes we get more uniques than we expected, and the matrix comes out smaller / nicer. Other times it's the opposite, and we have to go back and sieve another 10 million Q.

[frmky]

8m7_293 is done.

[frmky]

As is 8p7_293.

[RichD]

Taking 177__227_5m1_2. It can be moved to Queued for Post-Processing because it appears it may be over-sieved.