[QUOTE=VBCurtis;472262]I propose Two Golden Rules of 14e queue parameter choice:
1. Choose lim's such that your forecasted sieve range ends before 2 * {lim on the sieving side}. You don't have to choose a power-of-two lim: 140M is not a fast choice (just above a power-of-two), but there's nothing wrong with using 180M or 100M.
2. Choose LP bound such that average yield (specifically, relations divided by Q-range) is 2.0 or higher.

It's really unlikely to go wrong when following these two rules, and rarely faster to violate either of them.[/QUOTE]

Those are really good general rules to go by. The quartics (p^5-1) must have different attributes.

I tried increasing the lim from 67M to 134M but that added 20-25% more time per rel, but did increase the yield. We still needed the same number of total relations. Hence, more total time to sieve. My accidental first try had the best times of all - nearly half the current rate.

I usually like to keep the range to about 1.6-1.8 times the lim. I've seen curves where the yield starts at 2.0 but by the time the Q gets to 2*lim, it could be at or below 1.0. This curve is so flat there is not much of a penalty extending the range, for some unknown reason.

Which brings me to another point. I sometimes will increase the lim by 50% to squeeze a bit more yield. It increases the time/rel more than the yield gain but it keeps from getting past the 2*lim region where the curve really falls off. I try to avoid creating 32-bit jobs where it takes weeks on my Core-i5 to post-process. :smile:

P.S. These where the parameters [B]jyb[/B] used for p55^5-1 jobs when he added items to the queue.

[QUOTE=RichD;472271]Those are really good general rules to go by. The quartics (p^5-1) must have different attributes.

I tried increasing the lim from 67M to 134M but that added 20-25% more time per rel, but did increase the yield. We still needed the same number of total relations. Hence, more total time to sieve. My accidental first try had the best times of all - nearly half the current rate.

I usually like to keep the range to about 1.6-1.8 times the lim. I've seen curves where the yield starts at 2.0 but by the time the Q gets to 2*lim, it could be at or below 1.0. This curve is so flat there is not much of a penalty extending the range, for some unknown reason.

Which brings me to another point. I sometimes will increase the lim by 50% to squeeze a bit more yield. It increases the time/rel more than the yield gain but it keeps from getting past the 2*lim region where the curve really falls off. I try to avoid creating 32-bit jobs where it takes weeks on my Core-i5 to post-process. :smile:

P.S. These where the parameters [B]jyb[/B] used for p55^5-1 jobs when he added items to the queue.[/QUOTE]
This is, indeed, interesting to note the exceptions to such rules. Your job has a very unusually flat yield/Q curve, and a small choice of alim/rlim does appear better than my rules. I haven't done many (any?) quartics with SNFS, so my "golden rules" are perhaps only for degree 5-6 polys.

I do object to your 32-bit comment, though- unless this is another quartic quirk, I've found no difference in matrix size for 32LP vs 31LP, for a given difficulty of input number. Tough 32LP jobs are way bigger than most 31LP jobs, but there's no reason to assume that a bigger LP bound produces a bigger matrix.

[b]QUEUED C223_14083_59[/b] C223 from the OPN t550 file.
[CODE]n: 1865615717130772767119311116455570124208658607305842896726964588854670423572329039423087652007275888761705267019924529226143361268713546866643218854079602599917062877045108854870518360637155062971394820217914898442214150729
# 14083^59-1, difficulty: 248.92, skewness: 4.91, alpha: 0.00
# cost: 7.6469e+18, est. time: 3641.38 GHz days (not accurate yet!)
skew: 4.914
c6: 1
c0: -14083
Y1: -1
Y0: 306868134259300507087306303463544482273449
m: 306868134259300507087306303463544482273449
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.7
alambda: 2.7[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 12794
60M 10453
100M 10259
150M 8718
200M 8112
250M 7103[/CODE]

[b]QUEUED C188_895087_37[/b] C188 from the OPN t600 file.
[CODE]n: 10617829570839276659747741853830398849952865684054101910712506186845820619498688254461924516392091331519790551485245847452914148598316001358346365710249062092556695500444158007971971931097
# 895087^37-1, difficulty: SNFS-222
skew: 0.102
c6: 895087
c0: -1
Y1: -1
Y0: 514270363717491334687895212442791009
m: 514270363717491334687895212442791009
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 9690
50M 7398
80M 5836
110M 5735[/CODE]

For 16e
 

A C208 blocker from HP2(4496) index 314. It has been thoroughly ECM'd and shows no sign of breaking.

The polynomial is:
[CODE]n: 8095101662371927421703337019465587498085337648622133688278589711654019359923503887978141510461468343349838217540569173400647791769725685803537804186347867144149599002247585690859122186539724272741806859085719
skew: 771127364.56
Y0: -17068243492239505219994785346910834818341
Y1: 1873940548553722757
c0: 165792391853474935561243616954647727516748946250496
c1: 2160239644350504494844955872920952825447896
c2: -21514458180493538566295548810659238
c3: -5887571126475837688637761
c4: 35919796435243602
c5: 5588280
type: gnfs

rlim: 800000000
alim: 800000000
lpbr: 33
lpba: 33
mfbr: 96
mfba: 96
rlambda: 2.6
alambda: 4.6[/CODE]

All parameters were set based on the previous C207 I ran as well as some sieving tests. The best degree 6 polynomial was also checked and found to be slower.

Sieve timings are as follows:
[CODE]Q-blocks of 2000, 16e
33A
50M: total yield: 2030, q=50002009 (2.37828 sec/rel)
100M: total yield: 2986, q=100002011 (2.19112 sec/rel)
200M: total yield: 2663, q=200002007 (2.28734 sec/rel)
300M: total yield: 3343, q=300002029 (2.41504 sec/rel)
400M: total yield: 2874, q=400002011 (2.70271 sec/rel)
500M: total yield: 2619, q=500002003 (3.04544 sec/rel)
600M: total yield: 2464, q=600002003 (2.94305 sec/rel)
700M: total yield: 2263, q=700002011 (3.67559 sec/rel)
800M: total yield: 2904, q=800002003 (3.70078 sec/rel)
900M: total yield: 2771, q=900002017 (3.72014 sec/rel)[/CODE]

The C207 needed 950M+ relations to build the matrix, according to the log, so the Q-range needs to be ~635M long or so, which would suggest something like 100M-800M?

I know this will need to be sent to frmky to actually get added to the 16e queue, but I figured I would post it here for both posterity and to make sure I didn't miss anything obvious before I make my request to him.

Just curious - did you mean alambda: 4.6 or is that a typo?

If intentional, does it make a big difference in speed/yield?

[QUOTE=swellman;472407]Just curious - did you mean alambda: 4.6 or is that a typo?

If intentional, does it make a big difference in speed/yield?[/QUOTE]

The 4.6 is intentional and it does slightly improve the speed and yield over 3.6.

The 2.6 for the other lambda makes no sense, since you have 96 for mfbr. 3LP require lambda above 3.0.

[QUOTE=VBCurtis;472419]The 2.6 for the other lambda makes no sense, since you have 96 for mfbr. 3LP require lambda above 3.0.[/QUOTE]

Thanks. I'll up it and re-run a few ranges to see how that parameter affects the speed and yield.

[b]QUEUED C215_10695665473_23[/b] C215 from the OPN t550 file.
Sieve on the algebraic side.
[CODE]n: 30763230003902403786374728887690763700728078820500331429048458439998376653484290078336744584927334552651151486915560134867070802466057580185289662645224533831086254604129851935910106985930522415164930677253990639963
# 10695665473^23-1, difficulty: 240.70, skewness: 46.94, alpha: 0.00
# cost: 4.04942e+18, est. time: 1928.29 GHz days (not accurate yet!)
lss: 0
skew: 46.939
c6: 1
c0: -10695665473
Y1: -1
Y0: 13086733074990294411997693788174817885441
m: 13086733074990294411997693788174817885441
type: snfs
rlim: 132000000
alim: 132000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.7
alambda: 2.7[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 12348
60M 8822
100M 9910
150M 6537
200M 7234
250M 6071[/CODE]

[b]QUEUED AS C210_129_103b because I put it on 14e first by mistake[/b] C210_129_103 is ready for SNFS on the 15e siever.
[code]
n: 973422547784370322457514782831736956145196852856089924944333043407352689659116145124574973212168048907620323202284319881038292185920124546679327720675621471037727699034904089811538148953969144467029739410525629
# 129^103+103^129, difficulty: 261.77, anorm: 2.37e+040, rnorm: -3.95e+048
# scaled difficulty: 263.14, suggest sieving rational side
# size = 1.970e-013, alpha = 0.000, combined = 3.740e-014, rroots = 0
type: snfs
size: 261
skew: 4.5150
c6: 129
c0: 1092727
Y1: -1860294571709496226110032706809177658295303
Y0: 758621374683090977986568634824263809
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the -r side with Q in blocks of 2K.
[code]
20M 4879
80M 3522
150M 3378
250M 3015
320M 2764
[/code]
Suggesting a sieving range of 20M-300M with target # rels=480M.