[QUOTE=RichD;496102]I used most tricks to squeeze out more yield but couldn't get a decent yield. I am not too familiar with 32-bit jobs or 15e jobs unless they fall out nicely. That is why I try to avoid them. I guess this is the place to seek assistance. I was going to shelve this number (for now) because other potential 32-bit jobs were more important in the food chain. :-)[/QUOTE]

Try 32/64, and 32/92-64 (92 on the a side). I've found fastest performance (though not best yield) with mfba =3*lpba -4. 93 could be tested also.
I use a rule of thumb that going up an LP requires 70% more relations, so sec/rel should be approx. 1/1.7 the time of 31LP. If I try a hybrid 31/32, I aim for 30% more relations than I would have for the smaller LP size alone.
If you'd like me to do some test-sieving, I'll have time (and interest) Sunday. I'm interested to test-sieve one of these large-coeff SNFS candidates, so if you wish I'll tackle it then and post a writeup about test results.

I fixed both of my typos for C240_4603759_37_minus1, it's clear that I didn't even read back what I wrote...

With less than a third of the WUs returned at the time of this writing, the extrapolation code suggests 15M-98M for C162_785232_11446. That seems quite different from the previously suggested 15M-70M, is that natural ?

[QUOTE=debrouxl;496145]With less than a third of the WUs returned at the time of this writing, the extrapolation code suggests 15M-98M for C162_785232_11446. That seems quite different from the previously suggested 15M-70M, is that natural ?[/QUOTE]


Test sieving results (for 1000q ranges):
20M 2744
30M 1899
40M 2640
50M 2247
60M 2693
70M 1998
80M 1997

~ 2.3 rel per special-q in average



So, I expected at least 120M raw relations from 55Mq range (15M-70M). Don't know what is wrong, maybe some of the BOINC clients returns zero results or smth like this?

Getting caught up with my notes after a weekend of out of town company. It appears some wires got crossed with the job C240_4603759_37. I was explaining I couldn’t get a good set of parameters to use for a 31-bit job on 14e. I accidentally stumbled upon straight forward parameters for 15e, which I suggested. Then I thought someone was going to look into placing it on 14e as a higher bit job. No one could read my crypt message about the bad set of parameters I tried. Now I see the job is queued using the set that didn’t work very well at all. I am questioning whether we can get enough good relations to build a matrix with TD=120 or better using the bad set I had abandoned...

[QUOTE=RichD;496222]Getting caught up with my notes after a weekend of out of town company. It appears some wires got crossed with the job C240_4603759_37. I was explaining I couldn’t get a good set of parameters to use for a 31-bit job on 14e. I accidentally stumbled upon straight forward parameters for 15e, which I suggested. Then I thought someone was going to look into placing it on 14e as a higher bit job. No one could read my crypt message about the bad set of parameters I tried. Now I see the job is queued using the set that didn’t work very well at all. I am questioning whether we can get enough good relations to build a matrix with TD=120 or better using the bad set I had abandoned...[/QUOTE]

I confess I was a bit of a spectator for all this, but we may headed to a happy ending. The C240_4603759_37 sieving job seems to be holding up, with the estimated number of relations = 285M+ unless yield just falls off the table at high Q.

[QUOTE=swellman;496270]I confess I was a bit of a spectator for all this, but we may headed to a happy ending. The C240_4603759_37 sieving job seems to be holding up, with the estimated number of relations = 285M+ unless yield just falls off the table at high Q.[/QUOTE]

It does seem to be working out satisfactorily. Though not anywhere near optimal - but working. I was thinking 32-bit job when I looked at the accumulated relations with Q already at 400M. It should be fine.

My blunder was bigger by grabbing the wrong dataset and claiming the job was completed so all the data can be deleted. Which strike me a bit odd since there are several OPN datasets still in the directory from last April. Why would such a recent job be deleted so quickly??

Thanks for re-queueing a second copy.

[B]QUEUED AS C242_139_72
[/B]
C242_139_72 is ready for SNFS on 15e as a 31-bit job.
[code]
n: 49812362053064629725046788271819961121661892630136477608704147257280255201509988608805502207069017639692371737945719579827750684563019989923911425010255319944874671885435968709590306732416932774169217125964595170656048055165054576999943008867
# 139^72+72^139, difficulty: 260.58, anorm: 1.70e+037, rnorm: -1.06e+049
# scaled difficulty: 262.54, suggest sieving rational side
# size = 7.498e-013, alpha = 0.000, combined = 9.478e-014, rroots = 0
type: snfs
size: 260
skew: 1.0198
c6: 8
c0: 9
Y1: -10463510478998672094480749996152012350160896
Y0: 52020869037289085480011921
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]


Test sieving on the -r side with Q in blocks of 5K:
[code]
Q=40M 8954
Q=70M 7669
Q=120M 7023
Q=180M 5562
Q=250M 5050
[/code]
Suggesting a sieving range for Q of 40-230M with a goal of 240M relations.

[B]QUEUED AS C250_137_86[/B]

C250_137_86 is ready for SNFS on 15e.
[code]
n: 4882551164784256604186779948783602599048970696434654487886215653769921928202591397385975701221784264511324160458011717697125201644164505378282039798548809132479379484554962565368112446345390557569925508388404171272247142238595423180920120766222258903
# 137^86+86^137, difficulty: 266.96, anorm: 2.54e+039, rnorm: 9.47e+049
# scaled difficulty: 268.72, suggest sieving rational side
# size = 9.807e-014, alpha = 1.256, combined = 2.191e-014, rroots = 0
type: snfs
size: 266
skew: 10.8307
lss: 0
c6: 1
c0: 1614134
Y1: -820517673944445067756173565489
Y0: 311504538542350645715503145019022560519520256
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8
[/code]


Test sieving on the [b]-a[/b] side with Q in blocks of 5K:
[code]
Q=40M 7406
Q=70M 7655
Q=120M 5790
Q=180M 5361
Q=250M 4683
Q=350M 5103
Q=450M 4492
[/code]
Suggesting that this Q range be expanded to run 30-460M to reach a target number of relations = 470M.

Sextics usually sieve better on the algebraic side, ie pass -a to the siever. I've run my script to check .polys against it and there's not much in it but the algebraic side should be better. Or you might want to sieve on both sides if the yield drops too much at higher special-Qs.

Chris

[B]QUEUED AS C221_73659281_29m1
[/B]

C221 from the MWRB file with OPN weight of 4129.
[ a.k.a. Phi_29(Phi_5(3541)/5/427001) ]
[CODE]n: 19158844603971388507581221118976089908628871020460215190214530130501056787301285658416765308797970461345035890827495457011414238965357319835361687150733934985985188072358804187765589233828833700538947707920393190325853309
# 73659281^29-1, difficulty: 236.02, skewness: 20.47, alpha: 0.00
# cost: 2.80247e+18, est. time: 1334.51 GHz days (not accurate yet!)
skew: 20.474
c6: 1
c0: -73659281
Y1: -1
Y0: 2168389904330821777632297211238586600401
type: snfs
rlim: 67000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 91
rlambda: 2.7
alambda: 3.6[/CODE]
Trial sieving 5K blocks.
[CODE] Q Yield
20M 11398
60M 8648
100M 7741
150M 6345
200M 6132[/CODE]

[QUOTE=chris2be8;496309]Sextics usually sieve better on the algebraic side, ie pass -a to the siever. I've run my script to check .polys against it and there's not much in it but the algebraic side should be better. Or you might want to sieve on both sides if the yield drops too much at higher special-Qs.

Chris[/QUOTE]

Test sieving of C250_137_86 on the -a side did prove to show better yield. I’ll update my posted poly. Thanks!