135676061629^19-1 is done: [code]
p68 factor: 79635064094310037830645808630238979916842816602955253387792094206661
p122 factor: 24278112974759485763933791981097601121853224166709762343101936275633631974531044244600392566770714905096375091798556447233
[/code]
There are a few numbers left in the most wanted list that are small enough for me to do. So reserving:
151068118561^19-1

Chris

53041017196666952234619819994982127672443220243418249007541741030212106804476059^3-1 is done: [code]
p64 factor: 1083000123107068270733009827376476882510958865270189171822077137
p94 factor: 1091944940457896832937775063909880834458528001568212121577251753071393980783500894064924253967
[/code]
And reserving:
6411020322582811536531430904856859167136309271498396192913284709873455928246577^3-1

Chris

321381569252585866953628783126948367071187906389518216907098417372109834635071531^3-1 is done: [code]
p71 factor: 29032391505219456656574077295856600917457813817735894170745004802770829
p87 factor: 130655419999791598455282873249671150644436326030004224752728322966413022058935308204173
[/code]
Chris

151068118561^19-1 is done: [code]
p86 factor: 13168251261447086222529106003413582219673091219134273228635229205633692974206401006811
p117 factor: 127521279955406778018268352684989547268937847439690196654027039726274513550542345907805063608735355562846772849462089
[/code]
Chris

6411020322582811536531430904856859167136309271498396192913284709873455928246577^3-1 is done: [code]
p64 factor: 6144947125025633693162221212151808353911892992946890145396846651
p93 factor: 171502932285504588894559496321471476064429992828722843243067496208336947767466817848733178063
[/code]
Chris

1327736012762191^17-1
 

This is a followup to [URL=http://www.mersenneforum.org/showpost.php?p=416689&postcount=352]this post[/URL].

I tried 3LPB with some success. The following polynomial & parameters were used:

[CODE]n: 93279832932678885982491327274510953769646671804250585173949381396533884838015343380578179958902524702743577609136955094165823424785868918382341305541015034575413635998174157065849573034448811318011391066252444362245200432150814809755443305857
skew: 1
c8: 1
c7: 1
c6: -7
c5: -6
c4: 15
c3: 10
c2: -10
c1: -4
c0: 1
Y1: 1327736012762191
Y0: -1762882919585641022025519120482
alim: 90000000
rlim: 90000000
lpba: 31
lpbr: 31
mfba: 93
mfbr: 62
alambda: 3.6
rlambda: 3.6[/CODE]

I ran trial sieve on 5K blocks at various intervals. The algebraic side was the better performer.

[CODE]special-Q
30M 80M 130M 180M 230M 280M 330M 380M 430M 480M 530M 580M 630M 680M
algebraic side ( -a )
4153 2416 1681 1608 1283 1383 1204 1257 1006 925 1071 860 904 566
rational side ( -r )
2324 1264 1090 812 695[/CODE]

With such low yields, and to get to the needed 200M+ relations, one would have to sieve to over 900M using the 14e siever. Not very efficient.
By doing a little sieving on the rational side, say 30-220M, then 45-50M rels could be picked up on that side. Meaning the algebraic side could stop around 550M.
It would appear this is a two part sieving project. Accumulate 75-80% on the algebraic side and the rest on the rational side.

This is all inefficient compared to the traditional yields. Is there something that can be improved upon?

If I understand the parameter meanings correctly, the lambdas are only increased from 2.6 or 2.7 to 3.6 when using 3LP. So, I think rlambda should be 2.7 rather than 3.6, since that side is 2LP. I'm not certain about this, but the CADO helpfiles had an explanation of lambda that leads me to believe this. Surely someone will be kind enough to correct me if I'm mistaken...

With yield that low, I'd use 15e if I were doing it myself; but then, I'd also use 32 bit large primes and aim for 300-320M rels rather than 31bit and 200M. Yield should improve by 75% while only needing ~60% more relations. But I imagine this will be NFS@home, so the 14e queue will be the choice.

A not-quite-relevant data point: I just completed a SNFS-241 with 15e/32, needing 290M raw relations to build a TD 104 matrix of size 8.3M. I didn't try larger target densities.

I was thinking, without looking into it closely, that 32 bit jobs would need around 400M rels. Since the yield didn’t (nearly) double, I abandoned that road. Though I seem to recall it was in the neighborhood you mentioned. Further data points are needed.

rlambda=2.7 is an oversight on my part. Since I rarely work with 3LP jobs it slipped my mind.

In the coming weeks I will try to refine my testing with these suggestions.
Thanks.

Now I am confusing myself. On my other box I found the following parameters in the poly file.
[CODE]rlim: 90000000
alim: 90000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 93
rlambda: 2.6
alambda: 3.6[/CODE]
Not sure which one I used to collect the data points I posted earlier. Arg!

You might want to increase alim as well as using 3LP on that side.

Also consider raising lpba to 32 as follows (that should need about 50% more relations than lpba=lpbr=31): [code]
lpba: 32
lpbr: 31
mfba: 96
mfbr: 62
alambda: 3.6
rlambda: 2.6
[/code]
A related question, here's some output from the siever for a gnfs 101 job: [code]
Thu May 5 17:30:51 2016=>nice -n 19 "/home/chris/lasieve4_64/lasieve4I12e" -F -o spairs.out -v -n0 -a m101-22720408341975460027074353838899663659623294490773487546911374704466493450000974597687616799147775773.job
gnfs-lasieve4I12e (with asm64): L1_BITS=15, SVN $Revision$
FBsize 105499+0 (deg 4), 135071+0 (deg 1)
total yield: 45404, q=1380007 (0.00302 sec/rel)
710 Special q, 1053 reduction iterations
reports: 191668545->21803968->19707101->8139549->4931453->2904500
Number of relations with k rational and l algebraic primes for (k,l)=:

Total yield: 45404
0/0 mpqs failures, 584/49 vain mpqs
milliseconds total: Sieve 40060 Sched 0 medsched 22650
TD 32890 (Init 3600, MPQS 5170) Sieve-Change 41520
TD side 0: init/small/medium/large/search: 910 3690 1110 1650 8120
sieve: init/small/medium/large/search: 2560 10140 1150 5640 2550
TD side 1: init/small/medium/large/search: 430 2410 1160 1350 3030
sieve: init/small/medium/large/search: 1030 5830 1370 5300 4490
[/code]
What does it all mean? In particular can it be used to tell if raising (or lowering) bounds on one side would be desirable? I'm particularly curious about TD side 0 vs TD side 1.

Chris

Thanks for the suggestions chris2be8. Hopefully in the coming days I will get back to this.

I noticed the roadblock files have recently been updated.
The best way to access them are through [URL=http://oddperfect.org]OPN Homepage[/URL] and click on the "Pascal's site" link in the third section.
Because several of the "T-file" names have changed (in the Composites section).