135_128 is done:
p69 factor: 348018109213360124437028764970321873645281216434759709116828615883969

Taking C173_129_85 next.

Taking Fib(1301) on 15e once it has completed sieving.

Taking C225_140_138 next.

C165_4635303278743_17 factored
 

112 hours to solve a 11.8M matrix using -t 4, w/ TD=120. (TD=124 failed)
[CODE]p73 factor: 1703685403004238969793162360053116148856490928614889903426193039551381599
p93 factor: 148032584024016230812417741348656584090944625815567033182897029850437966490048194222503837171[/CODE]
[url]https://pastebin.com/Rqffx6S7[/url]

L3795a complete
 

[code]
Mon Sep 25 21:44:29 2017 p83 factor: 38314808675517428000311182505353643939012082834024431260359693819127495591684528811
Mon Sep 25 21:44:29 2017 p94 factor: 2739094758850798772599221192776420786788357000941267841549744480596697476686405580317580832801
[/code]

130.4 hours on 7 threads E5-2650v2 for 15.51M matrix at density 136 (138 didn't work). Log attached and at [url]https://pastebin.com/b2Pp3JRT[/url]

Taking C172_146_97, ETA Monday morning (actually ETA Friday night after going-home time)

Taking C189_4052490063499_17 next.

As info:
C173_129_85 - ETA - 2 days
C225_140_138 - ETA - 2 weeks
(19.75M matrix w/ TD=144)

Taking F1585 (eta morning of 5 October)

C185_1511140989109_17 (14e)
 

Hi guys, reserving C185_1511140989109_17.

C173_129_85 factored
 

116 hours to solve a 13.6M matrix using -t 4, w/ TD=140.
[CODE]p56 factor: 86086983998301697516501108333593979507791427403555442271
p117 factor: 190883950677116913600476364502363858918643907209852006644091054606495306144398872299710782478172931777388654692254863[/CODE]
[url]https://pastebin.com/TazsXKYS[/url]

As info, C165_4635303278743_17 is [url=http://www.mersenneforum.org/showpost.php?p=468550&postcount=2139]done[/url].

Update:

- C202_137_75 (14e/33) matrix will be checked for viability for first time on Oct 5
- Fib(1301) will start sieving on Oct 7
- F1847 will be factored on Oct 9

C185_1511140989109_17 (14e)
 

[URL="http://www.factordb.com/index.php?id=1100000000127909141"]C185_1511140989109_17[/URL] is factored.
[CODE]Sat Sep 30 06:07:33 2017 p61 factor: 3195075354983333018993072212302910626648062180336533014824431
Sat Sep 30 06:07:33 2017 p124 factor: 6866053581418628138975684429050933571964340563592646609306823373430333995948621868010159780548011464787717197933664381967353
[/CODE]LA on the 7.8e6 matrix took ~10.75h using 2x 16 threads on dual Intel Xeon E5-2686 v4 (target_density=120). Log attached and at [URL]https://pastebin.com/yCLxpzUe[/URL].

[QUOTE=richs;468193]Reserving 113990869481^19-1 cofactor.[/QUOTE]

[CODE]p63 factor: 691943852250245494331837474859115150841911217964535079917595389
p94 factor: 1857829467488952443176634987848181208474543771687198306463004610584465048406462240996943230827[/CODE]

61 hours on 2 threads Core i3-2310M with 4 GB memory for a 4.5M matrix at TD = 130. Log attached and at [URL="https://pastebin.com/3z5qWqDq"]https://pastebin.com/3z5qWqDq[/URL] .

Factors added to Factordb.

[QUOTE=richs;468193]C190_3372531985651_17 is delayed since 4GB of memory on my i3 was not enough for the matrix, and my 8GB machine is finishing a C153 today.[/QUOTE]

C190_3372531985651_17 will be finished in a couple of more days.

Reserving C191_22926121_31 please.

567661^41-1
 

[CODE]
prp61 factor: 3476277099574273472586508884176537529459408288497659437163063
prp130 factor: 5899681971112097138912776580374612821598060300277138549017141312121709240692222463211886422794086139184422913947507253233846026563
[/CODE]

I apologize for the circumstances.

C189_4052490063499_17 factored
 

45 hours to solve an 8.0M matrix using -t 4, w/ TD=132.
[CODE]p63 factor: 114641457989803634490624160851026605567114478238743827949979827
p127 factor: 2203344600433059322486205919457215662495034360676865075054161356334955853233705681423629755994897418669342160211934872143670117[/CODE]
[url]https://pastebin.com/9Wa0uhmh[/url]

Taking C173_130_129 next.

C172_146_97 done
 

[code]
Fri Sep 29 17:10:08 2017 p72 factor: 818610041445214467364775214149472528322943096387261392658948003274279979
Fri Sep 29 17:10:08 2017 p100 factor: 1430293986435778550472478613509436249283933070447776040038556871965350423673053095954828971563693341
[/code]

51.9 hours for 10.16M matrix at density 124 (126 didn't work) on 7 cores E5-2650v2. Log attached and at [url]https://pastebin.com/aVqwRQEE[/url]

C190_3372531985651_17 factored
 

[QUOTE=richs;467010]Reserving C190_3372531985651_17 please.[/QUOTE]

[CODE]p80 factor: 19468330155109623431655360784279286208259306606135024715280715820427677505452477
p110 factor: 68075911493087799792221558938989463052280916753086931192532185422686984023634755786378066720271997153818276071[/CODE]

214.7 hours on 6 threads i7-5500U with 8 GB memory for a 10.5M matrix at TD = 130. Log attached and at [url]https://pastebin.com/BKnwcG31[/url] .

Factors added to Factordb.

C177_4287755796749_17 (14e)
 

Taking C177_4287755796749_17 next, thanks.

150_142 failed with only trivial dependencies found. Starting over with fewer relations.

[PASTEBIN]rvjCSB7x[/PASTEBIN]

Taking L1307

Reserving C159_64171_47

Reserving C223_129_100.

L1307 looks undersieved (31.45M matrix at td=70) so I am putting on extra Q values for it and the other Fibonacci SNFS numbers, aiming for 550M relations.

C161_3613045528091_17 (14e)
 

Reserving C161_3613045528091_17, thanks.

F1585 completed
 

[code]
Fri Oct 6 13:30:06 2017 p62 factor: 30159426692976814405927406310408346500836746699714772458864121
Fri Oct 6 13:30:06 2017 p116 factor: 78108389059698030532381540558874142456535967300376741421906680434497308972601915703781498138124644213987933875655901
[/code]

165.3 hours for 15.38M density-134 (not 136) matrix on 7 cores of an otherwise fairly busy E5-2650v2. Log attached and at [url]https://pastebin.com/5YManJix[/url]

C157_11040 completed - 16 hours for 4.5M matrix(TD=110).
[CODE]prp76 factor: 6791590827367494145678259436891110741209316242646722112133932374461482697653
prp81 factor: 317104909878438442044945578413586866547708850807606774856843340423464912534275343
[/CODE][URL]https://pastebin.com/v8jcyY7k[/URL]

C177_4287755796749_17 (14e)
 

[URL="http://www.factordb.com/index.php?id=1100000000126263010"]C177_4287755796749_17[/URL] is factored.
[CODE]Fri Oct 6 19:34:18 2017 p73 factor: 6529716608313919933504407342336177588331836930596345561175091902797018231
Fri Oct 6 19:34:18 2017 p104 factor: 50972352449527706267095917357752460172695789314185776685132800312445845055152554541492741982726667715467
[/CODE]LA on a 14.38e6 matrix took ~32.25h using 48 cores of Intel Xeon E5-2686 v4 CPUs, target density = 108 (112 failed).
Log attached and at [URL]https://pastebin.com/4whNWVwB[/URL]

C159_64171_47 complete.
[CODE]prp68 factor: 72550354728027210996757930397476747089072100883479851299986903801991
prp91 factor: 1625696096303431330204493472070123147299893867864568084586098426401934556867155723505205299[/CODE]
[url]https://pastebin.com/ZmPrwZtN[/url]

Reserving C213_142_112

[QUOTE=swellman;469285]Reserving C223_129_100.[/QUOTE]

I’ve hit a roadblock - the computer chosen to run this job went flaky. I’m more than willing to run this job once my other reservations are finished (on other machines) but it may be a few weeks before I can start it.

Reserving L4035A (ETA 18 October)

Fib(1847)
 

[code]
prp85 factor: 1121304547118490668256079933472086180194380843388711150106119729666442866599123335769
prp96 factor: 704129261734399016560278313150032628102427875299966178295555961175776733941603118715703920535557[/code]

431782388 raw relations
329865306 unique
TD=126
matrix = 19002586 x 19002811 (8992.1 MB)

C173_130_129 factored
 

126 hours to solve a 13.0M matrix using -t 4, w/ TD=112. (TD=116 failed)
[CODE]p78 factor: 996120478562910590141596510514040577197801698028461532653695431988211881278809
p95 factor: 12993900278582003738452565758169612412896575278772933000255605112048469357208658210225609748389[/CODE]
[url]https://pastebin.com/g19BDMyt[/url]

[QUOTE=richs;468908]Reserving C191_22926121_31 please.[/QUOTE]

ETA approximately 17 October.

[QUOTE=frmky;469052]150_142 failed with only trivial dependencies found. Starting over with fewer relations.[/QUOTE]
Finished.
[PASTEBIN]nXAAgxnb[/PASTEBIN]

Thank you so much for saving us months of single-computer effort!

Taking C161_3613045528091_17 next.

Looks like C192_249541_41 could use a few more relations to get to the minimum. "110+M for 30 bits numbers"

C161_3613045528091_17
 

[QUOTE=RichD;469640]Taking C161_3613045528091_17 next. ...
[/QUOTE]

I reserved it: [URL="http://www.mersenneforum.org/showpost.php?p=469333&postcount=2162"]http://www.mersenneforum.org/showpost.php?p=469333&postcount=2162[/URL]
Looks like the 14e page has not been updated.

Sorry for the delay in updating the page; I am updating it this very lunch-break

As always, extra sieving once you've got to 450M relations doesn't make the linear algebra faster by the amount of time the sieving took. ETA 520 hours on 4 cores i7-4790K for L1307, so first week in November.

C161_3613045528091_17 (14e)
 

[QUOTE=YuL;469333]Reserving C161_3613045528091_17, thanks.[/QUOTE]

[URL="http://www.factordb.com/index.php?id=1100000000126228710"]C161_3613045528091_17[/URL] is factored.
[CODE]Thu Oct 12 13:15:21 2017 p70 factor: 6973758502234253884181929362856224995385676641649925515421567582226967
Thu Oct 12 13:15:21 2017 p91 factor: 2615526656926701787299805440932520462192513375052362998296857110075036721543122390667728507
[/CODE]

LA on the 4.84e6 matrix took 2.4h using 4x Dual Intel Xeon E5-2686 v4 (target density = 128).
Log attached and at [URL]https://pastebin.com/t01fTH5Z[/URL].

YuL: you have some pretty impressive compute resource there! Would you be able to run for ~100 wall-clock hours to deal with Lucas(1321) ?

C224_148_86 factors
 

[code]prp89 factor: 36004488451441119651214513502118979442636734789885920973089090859209192780295366731792917
prp136 factor: 1267270686372475929419863116308088251546931487306166069492255355460668707763455774860254500940743946722371347667053477745796394829918369[/code]
349M unique 32LP relations produced an 18.3M matrix at TD 134.

log at [url]https://pastebin.com/QzrLFYLq[/url]

c226_143_57 is 30% complete, about two more weeks.

[QUOTE=fivemack;469691]YuL: you have some pretty impressive compute resource there! Would you be able to run for ~100 wall-clock hours to deal with Lucas(1321) ?[/QUOTE]

Amazon EC2, 100 hours of 4x r4.16xlarge would cost me ~480$ :-).

Reserving C192_249541_41 please.

[QUOTE=YuL;469693]Amazon EC2, 100 hours of 4x r4.16xlarge would cost me ~480$ :-).[/QUOTE]

Ah! Definitely not asking you to do that, then :)

Taking C227_140_61 next.

C225_140_138 factored
 

About 354 hours (power outage) to solve 19.7M matrix using -t 4, w/ TD=144.
[CODE]p81 factor: 204743040471511957974607832522577158823452984876200257817529201941362845184315697
p145 factor: 2647406304735019701172167099689199866467319081702657342977655939289431878262715543870119797539665236347622085873613993044340283536212695425604817[/CODE]
[url]https://pastebin.com/ULCw6fWK[/url]

C191_22926121_31 factored
 

[QUOTE]Reserving C191_22926121_31 please.[/QUOTE]

Finished quicker than I expected.

[CODE]p93 factor: 914270024491921792401085778556927231150530617854161585172963998054586105241044056026056902827
p98 factor: 23790037067171663886838174425797681923684271024161057724917436107609767438289181684247267006610009[/CODE]

118.7 hours on 2 threads Core i3-2310M with 4 GB memory for a 6.6M matrix at TD = 130. This matrix just fit in 4GB with 98% memory usage. Log attached and condensed version (entire log too big for Pastebin) at [URL="https://pastebin.com/mYM26G1N"]https://pastebin.com/mYM26G1N[/URL]

Factors added to Factordb.

I'm post-processing C213_142_112 with 449159757 relations (I started it with a few relations still pending to be reported to NFS@Home). At first I tried a target_density of 120 (a standard value for me), but it failed to enter the LA step. So I tried it again without specifying a target_density and it has begun LA on 29.7 million dimensions.

Only thing is that it's estimating about 30 days on my i5-4670K to complete linear algebra. Is this to be expected, or is there something I should do to speed it up? I don't have a problem letting it run, just want to know I'm not wasting my time. :smile: I don't think I've done a job this big before.

Log attached.

[QUOTE=Mini-Geek;469875]I'm post-processing C213_142_112 with 449159757 relations (I started it with a few relations still pending to be reported to NFS@Home). At first I tried a target_density of 120 (a standard value for me), but it failed to enter the LA step. So I tried it again without specifying a target_density and it has begun LA on 29.7 million dimensions.

Only thing is that it's estimating about 30 days on my i5-4670K to complete linear algebra. Is this to be expected, or is there something I should do to speed it up? I don't have a problem letting it run, just want to know I'm not wasting my time. :smile: I don't think I've done a job this big before.

Log attached.[/QUOTE]

If not specified, the default target_density (TD) used by msieve is 70. You may want to restart msieve with a TD=116, then 112, etc until msieve successfully enters LA. Or drop TD in increments of 10. It’s up to you but it should be a bit faster than TD=70.

That said, a SNFS 263 is never going to be a one week job on a single machine. Good luck!

[QUOTE=swellman;469885]If not specified, the default target_density (TD) used by msieve is 70. You may want to restart msieve with a TD=116, then 112, etc until msieve successfully enters LA. Or drop TD in increments of 10. It’s up to you but it should be a bit faster than TD=70.

That said, a SNFS 263 is never going to be a one week job on a single machine. Good luck![/QUOTE]

Thanks! I'll try it in lower increments and see what I can get. :smile:

Taking L1321, on the basis of why not bite off more than I can chew in two places at once

:barbie:

C222_143_73 Update
 

I finally got both data files for C222_143_73 combined, filtered and into LA. Job should be done by 3 Nov. The split approach certainly works but it’s fairly unwieldy. And the algebraic file really didn’t add a lot of unique relations to the pot. Combined it was 610M raw/351M unique relations. I’ll post more details when I report the factors.

ETA: Fib 1301 should be done on 20 Nov. 6 weeks to run that job!

C202_137_75 -14e/33 job
 

I think there is a problem with this data file. I’ve downloaded it twice now, with the same results both times. Many, many errors in filtering, and eventually msieve crawls to a halt (but doesn’t crash) during reading relations, somewhere in the high 470M’s.

Remdups doesn’t seem to play well with it either, refusing to hash over 100M relations. These seem to be then discarded by remdups. Remdups also seems to need a DIM of at least 3000 but the highest I can use on my 32 Gb machine without an “out of memory” error is DIM=780. Not sure why that is - memory doesn’t seem to be a problem at least according to Win 10 task manager.

Remdups issues aside, I have always been able to filter data with msieve the old fashioned way, but not in this case.

Any advice?

[QUOTE=swellman;469994]I think there is a problem with this data file. I’ve downloaded it twice now, with the same results both times. Many, many errors in filtering, and eventually msieve crawls to a halt (but doesn’t crash) during reading relations, somewhere in the high 470M’s.

Remdups doesn’t seem to play well with it either, refusing to hash over 100M relations. These seem to be then discarded by remdups. Remdups also seems to need a DIM of at least 3000 but the highest I can use on my 32 Gb machine without an “out of memory” error is DIM=780. Not sure why that is - memory doesn’t seem to be a problem at least according to Win 10 task manager.

Remdups issues aside, I have always been able to filter data with msieve the old fashioned way, but not in this case.

Any advice?[/QUOTE]

I appear to be having a similar issue with the C181_HP2 file. I get to ~187M or so and then msieve basically just appears to churn where the CPU is occupied as expected but there is no disk activity at all related to reading in relations. I haven't tried remdups, but I did redownload the relations file and try again without any success.

I had a similar issue with L1307 - at about 130 million relations in, msieve just hung.

I sorted this out by using 'grep' to filter valid lines out of the file

[code]
egrep '^[-0-9]+,[0-9]+:[0-9a-fA-F,]+:[0-9a-fA-F,]+$' msieve.dat.dirty > msieve.dat.clean
[/code]

which does of course require you to have free disc space equal to about the size of the original uncompressed file.

The files produced by nfs@home do have some peculiarities - there seem to be chunks of gzipped data, some relatively large, in the middle of the result of gunzipping the file.

Do I need to decompress the relations file before doing your grep cleaning step?

[QUOTE=wombatman;470007]Do I need to decompress the relations file before doing your grep cleaning step?[/QUOTE]

Yes, egrep doesn't work on compressed data. But if you're on a Unix machine, gunzip -c msieve.dat.gz | egrep ... | gzip -c will filter the compressed relations file on the fly and recompress the results as they come out, which ought to save quite a lot of disc space.

[QUOTE=fivemack;469999]I had a similar issue with L1307 - at about 130 million relations in, msieve just hung.

I sorted this out by using 'grep' to filter valid lines out of the file

[code]
egrep '^[-0-9]+,[0-9]+:[0-9a-fA-F,]+:[0-9a-fA-F,]+$' msieve.dat.dirty > msieve.dat.clean
[/code]

which does of course require you to have free disc space equal to about the size of the original uncompressed file.

The files produced by nfs@home do have some peculiarities - there seem to be chunks of gzipped data, some relatively large, in the middle of the result of gunzipping the file.[/QUOTE]

Houston, we have a problem. Acting on Fivemack’s expert advice, I finally got the above procedure to work on my Win 7 box (via Cygwin) and it chewed on the file for less than 10 minutes. The uncompressed “dirty” file was 72Gb, the new clean data file was 2.4 Gb. Feeding it into msieve revealed barely 20M relations residing in the data file, and filtering quickly terminated. :max:

Either I need something else in my egrep syntax, or that data file is in bad shape.

Where to go from here?

[QUOTE=swellman;470027]Houston, we have a problem. Acting on Fivemack’s expert advice, I finally got the above procedure to work on my Win 7 box (via Cygwin) and it chewed on the file for less than 10 minutes. The uncompressed “dirty” file was 72Gb, the new clean data file was 2.4 Gb. Feeding it into msieve revealed barely 20M relations residing in the data file, and filtering quickly terminated. :max:

Either I need something else in my egrep syntax, or that data file is in bad shape.

Where to go from here?[/QUOTE]

Looking at it now...

Edit: now download the "clean" version and try again.

[QUOTE=wombatman;469996]I appear to be having a similar issue with the C181_HP2 file. I get to ~187M or so and then msieve basically just appears to churn where the CPU is occupied as expected but there is no disk activity at all related to reading in relations. I haven't tried remdups, but I did redownload the relations file and try again without any success.[/QUOTE]

Try downloading the "clean" version now on the website.

L4035A complete
 

[code]
Wed Oct 18 00:30:01 2017 p67 factor: 1132441062118657988069459361212669262221594775280716204960225056221
Wed Oct 18 00:30:01 2017 p113 factor: 69375058227376378456180740843481764719489673711855146010085448321766090414992352770525385538077508062911060288521
[/code]

146.5 hours for 16.83M density-136 (138 didn't work) matrix on 7 cores E5-2650v2. Log attached and at [url]https://pastebin.com/Qd4ZDnBu[/url]

[QUOTE=frmky;470028]Looking at it now...

Edit: now download the "clean" version and try again.[/QUOTE]

It works! Downloaded the data file and it was clean, no problems noted. Thank you Greg! Did you find the source of the recent data file corruption problems?

This morning I noted that this 14e/33 msieve job successfully built a matrix from 697M raw relations @TD=70, ETA 2450 hrs. Going to try again at TD=90.

[QUOTE=fivemack;470008]Yes, egrep doesn't work on compressed data. But if you're on a Unix machine, gunzip -c msieve.dat.gz | egrep ... | gzip -c will filter the compressed relations file on the fly and recompress the results as they come out, which ought to save quite a lot of disc space.[/QUOTE]

Just a followup that this worked perfectly, and the matrix is now built and due to be finished in ~80-82 hours.

I'll have a go at LA for Lucas(3795) from the 15e queue.

F1321 is done.

[CODE]Fri Oct 20 15:21:14 2017 p83 factor: 69626979775096683234793519356605470432977725247718711475283204582085949484683482861
Fri Oct 20 15:21:14 2017 p142 factor: 9273983418131527085004889529092092748649112068008532668692663079241442154764329300216622766855423715328763455785218354551858057110900877373573[/CODE]

[QUOTE=VBCurtis;470151]I'll have a go at LA for Lucas(3795) from the 15e queue.[/QUOTE]

I see this number is assigned to Greg now; I hadn't downloaded relations yet, so I'll process L5715A from the 14e queue instead.

C181_HP2_4496_313 factors as: [CODE]p72 factor: 455044685066535342888386537868177939233919658162573657240195840480779539
p109 factor: 2707034039704994685277147552030667475551207534457852025229162156962029074134842118345123858267307874230395097[/CODE]

Took approximately 93 hours on 8 threads of a 4930K at TD=130. Log file is attached. Note that I removed all the bits of the log from when I was having issues with the initial relations file.

[QUOTE=VBCurtis;470193]I see this number is assigned to Greg now; I hadn't downloaded relations yet, so I'll process L5715A from the 14e queue instead.[/QUOTE]

Sorry! I didn't see your post.

Taking C227_135_76 next.

C227_140_61 factored
 

202 hours to solve a 15.9M matrix using -t 4, w/ TD=132 (retry attempted).

remdups4 says:
[CODE]Found 407333057 unique, 107319784 duplicate, and 5123 bad relations.[/CODE]
[CODE]p64 factor: 2363437216374631892008045817854362472042164284268501264441285169
p163 factor: 4500044515090371233499785533644219816636397577744124508605030531349524083493905857422716724778952013421629686195984006786912018094572031737066880899100218946318973[/CODE]
[url]https://pastebin.com/v3eQAz43[/url]

L3795B is done.

[CODE]p60 factor: 612348618308220610749728687560942525957030000709170719322741
p119 factor: 18393757860363126409610158230472513454761725030065514049375068114849856624669853089551126227552626332154361336058864361[/CODE]

Reserving C224_122_119 for postprocessing.

Reserving C192_1577431459_23 please.

C226_141_59 is done.

[CODE]p84 factor: 362717407573062759649737199143733658562292627766699815889194128031404204438544404439
p142 factor: 5584640606072561151802930019243122240833798331945858851893157042850138505313340336371766706494184014505008264594637551042137666886143607864541[/CODE]

Reserving 141^62+64^141 on 15e.

c226_143_57 results
 

Log at [url]https://pastebin.com/Dw1swigP[/url]
[code]prp96 factor: 897094747754482045770531544477700088352397640594837413588145052113208015535658806042142533635811
prp130 factor: 5402116304783573647710016304889406303241500724198159102155379461705248829675304254503761226405413342784878208865325882006231555611[/code]
400 hours on 6 threads of a busy i7-5820 to solve a 23.5M matrix that filtering marks as density 84, and LA notes sparse part has density 71. In hindsight, I should have reduced the relations available to filtering until I got a matrix the matched the target-density setting. "top" listed msieve as using 9GB for this matrix.
This was my first 14e/33 job, and 590M unique relations (of roughly 720M raw) were far too many. Future 14/33 jobs should target 650-680M raw relations.

Taking C169_2158316902961_17 next.

[QUOTE=VBCurtis;470459]In hindsight, I should have reduced the relations available to filtering until I got a matrix the matched the target-density setting.[/quote]

I'm not quite sure why you suggest that, rather than increasing the target density (you were running with the default target density 70)

[QUOTE=fivemack;470462]I'm not quite sure why you suggest that, rather than increasing the target density (you were running with the default target density 70)[/QUOTE]

Two possible explanations:
1. After experimenting with a few filtering runs with varying relation counts (see [url]http://mersenneforum.org/showpost.php?p=469386&postcount=1186[/url]), I accidentally forgot to set TD on the full set, saw the matrix was the same size I got from the first filtering run with TD set to 140, and let it run without realizing I hadn't set TD
2. I edit/cut the log to delete the filtering runs irrelevant to the actual job, and accidentally deleted the target-density line.

Based on the post linked above, I'm quite sure I had target_density set during my trials.

However, on my current LA job I tried what I suggested two posts up, and the ETA (after 1% of the job, about 4 hrs) for the smallest matrix I could build with density matching my target density (I used 134) was about 5% longer than the ETA of the matrix I got from the full relation set, even though that matrix is density 104 when much higher was requested.

More specifically, 360M unique 32LP relations built a 19.0M matrix with density 104, while 339M unique relations produced a 17.0M matrix with density 134. The former matrix has a shorter ETA, after letting both run about 4 hrs so the ETA estimate settled down.

Interesting tidbit: 340M unique rels and TD=134 built a 17.9M matrix at density 132, while 338M unique rels and TD = 132 built a 17.1M matrix.
Tidbit #2: 333M unique rels and TD = 140 failed, as did 337M rels and TD = 136.
On this dataset, TD over 134 was nearly impossible to build, and matrices were MUCH more sensitive to input # of rels than I expected. I'll be using TD = 132 as my default for a while, and also running similar experiments on future 14/32 jobs.

Reserving 3408:1671 from 15e.

C169_2158316902961_17 factored
 

84 hours to solve a 11.3M matrix using -t 4, TD=120. (TD=124 failed)

[CODE]p58 factor: 5021316583534880940885444734079370333361932652310779490947
p112 factor: 1214281023169276509053011690942441596344967221458926915648042712870516387083258213891473300070212158822642727987[/CODE]
[url]https://pastebin.com/68hDDQnp[/url]

[QUOTE=swellman;470382]Reserving 141^62+64^141 on 15e.[/QUOTE]

Someone pointed out to me the typo here - this should be listed as [url=http://www.mersenneforum.org/showpost.php?p=469129&postcount=1180]
141^62+62^141[/url]. It’s listed as the above on the [url=https://escatter11.fullerton.edu/nfs/crunching_e.php]15e status page[/url]. Don’t think it matters, just clarifying which number is being factored.

C192_249541_41 factored
 

[QUOTE=richs;469697]Reserving C192_249541_41 please.[/QUOTE]

[CODE]p89 factor: 14966501911337363999273965335107891431399811757821271242482808819872463486296754278310309
p104 factor: 27681371675669264497163936318409255609518822587309867410642154738002909889661684388045387108642200203439[/CODE]

145.7 hours on 2 threads Core i3-2310M with 4 GB memory for a 8.8M matrix at TD = 70 (130 failed due to insufficient memory). This matrix just fit in 4GB with 98% memory usage. Log attached and at [URL="https://pastebin.com/pGqDjNY5"]https://pastebin.com/pGqDjNY5[/URL]

Factors added to factordb.

Reserving 147^53+53^147 cofactor from the 15e queue.

Taking L3295A

Taking phi_3(phi_13(phi_17(5)/409)/(79*13184595687563))/(109*907*528084932161) (labelled as C162_101xx233_3).

L1307 done
 

[code]
Fri Nov 3 00:15:30 2017 p103 factor: 4254700602097170739632329444630310095927804693473524447630393953006285040242712082170765529667370270451
Fri Nov 3 00:15:30 2017 p166 factor: 1449272516404293903772724289520464118891098753118366158456922201038894356519791990348988141509023047507966661277842375737184285484902968282873354858170439222862537991
[/code]

24.37M density-121.5 matrix (same density appeared at td=134 and td=198) took 530.1 hours on 4 cores i7/4790K. Log attached and at [url]https://pastebin.com/qxMDYjc8[/url]

C222_143_73 factored
 

[QUOTE=swellman;469992]I finally got both data files for C222_143_73 combined, filtered and into LA. Job should be done by 3 Nov. The split approach certainly works but it’s fairly unwieldy. And the algebraic file really didn’t add a lot of unique relations to the pot. Combined it was 610M raw/351M unique relations. I’ll post more details when I report the factors.
[/QUOTE]

[code]
prp56 factor: 70474838470398166975430111758099027193695120577835592463
prp166 factor: 1468625064688653877156370107262001424005899973431239516345520907697237497922202126994319199847205557550897168197493851748285511354981016285930910443660224192500563923
[/code]

The rational side resulted in 320166800 raw / 253751246 unique

The algebraic side resulted in 290251467 raw / 232270944 unique

The combined data file had 611639172 raw / 351058209 unique which (finally) built a matrix at TD=100. Higher densities failed. A snipped log file for the combined data file is attached. There were many errors in the filtering stage, not sure if it was corrupt data or something else. I'll hang onto the full log files for now. PM me if you are interested in them.

And yes, a p56 is really annoying...

[QUOTE=fivemack;470946]May I call a moratorium on adding new 14e entries while we have 12 essentially fully-sieved ones without a post-processor?[/QUOTE]

That's my cue.

[QUOTE=Dubslow;470992]I'll trade you my ill-advised OPN sieving reservation in exchange for throwing my cpu at the backlog.
[/QUOTE]

I'll start with C179_128_87, which is he first number without a listed PP-er. frmky, can you confirm that you haven't taken this and/or your numbers are listed as reserved?

[QUOTE=swellman;470685]Reserving 147^53+53^147 cofactor from the 15e queue.[/QUOTE]

Bump.

[QUOTE=fivemack;470946]May I call a moratorium on adding new 14e entries while we have 12 essentially fully-sieved ones without a post-processor?[/QUOTE]

Certainly. I’ve got a few 15e in the oven (ECM) but I’ll hold those back as well until we catch up on that siever. It’s the usual tension between feeding the grid vs. backlog postprocessing.

[QUOTE=Dubslow;470994]frmky, can you confirm that you haven't taken this and/or your numbers are listed as reserved?[/QUOTE]
I so confirm.