[QUOTE=swellman;486865][b]QUEUED[/b] C229_151_42 is ready for SNFS on 14e. Last 14e in my stores.
[code]
n: 1102417068447110828974330387319614606833947746041503077867648379042331914001941722688011464435548663098126330974444255295476735778999607110151139584098525740184596427948553032403054613968391022558764428920771666069942700842508993
type: snfs
size: 245
skew: 1.86441
c0: 42
c6: 1
Y1: 38126967124946768663101433365298971410432
Y0: -1789940649848551
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 5K
[code]
Q=20M 11483
Q=80M 8730
Q=150M 6265
Q=250M 4660
Q=350M 4104
[/code]
Suggesting a sieving range of 20M-400M with a target number of relations = 460M.[/QUOTE]

C229_151_42 appears to producing at a prodigious yield, far greater than my test sieving results above. So high that I find 14e’s results difficult to believe.

Is there an issue with 14e? Lots of dups? Inspection of the poly file from 14e shows nothing obvious.

[QUOTE=swellman;487344]C229_151_42 appears to producing at a prodigious yield, far greater than my test sieving results above. So high that I find 14e’s results difficult to believe.

Is there an issue with 14e? Lots of dups? Inspection of the poly file from 14e shows nothing obvious.[/QUOTE]

Are you sure that your test sieving was over 5k rather than 2k ranges?

I have run

[code]
/work/math/gnfs-lasieve4I14e snfs -r -f 150000000 -c 5000
[/code]

and see 6597 relations by Q=150002063

[code]
total yield: 15968, q=150005021 (0.11933 sec/rel)
[/code]

is quite close to 5/2 of the claimed yield

I think I see what may have happened - the previous job I test sieved was C167_M31_k33, a GNFS job. Test sieved on the -a side. May have then immediately used the same scripts to test sieve C229_151_42. Embarrassed apologies.

Thank you for taking this uglier than it should be job.

C241 from the OPN MWRB file with OPN weight nearly 24K.
[CODE]n: 1465198448177965428772026990227075055702727441032985216293696461981941574813770882021969879133562225263889540648065878923236437280161477935898854454731228974338074953129161253134126152495378305301918303763757927109426114532655728650934645831
# 13829^59-1, difficulty: 248.45, skewness: 6.73, alpha: 0.00
# cost: 7.37407e+18, est. time: 3511.46 GHz days (not accurate yet!)
skew: 6.732
c5: 1
c0: -13829
Y1: -1
Y0: 48920323413279685134888105908255791411939427791441
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 95
rlambda: 2.7
alambda: 3.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 6484
60M 7328
100M 8315
150M 7586
200M 7368
300M 6913
400M 6279[/CODE]

[QUOTE=swellman;487376]I think I see what may have happened - the previous job I test sieved was C167_M31_k33, a GNFS job. Test sieved on the -a side. May have then immediately used the same scripts to test sieve C229_151_42. Embarrassed apologies.

Thank you for taking this uglier than it should be job.[/QUOTE]

Confirmed the above did NOT happen. Reran C229_151_42 for 5K with Q=20M on the -r side and got 11483 relations. Odd. Maybe it is machine or siever dependent? I’ll rerun the test sieving this evening on another machine/environment. All my boxes are Win64, if that matters.

[b]QUEUED AS C212_157xx799_13[/b]
C212 from the OPN t600 file.
[ a.k.a. Phi_13(Phi_31(11)/50159/2428541)/79/<p30> ]
[CODE]n: 28074502122564319908979181531967537616095668707384454473748919573561082001884566015915909261090700889679832915180616153494785635778300687649218819936786961125157204537625400997331224951086304617912441364997580901
# 157571957584602258799^13-1, difficulty: 242.37, skewness: 1.00, alpha: 3.10
# cost: 4.612e+18, est. time: 2196.19 GHz days (not accurate yet!)
skew: 1.000
c6: 1
c5: 1
c4: -5
c3: -4
c2: 6
c1: 3
c0: -1
Y1: -157571957584602258799
Y0: 24828921817043693312917600278892972922402
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 61
mfba: 61
rlambda: 2.6
alambda: 2.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 12319
60M 10064
100M 8778
150M 6902[/CODE]

[QUOTE=swellman;487408]Confirmed the above did NOT happen. Reran C229_151_42 for 5K with Q=20M on the -r side and got 11483 relations. Odd. Maybe it is machine or siever dependent? I’ll rerun the test sieving this evening on another machine/environment. All my boxes are Win64, if that matters.[/QUOTE]

Repeated this exercise on another machine with the [url=http://www.mersenneforum.org/showthread.php?t=18043]
newer ggnfs sievers[/url]. Got 23767 relations on a 5K block of Q. I knew the newer sievers were faster but had never noticed such disparity in yield. Mystery solved, and I’ll not use the old sievers again!

[b]QUEUED AS C202_31_173[/b]
C202 from the OPN t600 file.
[CODE]n: 2905727676062406581210143813463355281321549043490114270159566965555133147925016922068597211500273316200934979655112275928267750162727044710845265351725732582843332610215496302023194109196714634798893557
# 31^173-1, difficulty: 259.50, skewness: 1.77, alpha: 0.00
# cost: 1.70111e+19, est. time: 8100.53 GHz days (not accurate yet!)
skew: 1.772
c6: 1
c0: -31
Y1: -1
Y0: 17761887753093897979823770061456102763834271
type: snfs
rlim: 268000000
alim: 536000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 94
rlambda: 2.6
alambda: 3.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
30M 10818
90M 9676
150M 8316
250M 7390
350M 7003[/CODE]

[b]QUEUED AS C191_295xx029_13[/b]
C191 from the OPN t600 file.
[ a.k.a. Phi_13(Phi_3(Phi_29(13)/1973/2843/3539)/3/11959/85093/79236309623407)/<p32> ]
[CODE]n: 12794062033878655457450355776266486437430348094623888074791572090516980553375503615389937683920201291889580924137859987844778415030061375032797695148998297559103483481688024256497772362510753
# 2959025653654433029^13-1, difficulty: 221.65, skewness: 1.00, alpha: 3.10
# cost: 8.81455e+17, est. time: 419.74 GHz days (not accurate yet!)
skew: 1.000
c6: 1
c5: 1
c4: -5
c3: -4
c2: 6
c1: 3
c0: -1
Y1: -2959025653654433029
Y0: 8755832818985044651391268463446114842
type: snfs
rlim: 17000000
alim: 34000000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.5
alambda: 2.5[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
6M 9836
10M 8908
20M 7450
40M 5587
50M 5081[/CODE]

The best poly so far, for the C174_M127_k24, at 50% complete with CADO.
Is this good enough? Test sieving with some unoptimized param gave yield 8160 @6M, but i am not sure i did this right :-(

[CODE]
n: 94410615373218704797201510125651849712559525623382519147033843966374414757318643595714477201887765034604269728700950434464990003242159016268314282962617716190928317011619566657
Y0: -7471849389251086201749091300586895
Y1: 708649660173940995547
c0: 2621705914649230171819209755822160165162
c1: -993914513963741328984046025976199
c2: -1358186992798631904082561818
c3: 265509778204990369114
c4: -243054615251784
c5: -12161880
skew: 2530302.065
# lognorm 53.49, E 47.81, alpha -5.68 (proj -2.31), 3 real roots
# MurphyE(Bf=1.00e+07,Bg=5.00e+06,area=1.00e+16)=1.30e-13
# Average exp_E: 47.62, average E: 47.81
[/CODE]

[QUOTE=kosta;487728]The best poly so far, for the C174_M127_k24, at 50% complete with CADO.
Is this good enough?[/quote]

That looks a perfectly reasonable polynomial.

Test-sieving results are only meaningful if you list the limits and the command line used: with

[code]
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
alambda: 2.6
rlambda: 2.6
alim: 268000000
rlim: 268000000
[/code]

I get

[code]
> ./gnfs-lasieve4I14e -a M127_k24.gnfs -f 268000000 -c 999
total yield: 1638, q=268001011 (0.34965 sec/rel)
> ./gnfs-lasieve4I15e -a M127_k24.gnfs -f 268000000 -c 1000
total yield: 3824, q=268001011 (0.21752 sec/rel)
> ./gnfs-lasieve4I16e -a M127_k24.gnfs -f 268000001 -c 999
total yield: 8517, q=268001011 (0.23832 sec/rel)
[/code]

so, unless you tell me not to in the next day, I will queue this on 14e (it's much less efficient than 15e, but the queue is much shorter so it will get done quicker)