I’m just confused about your chosen sieve range and lpb sizes.

PS(nevermind , I didn’t look at the trial sieve values)

Time for my periodic reminder that choosing LP bounds that cause average yield below 1.0 is distinctly suboptimal. It is a fallacy that matrices from such jobs are easier and smaller than the same job with 1 higher LP bound; matrix size scales pretty steadily with input difficulty, and not very much at all with LP choice provided LP is 32 or lower.

Q-ranges of 100M or greater should use 31LP, as using 30LP would mean a yield around 1.0-1.2.
Q-ranges of 180M or greater should use 32LP, as using 31LP would mean a yield around 1.2-1.4.
Q-ranges of 320M or greater should likely use 33LP, or 15e with a much smaller Q-range.

An example of the last situation: I test-sieved 13*2^870-1 and found I'd need Q of 20-330M on 14e, but just 20-133M on 15e. I cut alim and rlim in half for the 15e tests.

The only reason I know of to stick to smaller LP choices is to save disk space on the server; I've been submitting jobs that are faster at 33LP as 32 or 32-33 hybrid to save 200M relations' worth of disk space.

Thank you Curtis for your last message.
Hope next year I can afford a new machine so I can do the 31-32 bit jobs.

[QUOTE=jyb;501601][B]QUEUED AS 3p2_1374M[/B]

SNFS-218.5 (quartic) C188 HCN (3+2,1374M), ECM to t54+. For 14e.
[code]
n: 44839735358598707252555531236585887831019607286396777904986801265663864886296103132384389353081153430783934990117572443894329881796932464882694369089685995379947826196672194425429020268997
skew: 0.816497
c4: 9
c3: 18
c2: 18
c1: 12
c0: 4
Y1: 20769187434139310514121985316880384
Y0: -2465034704958067503996131453373943813074726512397600969
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
[B]mfbr: 93[/B]
mfba: 62
[B]rlambda: 2.6[/B]
alambda: 2.6
[/code]Trial sieving 5K blocks:
[code]
Q Yield
--- -----
20M 4090
50M 5538
80M 6073
110M 7209
140M 6911
170M 6473
200M 6621
230M 6433
260M 6594
290M 6169
[/code]Recommend sieving special Q on rational side, 20M - 230 M.[/QUOTE]

Are the highlighted values correct? You normally want rlambda 3.6 or similar when using 3 large primes.

The same question applies to the next job (4p3_1335L).

Chris

[QUOTE=VBCurtis;501622]Time for my periodic reminder that choosing LP bounds that cause average yield below 1.0 is distinctly suboptimal. It is a fallacy that matrices from such jobs are easier and smaller than the same job with 1 higher LP bound; matrix size scales pretty steadily with input difficulty, and not very much at all with LP choice provided LP is 32 or lower.

Q-ranges of 100M or greater should use 31LP, as using 30LP would mean a yield around 1.0-1.2.
Q-ranges of 180M or greater should use 32LP, as using 31LP would mean a yield around 1.2-1.4.
Q-ranges of 320M or greater should likely use 33LP, or 15e with a much smaller Q-range.

An example of the last situation: I test-sieved 13*2^870-1 and found I'd need Q of 20-330M on 14e, but just 20-133M on 15e. I cut alim and rlim in half for the 15e tests.

The only reason I know of to stick to smaller LP choices is to save disk space on the server; I've been submitting jobs that are faster at 33LP as 32 or 32-33 hybrid to save 200M relations' worth of disk space.[/QUOTE]

Thanks! I want to explore this more, but without cluttering up this thread. So I created a new thread for it. Please see my post [URL="https://mersenneforum.org/showthread.php?t=23865"]there[/URL].

[QUOTE=chris2be8;501668]Are the highlighted values correct? [COLOR="Red"]You normally want rlambda 3.6 or similar when using 3 large primes.[/COLOR]

The same question applies to the next job (4p3_1335L).

Chris[/QUOTE]

My goodness, my last few proposals for the grid have generated quite some attention (in a bad way)! In my ignorance I may have made another mistake here. But in response to your highlighted claim above, my question is: why?

Let's have follow-ups on the [URL="https://mersenneforum.org/showthread.php?t=23865"]new thread[/URL].

[B]QUEUED AS 7p6_320[/B]

Let's see how this one goes over.:smile:

SNFS-216.3 (quartic) C175 HCN (7+6,320), ECM to t53+. For 14e.
[code]
n: 2096668945124846104936524469293743083652163786726518117628633594683453465704882596336036173313716942495865167087580490389725536338435858785677170181687349875728795502959918721
# 7^320+6^320, difficulty: 216.35, skewness: 1.00, alpha: 1.45
skew: 1.000
c4: 1
c3: -1
c2: 1
c1: -1
c0: 1
Y1: -63340286662973277706162286946811886609896461828096
Y0: 1219760487635835700138573862562971820755615294131238401
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 90
mfba: 62
rlambda: 3.0
alambda: 2.6
[/code]
Trial sieving 5K blocks:
[code]
Q Yield
--- -----
20M 5264
50M 7540
80M 8117
110M 9765
140M 8960
170M 8848
[/code]
Recommend sieving special Q on rational side, 20M - 170M.

Change that rlambda to 3.6 rather than 3.0!

Or maybe I don't understand lambda at all.... I've usually used 2.x for 2LP, 3.x for 3LP, where x is 6 or 7. Sometimes I test-sieve x=6 vs x=7, results haven't told me much. I think if you test-sieved with 3.0, you were actually test-sieving 2 large primes rather than 3?

[QUOTE=VBCurtis;501720]Change that rlambda to 3.6 rather than 3.0!

Or maybe I don't understand lambda at all.... I've usually used 2.x for 2LP, 3.x for 3LP, where x is 6 or 7. Sometimes I test-sieve x=6 vs x=7, results haven't told me much. I think if you test-sieved with 3.0, you were actually test-sieving 2 large primes rather than 3?[/QUOTE]

What? Here's what you said in the other thread:

[QUOTE=VBCurtis;501683]Now, I thought lambda was supposed to be the ratio of MFB to LPB, but if it was then 2.0 or 2.1 should always be best (or 3.0 or 3.1 for 3LP)
[/QUOTE]

And yes, I know you later say that it should be "3.7 or 3.8 or maybe 3.9" for 3LP, but it doesn't seem like you can give a reason why. And while I am sometimes willing to do things simply because they are considered best practices, nobody seems to have any actual understanding of what the best practice is here and why. So while I certainly don't know better than you here, I'm not terribly inclined to make this change without some further explanation.

Edit: And by the way, saying "I don't really understand why, but this will speed up sieving by 10%" would be a perfectly fine explanation for these purposes. But I haven't heard anything to that effect, or heard tell of any evidence that something like that should be the case.

[QUOTE=jyb;501725]Edit: And by the way, saying "I don't really understand why, but this will speed up sieving by 10%" would be a perfectly fine explanation for these purposes. But I haven't heard anything to that effect, or heard tell of any evidence that something like that should be the case.[/QUOTE]
Well then, here would be an opportunity to do a controlled scientific experiment. Use the suggested value and do trial sieving on the same regions. Voila! You now have data.

I don’t thing we should care about the sieve speed since it is done by others. What we should concentrate is achieving smaller matrix. The former we can’t quantify when we are using the NFS grid (generally speaking).