I was mistaken, and both those SNFS jobs are already begun on my machines. I have just one fully-ECMed number in my queue, a GNFS-172:
[code]n: 1374250293977900524006825181025041222391785962418349198188752592542556833408706796147779390990626204883096007787340300959668458776589915992783964729160514357520386806570509
# 13*2^905-1 difficulty: 172 combined = 2.82e-013
type: gnfs
skew: 8648943.40
c5: 519480
c4: -51331470267154
c3: 123748321202088763083
c2: 3146916195524283581740271732
c1: 1029230367426047271940304894097130
c0: -23481671787104319711626620457547467037375
Y1: 18303130010379613
Y0: -1214784946281755925158360658293296
rlim: 134000000
alim: 134000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.7
alambda: 2.7[/code]
I run jobs this size as 32LP always; if the grid prefers 31 for this size, I have no reason to disagree. I left rlim and alim the same as post 784; if I ran it myself, I would have let factmsieve choose the bounds.
Since there is substantial risk of the queue running dry, I'll hustle to finish ECM on a couple of jobs near SNFS-240.

14e candidate
 

C248_132_89 (14e)

[code]
n: 19914463491794148695036001655851654463377041639463453015600545713371142924122088156292097281661702696180457526466114808374474869729527721163907160457837723984983338344923197004308980643565869740474071697747526430443589086054097938400375136646692203
# 132^89+89^132, difficulty: 257.32, anorm: 2.30e+037, rnorm: -1.16e+049
# scaled difficulty: 259.27, suggest sieving rational side
# size = 1.282e-012, alpha = 0.000, combined = 1.375e-013, rroots = 0
type: snfs
size: 257
skew: 2.2565
c6: 1
c0: 132
Y1: -7701585589361325209940623087797432152759121
Y0: 64358952668588346584858590445568
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]

[QUOTE=VBCurtis;448632]
[snip]
I run jobs this size as 32LP always; if the grid prefers 31 for this size, I have no reason to disagree. I left rlim and alim the same as post 784; if I ran it myself, I would have let factmsieve choose the bounds.
Since there is substantial risk of the queue running dry, I'll hustle to finish ECM on a couple of jobs near SNFS-240.[/QUOTE]

Thanks for the candidate. It's not so much that the grid prefers 31-bit jobs (though that's probably true for the 14e queue at least), it's that I think it prefers to use resources to best advantage. And from the test sieving I've done with your number, it seems pretty clear that it's best done with 15e, not 14e.

With 15e, it seems to be pretty much right at the border between 31 and 32 bits; it could reasonably go either way. But whether with 31 or 32 bits, 14e is slower. So I recommend we put this one on the 15e queue, which unlike the 14e queue, is not in immediate danger of running out of work.

Would anyone care to verify my test sieving? I'm happy to be corrected if I got it wrong.

I agree that it's quicker on 15e.
Since 15e is not running low on candidate work, shouldn't I just do this one myself? I only suggested help from the grid 'cause it was running out of candidates, and do not wish to add to the queue of interesting-to-other-people work that 15e has now.

I'd still like to begin doing LA for NFS@home, while I prepare a few SNFS candidates for 14e.

[QUOTE=VBCurtis;448693]I agree that it's quicker on 15e.
Since 15e is not running low on candidate work, shouldn't I just do this one myself? I only suggested help from the grid 'cause it was running out of candidates, and do not wish to add to the queue of interesting-to-other-people work that 15e has now.

I'd still like to begin doing LA for NFS@home, while I prepare a few SNFS candidates for 14e.[/QUOTE]

If it goes on in the 15e queue it'll be a little while before it's done, so if you can do it yourself faster and you care about how long it takes, then yes I suppose you could do it yourself.

OTOH, I don't think NFS@Home has any particular definition for what constitutes "interesting" and I imagine that you're not the only one who thinks that numbers of the form k*2^n-1 qualify.

In any case, we can queue this one or not; it's up to you.

By all means, go ahead. Thank you!

[QUOTE=VBCurtis;448632]I was mistaken, and both those SNFS jobs are already begun on my machines. I have just one fully-ECMed number in my queue, a GNFS-172:
[code]n: 1374250293977900524006825181025041222391785962418349198188752592542556833408706796147779390990626204883096007787340300959668458776589915992783964729160514357520386806570509
# 13*2^905-1 difficulty: 172 combined = 2.82e-013
type: gnfs
skew: 8648943.40
c5: 519480
c4: -51331470267154
c3: 123748321202088763083
c2: 3146916195524283581740271732
c1: 1029230367426047271940304894097130
c0: -23481671787104319711626620457547467037375
Y1: 18303130010379613
Y0: -1214784946281755925158360658293296
rlim: 134000000
alim: 134000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.7
alambda: 2.7[/code]
I run jobs this size as 32LP always; if the grid prefers 31 for this size, I have no reason to disagree. I left rlim and alim the same as post 784; if I ran it myself, I would have let factmsieve choose the bounds.
Since there is substantial risk of the queue running dry, I'll hustle to finish ECM on a couple of jobs near SNFS-240.[/QUOTE]

Just a note on the parameters from post 784 - I was once advised by the gatekeepers that it is best to make r/alim = 2^(LP-4). I just round it down to the nearest million. Not sure if this is a general msieve rule of thumb or just BOINC but it's one I've followed ever since.

The other parameters I consistently use with seemingly good results are as follows:

mfbr/a=2*lpbr/a
LP of 30, 31, 32 and 33 = lambda of 2.6, 2.7, 2.8 and 3.0 respectively.

These parameters are used with 2 LP. I never use 3, never really understood how to do it properly.

Nothing earthshattering, just explaining my approach on post 784.

One for 15e queue
 

A lone 15e candidate to consider. The 15e queue is not going dry anytime soon but I won't have another suitable composite for some weeks.

C244_147_47 (-a side seems best)

[code]
n: 8494804663946639610210259101942922812406924568440234407437237901396309872197081862187360541856646153667597408823665004132735402796172909713296145650571113536376373437283906681810354949915953097660658876021449078127677103014961099253609473085649
# 147^47+47^147, difficulty: 245.80, anorm: 1.29e+033, rnorm: -1.13e+055
# scaled difficulty: 255.08, [b]suggest sieving algebraic side[/b]
type: snfs
size: 245
skew: 1.3333
c6: 103823
c0: 583443
Y1: 10382917022245341
Y0: -13500460747057082764996435506735298654081
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]

[QUOTE=swellman;448705]
mfbr/a=2*lpbr/a[/QUOTE]

This is what determines the number of large primes. Setting mfb to lpb*3 is how you set it to 3LP (I've also sometimes seen mfb=3lpb-1 or -2 sometimes, IIRC)

Thanks Dubslow. What values of r/alim and lambda are optimal? Should lpbr=lpba?

I presume the side being sieved (-r or -a) is the side with 3 LPs.

And my biggest question - why do it? In what scenarios is it better than 2 LPs? Just trying to get my arms around the idea. Despite searching, I've never found a good detailed discussion on 3 LPs, maybe I've just missed it.

[QUOTE=swellman;448746]Thanks Dubslow. What values of r/alim and lambda are optimal? Should lpbr=lpba?

I presume the side being sieved (-r or -a) is the side with 3 LPs.

And my biggest question - why do it? In what scenarios is it better than 2 LPs? Just trying to get my arms around the idea. Despite searching, I've never found a good detailed discussion on 3 LPs, maybe I've just missed it.[/QUOTE]
I'm far from even being competent at tweaking these values... probably around the same level as you.

I have no "intuition" whatsoever as to alim/rlim, I've basically only ever used yafu to do NFS, so let it choose for me. I think it's a pretty flat curve near optimal, so as long as you get it within an order of magnitude or so it'll only be a few percent at best difference.

I don't recall that I've ever seen different large prime *sizes* allowed r.e. rational vs algebraic, though you're right that (especially in awkward/strange SNFS cases) I've occasionally seen one side have 3LP while the other has 2LP (though whether or not it's the sieved side I couldn't recall). I believe having both sides set to 3LP is suitable for extremely large jobs, e.g. right at the edge of 16e where it would otherwise be appropriate to move to a hypothetical 17e, but of course we can't -- and double sided 3LP can help bridge a bit of the gap (in the same way that 2LP can bridge some of the gap vs 1LP).

.......Actually ignore that above paragraph. I've just relocated how YAFU treats weird SNFS polys; I believe you'll find it quite informative. Note that indeed both lpb and lp-count (i.e. mfb/lpb ratio) are both tweaked on the sieving-only side for highly skewed SNFS polys (not to mention the appropriate lambdas, as well as the factor base bounds).

[url]http://pastebin.com/PSD8uvcv[/url]

Here's another less informative example from the test sieving code: [url]http://pastebin.com/5Q26ERNg[/url]