GNFS C181 currently blocking HP2(4496).
[CODE]n: 12318214520619502375309197444302415329946926189197389561198861911510635946133589638416409637733506897688961608651544$# norm 1.439129e-017 alpha -8.905887 e 7.874e-014 rroots 3
skew: 123515293.34
c0: 4939055050442425955439652118236542439461254700
c1: 13600752217009344448310033829110047310
c2: -2321123572444702694783022432428
c3: -22840646084593908802465
c4: 211416855324726
c5: 727272
Y0: -70108419896313411533408862388542677
Y1: 10591976477210123
type: gnfs


rlim: 286000000
alim: 286000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.6
alambda: 2.6
[/CODE]

This sieved best as a 15/32 job. Assuming ~350-400M raw relations needed (is this accurate?), recommending sieving from 20M-250M for a bit of buffer. Test sieve yields below (2k q-blocks):
[CODE]
Q=20M: total yield: 3853 (0.35063 sec/rel)
Q=100M: total yield: 5379 (0.23646 sec/rel)
Q=200M: total yield: 4497 (0.28346 sec/rel)
Q=300M: total yield: 3487 (0.31513 sec/rel)[/CODE]

[QUOTE=wombatman;467598]GNFS C181
This sieved best as a 15/32 job. Assuming ~350-400M raw relations needed (is this accurate?), recommending sieving from 20M-250M for a bit of buffer. Test sieve yields below (2k q-blocks):
[CODE]
Q=20M: total yield: 3853 (0.35063 sec/rel)
Q=100M: total yield: 5379 (0.23646 sec/rel)
Q=200M: total yield: 4497 (0.28346 sec/rel)
Q=300M: total yield: 3487 (0.31513 sec/rel)[/CODE][/QUOTE]

My personal data only goes up to GNFS170, but 275M 32LP raw relations built a matrix under 10M for that. 400M is likely enough to build a decent matrix, but GNFS180 is getting into "big matrix" land, so some oversieving should save substantial matrix time.
Also, note the high time per relation at 20M; small Q-values don't work as well for GNFS as for SNFS. Even 300M is faster than 20M! It should probably run 40-230M and expect ~430M relations.
We're fortunate the gatekeepers have much experience at this size, and can correct both of us.

I'm assuming 286000000 is a typo for 268000000 (the largest multiple of 10^6 less than 2^28) because there is a small performance cliff at powers of two there. That looks an entirely reasonable 32/15 candidate; when dispatching sieving to nfs@home I usually go for 444 million relations (just a round number!) though I'd expect to be able to build a usable matrix at 350M.

My nearest data point is logN=178.7 E=9.49e-14 where 326.8M relations made a 16.76M matrix which took eight days on an i7/4770K to solve, after 13 days of sieving on 128 fairly slow Xeon threads; a day more on the Xeons might well have saved a day on the matrix.

I appreciate this oversieving is a matter of burning more of other peoples' natural gas in order to be nicer to the 15e linear algebra team, I oscillate on whether that's the right thing to do.

Queued on 15e.

(and then queued again with the right number in the top line - your post has the first 115 digits, a $, and then the norm line)

[b]QUEUED[/b] C159 from the OPN t550 file.
[CODE]n: 117944828466783029341130794951407919800494290243676688928501114065533252139794251478009415680546990298699711759392626060835559321003200394428376875862099950309
# 64171^47-1, difficulty: 230.75, skewness: 6.33, alpha: 0.00
# cost: 1.84331e+18, est. time: 877.77 GHz days (not accurate yet!)
skew: 6.327
c6: 1
c0: -64171
Y1: -1
Y0: 287548069938690982194158881806162430561
m: 287548069938690982194158881806162430561
type: snfs
rlim: 100000000
alim: 100000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 17158
60M 12861
100M 11825
140M 9527[/CODE]

[QUOTE=fivemack;467614]I'm assuming 286000000 is a typo for 268000000 (the largest multiple of 10^6 less than 2^28) because there is a small performance cliff at powers of two there. That looks an entirely reasonable 32/15 candidate; when dispatching sieving to nfs@home I usually go for 444 million relations (just a round number!) though I'd expect to be able to build a usable matrix at 350M.

My nearest data point is logN=178.7 E=9.49e-14 where 326.8M relations made a 16.76M matrix which took eight days on an i7/4770K to solve, after 13 days of sieving on 128 fairly slow Xeon threads; a day more on the Xeons might well have saved a day on the matrix.

I appreciate this oversieving is a matter of burning more of other peoples' natural gas in order to be nicer to the 15e linear algebra team, I oscillate on whether that's the right thing to do.

Queued on 15e.

(and then queued again with the right number in the top line - your post has the first 115 digits, a $, and then the norm line)[/QUOTE]

:davieddy:

Yes, thank you for correcting those typos. And please set the Q-range to whatever you think is appropriate. I've been trying to learn more about the necessary guidelines, but I'm still shaky. :smile:

[QUOTE=fivemack;467614]
I appreciate this oversieving is a matter of burning more of other peoples' natural gas in order to be nicer to the 15e linear algebra team, I oscillate on whether that's the right thing to do.
[/QUOTE]

IMO, any job that requires more than 16GB or more than a quad-core-month for LA deserves to be oversieved, as resources to do such jobs are in short supply.

The 14e jobs and the 15e/31 jobs can be run on most of the LA-solving-pool's machines, and as such should be oversieved only insofar as to minimize the frequency a gatekeeper's editing of Q-range is required.

Is there a chance to alter the BOINC commands for the 14e pool to add "-J 14" to the lasieve command line? Now that nearly every 14e job is near the size where 15e is a viable option, setting this flag would improve overall 14e efficiency. The flag changes the sieve region from 2^14 by 2^13 to 2^14 by 2^14, finding ~40% more relations per Q-range. It's marginally less efficient search space in theory, but since we're sieving numbers outside the efficient range for 14e the gain from more rels outweighs the loss in theoretical efficiency.

Then again, we'd gain efficiency simply by convincing more BOINCers to run 15e rather than 14e and then sending the tougher 14e jobs to 15e instead; but I don't have any idea how we would go about doing that.

C226_143_57 (14e)
 

Another candidate for 14e. Survived ECM to t55 and a bit more at t60. Sieve on the -a side.

[code]
n: 4846210163780194652371739154306052503975694058742199643141954936038658621178225753197153487600982972049251631335307675463568920952755482872691616056868934686502334591899184971330850887145560276922389198184294368241994267585521
# 143^57+57^143, difficulty: 252.85, anorm: 2.58e+040, rnorm: 2.86e+047
# scaled difficulty: 254.02, suggest sieving [b]algebraic[/b] side
# size = 5.957e-013, alpha = 0.000, combined = 8.434e-014, rroots = 0
type: snfs
size: 252
skew: 23.4592
c6: 1
c0: 166679799
Y1: -25004854810776297743
Y0: 1383555343921576970686857174303757103336001
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Some test sieving on the -a side with Q in blocks of 10K:
[code]
rels
Q=20M 20991
Q=80M 15884
Q=150M 14223
Q=250M 14203
Q=310M 12420
[/code]
Suggesting a sieving range of 20M-310M with a target of 450M relations.

C224_148_86, marked 33LP, is actually posted as a 32LP number (and yielding more than I estimated, whoops). I'll start the matrix late Tuesday Pacific time.

I'm still curious about 14e/33; if the gatekeepers are willing to post this new candidate 143_57 as 14e/33, I'll do the LA.

[QUOTE=VBCurtis;468082]C224_148_86, marked 33LP, is actually posted as a 32LP number (and yielding more than I estimated, whoops). I'll start the matrix late Tuesday Pacific time.[/quote]

Sorry, that was my fault. I thought it was going very slowly for a 33LP.

I have submitted 143_57 as 14e/33, and this time actually changed the LPB values in the input file rather than just the number in the description. Initially sieving 200MQ; let's look at the yield when that's done and see how much further VBCurtis wants to go.

C202_137_75
 

C202_137_75 is ready for SNFS, preferably on 14e. It seemed a toss-up between 15e/31 and 14e/32 - neither has great yield - but gotta feed the grid, right? 15/32 looks like the optimal solution, if we ignore the everpresent hunger of 14e...

3LP did not work in any of the four possible combinations, i.e. 3LPa+2LPr and 3LPr+2LPa, sieved on either the -r or the -a side.

Is this perhaps another possible data point for the 14e/33 condition? I will postprocess it regardless of siever/lpb/rlim combination chosen by the gatekeeper.

[code]
n: 1254920216327506711470857726162165812550094782910886342493118602914148985990576287053479944571411779598799332039514853128792523457936465212358489555790194402703085433378083484443208260708735082143829089
# 137^75+75^137, difficulty: 258.76, anorm: 2.78e+040, rnorm: 2.73e+048
# scaled difficulty: 260.09, suggest sieving rational side
# size = 1.763e-013, alpha = 0.000, combined = 3.468e-014, rroots = 0
type: snfs
size: 258
skew: 24.0365
c6: 1
c0: 192851475
Y1: -43716643078717303412870881
Y0: 13378550367377783913980238139629364013671875
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving of the above 14e/32 poly with Q in blocks of 5K.
[code]
Q=20M rels=5448
Q=80M rels=4487
Q=150M rels=3826
Q=250M rels=3356
Q=450M rels=2652
[/code]
Suggesting a sieving range of 20M-640M with target # rels = 400M (maybe oversieving?).



Test sieving of 14e/33 poly with Q in blocks of 5K, using same poly as above (with r/alim=[b]268e6[/b], lpbr/a=33, mfbr/a=66 and r/alambda=3.0).
[code]
Q=20M rels=7959
Q=80M rels=6563
Q=150M rels=5640
Q=250M rels=4935
Q=350M rels=4664
[/code]
Suggesting a sieving range of 20M-380M with a target # rels = 400M.



Test sieving of 14e/33 poly again with Q in blocks of 5K, using same poly as above (but this time with r/alim=[b]134e6[/b], lpbr/a=33, mfbr/a=66 and r/alambda=3.0).
[code]
Q=20M rels=6838
Q=80M rels=5530
Q=150M rels=4595
Q=250M rels=3775
Q=400M rels=2975
[/code]
Suggesting a sieving range of 20M-510M with a target # rels = 400M.



Test sieving as a 15e/31 job with Q in blocks of 5K, using same poly as above (with r/alim=134e6, lpbr/a=31, mfbr/a=62 and r/alambda=2.7).
[code]
Q=20M rels=5098
Q=80M rels=3972
Q=150M rels=3184
Q=250M rels=2691
Q=400M rels=2291
[/code]
Suggesting a sieving range of 20M-410M with target # rels = 240M.



And finally, going all in with test sieving the above poly as a 15e/32 job with Q in blocks of 5k (i.e. r/alim=268e6, lpbr/a=32, mfbr/a=64 and r/alambda=2.8).
[code]
Q=20M rels=11464
Q=80M rels=9305
Q=150M rels=8033
Q=250M rels=7113
Q=400M rels=6092
[/code]
Suggesting a sieving range of 20M-340M with target # rels = 520M.

Thank you for all the options!

I have put this one in as a 14/33, I think 400M is rather low for 33LP; if you don't mind, could you try post-processing when it hits the Q=400M mark, and we can add more relations if that doesn't work.