P55 (15147...)^5-1 (14e) Factored
 

[CODE]
Mon Nov 14 23:35:18 2016 p91 factor: 1326867178321256303384090380416257073086388611557586709330957713439999203490462755887747801
Mon Nov 14 23:35:18 2016 p97 factor: 1912261560256534191013928466461236046120254349531171260928999659803622464374291860053867616624961
[/CODE]

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

Trying C186_138_79 whilst away from home. Hope it fits 16GB.

[QUOTE=pinhodecarlos;447231]Trying C186_138_79 whilst away from home. Hope it fits 16GB.[/QUOTE]

After all I won't be running this one.

[QUOTE=swellman;447074]Reserving 12+11_250 (14e).[/QUOTE]

[code]
prp61 factor: 5033948904903725475755315464169878865591769388739683777744001
prp155 factor: 26903207248448455899472759261845833072315535344106461325396934859287587280755299417333112208585654841162761042147611169424752060846261420385692203391603501
[/code]

[QUOTE=swellman;447261][code]
prp61 factor: 5033948904903725475755315464169878865591769388739683777744001
prp155 factor: 26903207248448455899472759261845833072315535344106461325396934859287587280755299417333112208585654841162761042147611169424752060846261420385692203391603501
[/code][/QUOTE]

Thanks. Are you still working on C232_126_107?

[QUOTE=swellman;447074]Reserving 12+11_250 (14e).

[QUOTE=swellman;447261][code]
prp61 factor: 5033948904903725475755315464169878865591769388739683777744001
prp155 factor: 26903207248448455899472759261845833072315535344106461325396934859287587280755299417333112208585654841162761042147611169424752060846261420385692203391603501
[/code][/QUOTE][/QUOTE]

Log: [url]http://pastebin.com/n0B6Be5t[/url]

[QUOTE=jyb;447264]Thanks. Are you still working on C232_126_107?[/QUOTE]

Yes. Should be done by tomorrow night.

Taking C241_121_116

C232_126_107 factored
 

[code]
prp102 factor: 325896438723197365327198625830989700424936841396970420774595105527370951140413603085637171277082460339
prp130 factor: 8861356250244287493814456808071562732474531787226056809422329504979138120219758514210985249218227276563172695626314191688341160013
[/code]

[QUOTE=swellman;447315][code]
prp102 factor: 325896438723197365327198625830989700424936841396970420774595105527370951140413603085637171277082460339
prp130 factor: 8861356250244287493814456808071562732474531787226056809422329504979138120219758514210985249218227276563172695626314191688341160013
[/code][/QUOTE]

[url]http://pastebin.com/7ei29eQA[/url]

[QUOTE=RichD;447142]I'll take C189_136_130 next.[/QUOTE]

This should finish up in 30-32 hours.

Taking C187_142_59; ETA is Monday 28 November

C171_933436_i12560 completed - 60 hours for 9M matrix (TD=130).

[CODE]prp61 factor: 2306522953578728992356438308089119394729666909639633383797971
prp110 factor: 68879760555535195515734382304502875771729722215562249029442901711112936749094248875534065234636285317262574449
[/CODE]
[url]http://pastebin.com/h3ipc3Gj[/url]

C251_127_108 (14e) factored.
 

[code]
p107 factor: 20673245043844690677023493825363185886158838025287817538541391720262128196540157552014620829375261204499481
p145 factor: 4090568917654875876889236436179197704100818946832296830740275588273960096191246481245001957334501688083506869682714111602085441272264164518384869
[/code]

Log: [url]http://pastebin.com/Bxtj4Yx4[/url]

Taking C190_141_53

ETA afternoon 30 November

Taking C191_130_79.

C189_136_130 factored
 

[strike]122[/strike] 146 hours for 16.0M matrix with TD=140.
[CODE]p70 factor: 1480269104689163239029592198010997767620457224409402795726546063264453
p120 factor: 237882193114524091432721117798346334140130613730333661987370007057781725807841919063771730620338410613815297309522755117[/CODE]

Re: C191_130_79
 

[QUOTE=RichD;447430]122 hours for 16.0M matrix with TD=140.
[CODE]p70 factor: 1480269104689163239029592198010997767620457224409402795726546063264453
p120 factor: 237882193114524091432721117798346334140130613730333661987370007057781725807841919063771730620338410613815297309522755117[/CODE][/QUOTE]

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

Ack! That should say Re: C189_136_130. I can't edit the subject line!

Taking C194_129_77

Taking 8-7_305 (14e).

127^92+92^127 cofactor (15e) factored.
 

[code]
p98 factor: 99916268507412785728294827229373043076771600841365121126063339775552926084391866535537213844043989
p141 factor: 447137012627347603004693681483203938598568308902979389050913368018422704311080687014451307158819053191521407635375241790143465904296713253737
[/code]

Log: [url]http://pastebin.com/SWWkXcvQ[/url]

C241_121_116 done
 

[code]
Sun Nov 20 20:07:11 2016 p84 factor: 382287215827374516490913335371311113681067958598268402528490562590751491450318848599
Sun Nov 20 20:07:11 2016 p157 factor: 3400940389968403667731539737448696123231575042827382632730660962351212715477766287828544695265357156149504130573165768485381955913367322088713721160358336633
[/code]

70.3 hours for 11.4M density-152 matrix on 6 threads i7-4930K. Log attached and at [url]http://pastebin.com/Cba9U0a6[/url]

[QUOTE=pinhodecarlos;447488]Taking 8-7_305 (14e).[/QUOTE]
Can't manage to build a matrix with TD set to 140 and 130.

P223 (284688...)+1 done
 

[code]
Sat Nov 19 00:32:32 2016 p108 factor: 716905281051458361496599418461912038526878202032358002696049777126802136327392049986279278218827331523325193
Sat Nov 19 00:32:32 2016 p115 factor: 1985539808000448864336423843924848069332363172535981202002959354687318573297260097054958575980797727863937374396257
[/code]

About 376 hours for 26.4M density-110 matrix on 7 threads E5-2650v2 (two intervening reboots)

Log attached and at [url]http://pastebin.com/BhQAzWsm[/url]

[QUOTE=pinhodecarlos;447515]Can't manage to build a matrix with TD set to 140 and 130.[/QUOTE]
Thank you Jon for the extra sieving. Trying once again, I'll came back within 3 hours to share if LA is underway.

[QUOTE=pinhodecarlos;447540]Thank you Jon for the extra sieving. Trying once again, I'll came back within 3 hours to share if LA is underway.[/QUOTE]

Actually, I think that doing more sieving was the wrong choice. The reason the matrix wouldn't build was that there were [I]too many[/I] relations. If you cut it down (I tried filter_maxrels=250000000), then it manages to finish the filtering just fine with td=130.

[QUOTE=jyb;447548]Actually, I think that doing more sieving was the wrong choice. The reason the matrix wouldn't build was that there were [I]too many[/I] relations. If you cut it down (I tried filter_maxrels=250000000), then it manages to finish the filtering just fine with td=130.[/QUOTE]

But shouldn't the matrix be built even when you have oversieved SNFS220? Anyway, I'm already in bed and filtering is still going on and I can see twice message "matrix not dense enough, retrying". Think another hour and LA will be running but I won't be awake to control this.

Ps( using my iPhone to connect to UK home machine).

[QUOTE=pinhodecarlos;447552]But shouldn't the matrix be built even when you have oversieved SNFS220? Anyway, I'm already in bed and filtering is still going on and I can see twice message "matrix not dense enough, retrying". Think another hour and LA will be running but I won't be awake to control this.

Ps( using my iPhone to connect to UK home machine).[/QUOTE]

I don't know the details (I'm sure jasonp could enlighten us), but I know that there are times when too many relations will result in just the situation you're seeing. The solution is to cut down the number of relations a bit.

In any case, I ran the filtering with 250M relations, and it built a matrix without any trouble.

[QUOTE=jyb;447554]I don't know the details (I'm sure jasonp could enlighten us), but I know that there are times when too many relations will result in just the situation you're seeing. The solution is to cut down the number of relations a bit.

In any case, I ran the filtering with 250M relations, and it built a matrix without any trouble.[/QUOTE]

Just stayed talking with my wife whilst awaiting for the LA to start and it's underway with an ETA of 71 hours. Almost midnight here so now I'm going to sleep.

Reserving 3366:i2156.

Reserving 127^93+93^127 cofactor (15e).

Reserving C229_148_70.

I'll take C194_142_70 next.

I must abandon my reservation for 150^122+122^150 cofactor. I had put this on the back burner for a while, then honestly forgot about it for a bit. Since "rediscovering" my reservation I've spent days trying to get this into LA - to no avail. The memory on my biggest baddest machine seems to have degraded (guessing) and I can't process this number.

Planning to experiment with a few of the easier 32-bit jobs, but I from now on I won't reserve a NFS@Home factorization until I've successfully downloaded it and made it into LA.

With regards to 8-7_305 please read this:

[url]http://www.mersenneforum.org/showpost.php?p=447745&postcount=133[/url]

Release C194_142_70, I don't have machine to run this 32 bits tasks.

C169_3366_2156 completed - 68 hours for 8.9M matrix (TD=140).

[CODE]prp77 factor: 25641422047868541686986107525186596561936623541345083157292277889617899142993
prp93 factor: 236987675809269531923788288063277096288560787567038249028484779323136113755266916583339154863
[/CODE][URL]http://pastebin.com/kd8vPCqt[/URL]

C229_148_70 completed - 31 hours for 6.2M matrix (TD=150).

[CODE]prp59 factor: 31341865988592334418593864986093727905704570129434258989293
prp68 factor: 69427046440186584592164280112833479826741033494349863350321991599569
prp103 factor: 1038282752331259626425572544634440815688452884099890210062246681711726738973404015157301258187856223461
[/CODE][URL]http://pastebin.com/UaQJMdWi[/URL]

C237_127_93 (15e) factored.
 

[code]
p51 factor: 297202845182863447345374726482649007673631788341481
p186 factor: 970553391576387434074331675298844842908403605335927176431147146123005272518243346310346847152873192974135025815202444672862587723955494504862775228821614081191765437121091590734210514727
[/code]

Log: [url]http://pastebin.com/0QxTm8Fw[/url]

This is a pretty bad ECM miss. This number should have had more than a t55, which would make missing a p51 [I]very[/I] unlikely.

Trying C196_137_66 (14e).
8-7_305 needs more sieving per [URL]http://www.mersenneforum.org/showpost.php?p=447745&postcount=133[/URL]

[QUOTE=jyb;447859][code]
p51 factor: 297202845182863447345374726482649007673631788341481
p186 factor: 970553391576387434074331675298844842908403605335927176431147146123005272518243346310346847152873192974135025815202444672862587723955494504862775228821614081191765437121091590734210514727
[/code]

Log: [url]http://pastebin.com/0QxTm8Fw[/url]

This is a pretty bad ECM miss. This number should have had more than a t55, which would make missing a p51 [I]very[/I] unlikely.[/QUOTE]

It sustained a full t55 by yoyo@Home. An ECM miss, and an unfortunate one, but are you suggesting a SNFS 251 should have a partial t60 run prior to NFS?

[QUOTE=swellman;447862]It sustained a full t55 by yoyo@Home. An ECM miss, and an unfortunate one, but are you suggesting a SNFS 251 should have a partial t60 run prior to NFS?[/QUOTE]

Well that's a good question. The answer depends on whom you ask. If you follow the standard 2/9 rule for a composite with SNFS difficulty 253.05, then yes, it should have more than just a t55. OTOH, there are threads on this forum where that topic has been debated, with Bob Silverman in particular favoring earlier commencement of NFS. (Though he never articulated any better actual guideline than the 2/9 rule.)

I'll point out that even with just a t55, there's less than a 1% chance that the p51 factor would not have been found. So mostly my comment was intended as a query to verify that this really did receive the ECM work that it deserved.

C272_136_105 at last done (job queued 30/Aug/2016)
 

[code]
Sat Nov 26 18:55:26 2016 p133 factor: 6543705328400180561577911640580975478076882049636590514144600269097437013273310299121836093980225911815544821116466542927850009998397
Sat Nov 26 18:55:26 2016 p139 factor: 3693792848093521850768683089919709265366228631806734580057526850215427168910019282185675375281048261775975004394791990644572376727424390683
[/code]

1254 hours on 48 cores K10/1900 (2x4 grid of 6-thread jobs, on a single four-socket machine) for a 42.8M matrix at density 136; ETA at start was 834 hours, so I'm not sure why it took quite so long, I'd expected it to be done by Thanksgiving.

Log attached and at [url]http://pastebin.com/SGJee32t[/url]

Taking on swellman's reservation for C277_150_122; anticipating this will be another eight-week job.

C194_129_77 done (queued 12/Nov/2016)
 

[code]
Sat Nov 26 21:26:16 2016 p58 factor: 3897537125302085460677693448225794008640755707421364517799
Sat Nov 26 21:26:16 2016 p64 factor: 1145961683293536618698405032748415262288603230517505840692211761
Sat Nov 26 21:26:16 2016 p74 factor: 14059146713659097747811895190173317658713062459220493919197418898669984269
[/code]

112.2 hours on 6 threads i7/4930K for 14.01M density-140 matrix.

Log attached and at [url]http://pastebin.com/TSDMTmg1[/url]

[QUOTE=fivemack;447880]Taking on swellman's reservation for C277_150_122; anticipating this will be another eight-week job.[/QUOTE]

Thank you. Even if my machine was 100% functional, that job was likely too big for me. I mean really, an eight week job with your hardware! :max:

[QUOTE=jyb;447876]Well that's a good question. The answer depends on whom you ask. If you follow the standard 2/9 rule for a composite with SNFS difficulty 253.05, then yes, it should have more than just a t55. OTOH, there are threads on this forum where that topic has been debated, with Bob Silverman in particular favoring earlier commencement of NFS. (Though he never articulated any better actual guideline than the 2/9 rule.)

I'll point out that even with just a t55, there's less than a 1% chance that the p51 factor would not have been found. So mostly my comment was intended as a query to verify that this really did receive the ECM work that it deserved.[/QUOTE]

No worries, I appreciate the comment, and yes I too have watched the debate on this issue over the years. Perhaps the easy answer here is to automatically run at least 1000 curves @t60 on any 15e jobs (or even include 14e/32-bit jobs). These sized jobs take a significant amount of resources to sieve and post process. A week of ECM on a single machine might minimize the chances of a painful miss.

[QUOTE=pinhodecarlos;447860]Trying C196_137_66 (14e).
8-7_305 needs more sieving per [URL]http://www.mersenneforum.org/showpost.php?p=447745&postcount=133[/URL][/QUOTE]

No, this number does not need more sieving. Serge was unaware of the history of this number because you didn't tell him in that other thread. This number was oversieved to begin with, and then I made the mistake of adding even more when you said you couldn't build a matrix, thereby [I]way[/I] oversieving it.

As mentioned previously, it will happily build a matrix if you cut down on the number of relations you give to the filtering stage. I don't know why you then got the "lanczos error: only trivial dependencies found" message during the square root phase, but I would bet that Serge's advice would have been different had he known the history here. Perhaps you cut down the relations too much? I don't know.

In any case, I set the relation count to 285M and the target density to 140, it built the matrix just fine, did the LA, and finished up the square root a few minutes ago.

8-7_305 (14e) factored
 

[code]
p77 factor: 29116441877739317633133712797380504842557969869033106242148507440396074392071
p113 factor: 63366066829731053853461652092984143316950287798436097090891506682649399669464330535532729136493614010242339604361
[/code]

Log: [url]http://pastebin.com/rEG1GRgw[/url]

[QUOTE=swellman;447884]No worries, I appreciate the comment, and yes I too have watched the debate on this issue over the years. Perhaps the easy answer here is to automatically run at least 1000 curves @t60 on any 15e jobs ([COLOR="Red"]or even include 14e/32-bit jobs[/COLOR]). These sized jobs take a significant amount of resources to sieve and post process. A week of ECM on a single machine might minimize the chances of a painful miss.[/QUOTE]

Speaking of those 14e/32-bit jobs, I've been meaning to ask about those: do we have good data on whether it's really faster to run a 14e job with 32-bit large primes vs. making it a 15e job?

I was doing test sieving on an HCN composite recently, and it quickly became clear that with 14e the yield just wouldn't cut it with 31-bit LPs, and even 32-bit was pretty bad. Then I tried it with 15e and it was much better (higher yield [I]and[/I] faster), even with 31-bit LPs. So I naturally wondered whether 32-bit LPs was [I]ever[/I] a good idea with 14e. But it's worth pointing out that in my case the polynomial was a quartic, so that's a special case that might make my results not broadly applicable.

I also ask because those 32-bit jobs are backing up the 14e queue quite a bit. There are fewer people available for post-processing those jobs, and they take much longer, so we've been falling behind a bit. If there were data suggesting that those jobs were faster if done by 15e, then we could better utilize our resources by sending them there.

C191_130_79 factored
 

204 hours for a 17.1M matrix (-t 4) with TD=140.
[CODE]p60 factor: 237590541497454625347345657700836304227298357411185172581463
p132 factor: 224672143024697100615177361238402356089881275921436808490210456927837061493210959320226727155157967486727070560233193950426585503961[/CODE]
I'll be relocating in a few days so I will be off-line for a bit and can't take another job until the end of the week.

[B][SIZE=2]C191_130_79[/SIZE][/B]



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

[QUOTE=jyb;447936]No, this number does not need more sieving. Serge was unaware of the history of this number because you didn't tell him in that other thread. This number was oversieved to begin with, and then I made the mistake of adding even more when you said you couldn't build a matrix, thereby [I]way[/I] oversieving it.

As mentioned previously, it will happily build a matrix if you cut down on the number of relations you give to the filtering stage. I don't know why you then got the "lanczos error: only trivial dependencies found" message during the square root phase, but I would bet that Serge's advice would have been different had he known the history here. Perhaps you cut down the relations too much? I don't know.

In any case, I set the relation count to 285M and the target density to 140, it built the matrix just fine, did the LA, and finished up the square root a few minutes ago.[/QUOTE]

In my case managed to build the matrix with 320M and target density set to 130 but got that error after LA completion, square root stalled.

I did request last week Silverman's help to understand the issue on this SNFS220 where oversieving was in place but no reply so far. I wanted to get some papers orientation to read and study.

Reserving C195_134_124 (14e). Finally managed to get a 32-bit job into LA!

ETA is 268 hours, so ~9 Dec.

[QUOTE=jyb;447939]Speaking of those 14e/32-bit jobs, I've been meaning to ask about those: do we have good data on whether it's really faster to run a 14e job with 32-bit large primes vs. making it a 15e job?
...
I also ask because those 32-bit jobs are backing up the 14e queue quite a bit. There are fewer people available for post-processing those jobs, and they take much longer, so we've been falling behind a bit. If there were data suggesting that those jobs were faster if done by 15e, then we could better utilize our resources by sending them there.[/QUOTE]

I don't know if there is any data on this issue. The main reason I proposed 32-bit jobs was to feed the hungry grid. Not a great reason but when test sieving showed a reasonable yield on 14e/32 for a given poly, nominating it for 14e seemed a better option than just parking it waiting for the 15e queue to decrease, especially when 14e was going dry. But you're right about the 32-bit jobs backing up in postprocessing, so I've abandoned the practice. Sorry if my good intentions led to a bad place.

On an up note, I've managed to start postprocessing 32-bit jobs again on 14e. So I'm hoping to help cleanup the backlog I inadvertently created.

14e and 15e are at present both sieving well ahead of the available linear algebra resources; I should probably move some of my resources into tidying up, but with 128 threads sieving locally I get quite a lot of linear algebra demand before I even look at nfs@home.

C187_142_59 done (queued 26/Sep/2016)
 

[code]
Sat Nov 26 05:02:20 2016 p61 factor: 2150486893617994651425932611447525781809518764361672956127463
Sat Nov 26 05:02:20 2016 p127 factor: 1510439317278894815928048894035007820156795646375424459362259062827696380521191725561534220149929988922800004670897132556417697
[/code]

168.8 hours for 17.17M density-140 matrix on 7 threads E5-2650v3.

Log attached and at [url]http://pastebin.com/jrzRN6e4[/url] (there were 2479 erroneous lines in the relation file, and I ran filtering three times, which is why the log is so long as to require gzipping)

Reserving C249_128_105. ETA morning 7 December

[QUOTE=swellman;447959]Reserving C195_134_124 (14e). Finally managed to get a 32-bit job into LA!

ETA is 268 hours, so ~9 Dec.[/QUOTE]

Which td did you use (share nb of unique relations) and how much memory LA is using?

[QUOTE=pinhodecarlos;447997]Which td did you use (share nb of unique relations) and how much memory LA is using?[/QUOTE]

I used TD=130, 395M unique relations (482M relations at start). Using -t 6 on an older i7.

10.4 Gb used by LA according to windoze.

[QUOTE=pinhodecarlos;447957]In my case managed to build the matrix with 320M and target density set to 130 but got that error after LA completion, square root stalled.[/QUOTE]

Okay, so it sounds to me like the problem was still that there were too [I]many[/I] relations, not too few. Serge should probably be made aware of this discussion, since it seems that always prescribing more sieving when this error occurs can be counterproductive.

And BTW, I apologize for so unceremoniously stealing this number from you. You had asked for more sieving, and before adding more work I wanted to test my theory that it didn't need that. Of course, the only way I could think of to test it was to actually try doing the post-processing myself. And getting an answer meant basically completing the job.

No worries Jon.

[QUOTE=swellman;447960]I don't know if there is any data on this issue. The main reason I proposed 32-bit jobs was to feed the hungry grid. Not a great reason but when test sieving showed a reasonable yield on 14e/32 for a given poly, nominating it for 14e seemed a better option than just parking it waiting for the 15e queue to decrease, especially when 14e was going dry. But you're right about the 32-bit jobs backing up in postprocessing, so I've abandoned the practice. Sorry if my good intentions led to a bad place.

On an up note, I've managed to start postprocessing 32-bit jobs again on 14e. So I'm hoping to help cleanup the backlog I inadvertently created.[/QUOTE]

Yes, it's hard to know the right thing to do here. My gut feeling is that between all the different queues, we should not intentionally use parameters which end up requiring more processor time than could be achieved with better parameter selection. So I'd rather avoid taking a number which could be most efficiently handled on the 15e queue and putting it on the 14e queue just to keep that one from running out.

Now I don't want to sound too doctrinaire about this. The history of NFS has many examples of doing something that's less than optimal as a concession to practicality (e.g. using small factor bases and oversieving in order to make the linear algebra tractable). And it would certainly be nice if we could keep the 14e queue from running out. But it would be nice if we could accomplish that without resorting to jobs that cut down the pool of people willing to do the post-processing.

I think there's still a sweet spot for 14e, jobs that are too hard for most people to do on personal hardware but still are optimal with the 14e siever. We just don't seem to be able to get them pre-tested with ECM fast enough. And along those lines, perhaps it's not that important to do the full ECM testing for these numbers before they get queued (where "full" means whatever guideline is most in vogue (2/9, or something else)). After all, too-few ECM curves is just another form of suboptimal resource usage, akin to using the wrong siever, and if something has to give, then it's not clear that's such a bad one. (FWIW, I haven't been post-processing lately because my cores are all tied up with ECM, getting some HCN numbers ready for the queue.)

In any case, I want to make sure you don't interpret my previous musings as any kind of rebuke. We're all sort of feeling our way to the best practices here, and many on this forum have a lot more experience with this than I do, you included.

Taking C257_128_111 (large matrix, ETA 12 December)

Will try next C194_142_70.

[QUOTE=jyb;448018]Yes, it's hard to know the right thing to do here. My gut feeling is that between all the different queues, we should not intentionally use parameters which end up requiring more processor time than could be achieved with better parameter selection. So I'd rather avoid taking a number which could be most efficiently handled on the 15e queue and putting it on the 14e queue just to keep that one from running out.

Now I don't want to sound too doctrinaire about this. The history of NFS has many examples of doing something that's less than optimal as a concession to practicality (e.g. using small factor bases and oversieving in order to make the linear algebra tractable). And it would certainly be nice if we could keep the 14e queue from running out. But it would be nice if we could accomplish that without resorting to jobs that cut down the pool of people willing to do the post-processing.

I think there's still a sweet spot for 14e, jobs that are too hard for most people to do on personal hardware but still are optimal with the 14e siever. We just don't seem to be able to get them pre-tested with ECM fast enough. And along those lines, perhaps it's not that important to do the full ECM testing for these numbers before they get queued (where "full" means whatever guideline is most in vogue (2/9, or something else)). After all, too-few ECM curves is just another form of suboptimal resource usage, akin to using the wrong siever, and if something has to give, then it's not clear that's such a bad one. (FWIW, I haven't been post-processing lately because my cores are all tied up with ECM, getting some HCN numbers ready for the queue.)

In any case, I want to make sure you don't interpret my previous musings as any kind of rebuke. We're all sort of feeling our way to the best practices here, and many on this forum have a lot more experience with this than I do, you included.[/QUOTE]

Your comments are spot on and well mannered. I've taken no offense so no worries there.

Yes, as to 14/32 I'm now in the 'don't do it' camp. Feeding the grid is not sufficient reason to burden the postprocessing folks, not to mention forcing the sievers to do non optimum tasks. And feeding the masses does not seem to guarantee them staying around - the throughput of NFS@Home has steadily dropped for the last few days, and most of the sieving resources have shifted to 16e (though maybe this is Greg shifting things around behind the scenes). This despite sufficient queue length to keep the grid fed. Maybe there's another challenge somewhere else. Regardless I've spent the last month optimizing my polys/siever choices and I will stick with them. And ECM is still a big part of the process - I've got lots of partial t60 work ahead of me. Happy factoring!

[QUOTE=swellman;448027]Your comments are spot on and well mannered. I've taken no offense so no worries there.

Yes, as to 14/32 I'm now in the 'don't do it' camp. Feeding the grid is not sufficient reason to burden the postprocessing folks, not to mention forcing the sievers to do non optimum tasks. And feeding the masses does not seem to guarantee them staying around - the throughput of NFS@Home has steadily dropped for the last few days, and most of the sieving resources have shifted to 16e (though maybe this is Greg shifting things around behind the scenes). This despite sufficient queue length to keep the grid fed. Maybe there's another challenge somewhere else. Regardless I've spent the last month optimizing my polys/siever choices and I will stick with them. And ECM is still a big part of the process - I've got lots of partial t60 work ahead of me. Happy factoring![/QUOTE]

What is happening is that Gridcoin CPU power is deployed onto SRBase and Syracuse University is on Universe@Home pausing NFS help since 27 Nov. Also there's a challenge going on at SkyNet POGS, SETI.USA and Gridcoin are there.

In the meantime Team Norway and L'Alliance Francophone joined the 16e effort but not enough to reach the daily 80k wus from Syracuse University. 14e and 15e sieve is down due to Syracuse University pause but it will give us time to clean the post-processing until it ramps up again, hoping within a week or so.

[QUOTE=pinhodecarlos;448029]14e and 15e sieve is down due to Syracuse University pause but it will give us time to clean the post-processing until it ramps up again, hoping within a week or so.[/QUOTE]

Good to hear they should be coming back soon.Yes it will be nice to work through some of the backlog. I'm thinking I can postprocess some of the waiting 14/32 jobs but that remains to be seen. Trying to procure a big memory machine (32 Gb) for 15e work but SWMBO has not yet authorized it.

[QUOTE=swellman;448034]Trying to procure a big memory machine (32 Gb) for 15e work but SWMBO has not yet authorized it.[/QUOTE]

Same here. The beast would be:

[QUOTE=pinhodecarlos;448035]Same here. The beast would be:[/QUOTE]

So very jealous of this potential rig. Perhaps one day. :smile:

C177_HP2_4496_300 LA has been started (density of 130) and will done in ~69-70 hours, depending on how long square root phase takes.

Bad news, I've just lost my laptop cooling pad therefore I'll need to release all my reservations until I sort this issue out. Maybe it's a sign to buy new rig. I'm very very sorry.

Reserving C186_138_79 (14e).

C277_150_122 is now actually started (on a six-core rather than trying MPI, since the matrix is 'only' 24.54M), ETA 19th December

C190_141_53 done (job created 09/Nov/2016)
 

[code]
Thu Dec 1 02:17:44 2016 p70 factor: 6650839715565743145568907396759395115662538874843397971656637857558071
Thu Dec 1 02:17:44 2016 p120 factor: 308716298830521025513010926423793555851686262372980749902991593061890504711417249448870590192457763766201567310206184347
[/code]

115.4 hours for 14.20M density-140 matrix on 7 threads E5-2650v2

Log attached and at [url]http://pastebin.com/H6VhK1TZ[/url]

£
 

[QUOTE=pinhodecarlos;448063]Bad news, I've just lost my laptop cooling pad therefore I'll need to release all my reservations until I sort this issue out. Maybe it's a sign to buy new rig. I'm very very sorry.[/QUOTE]

Same model new one costs £55!!! Remember to buy this one by one third of the price.

I'll take C194_142_70 next.

[QUOTE=RichD;448187]I'll take C194_142_70 next.[/QUOTE]

12 days (~14 Dec) 17.7M matrix w/ TD=152.

C177_HP2_4496 Index 300 splits as:

[CODE]p77 factor: 15073733780170275991471285226220957056099524109302522581259526237420527714739
p101 factor: 26346862412952024212670969138665562800723279728780336982192347180271102719081510814813774727561135203[/CODE]

11.36M matrix at density of 130. Took ~90 hours altogether.

Log is attached.

[QUOTE=wombatman;448256]C177_HP2_4496 Index 300 splits as:

[CODE]p77 factor: 15073733780170275991471285226220957056099524109302522581259526237420527714739
p101 factor: 26346862412952024212670969138665562800723279728780336982192347180271102719081510814813774727561135203[/CODE]

11.36M matrix at density of 130. Took ~90 hours altogether.

Log is attached.[/QUOTE]

Log at [url]http://pastebin.com/gbAKnkHU[/url]

Reserving C211_134_110.

Please hold C203_123_89 for me until I finalize some testing with the old laptop cooling pad. I've opened it and made a full dust free clean. Testing CPU temperatures.

[QUOTE=pinhodecarlos;448295]Please hold C203_123_89 for me until I finalize some testing with the old laptop cooling pad. I've opened it and made a full dust free clean. Testing CPU temperatures.[/QUOTE]

LA is underway with an ETA of 7 days since I started it with td=120, failed with td=130. Looks like the cooling pad is OK and working better than before. Bad news my wife doesn't let me buy the Xeon server...:no::cry:

Reserving C189_133_78

ETA 12 December

I will do C228_128_77

C211_134_110 splits as:

[CODE]p61 factor: 1564872259932318288625530755828099955814207574904891144434941
p151 factor: 1790127111361706742891716447305212793991712554883045466496316231594025128100956863652620690460604703735625558717303812317623810200255516288927164544021[/CODE]

Density of 130, Matrix size of 9.49M.

Pastebin: [url]http://pastebin.com/T7nFqzhA[/url]

Reserving C229_128_83.

C249_128_105 done (job created 21/10/2016)
 

[code]
Tue Dec 6 06:02:48 2016 p87 factor: 283056354616963989956811099925181280838872616086344681487973842662478446408168184114761
Tue Dec 6 06:02:48 2016 p163 factor: 1441911157234602219445924272334338835065813897211848942532197488014312531772286470438841923981095691430362183230136688725630654417048608356873664556369665999585153
[/code]

115.9 hours on 7 threads E5/2650v2 for 15.57M matrix at density 130. 465.3Mrel, 373.9Muniq, E=4.771e-14.

Log attached and at [url]http://pastebin.com/m62PPXUf[/url]

C186_138_79 (14e) factored.
 

[code]
p81 factor: 606591674543524511999783313578459266077922922351654070554120540891821263631134653
p105 factor: 402493647691732817846954022528351136942941376208927076847594202786846652068679115008901314676431421004749
[/code]

Log: [url]http://pastebin.com/tSXkMc8U[/url]

I appreciate if you can leave C192_124_97 to myself since I now have less time to remotely control my laptop so I prefer to LA big ones.

Ready to LA are:

C196_137_66
C227_134_112
C207_136_110
C214_140_94
C218_127_79

Just got an error whilst doing LA for C203_123_89 and until I get some reply to support me I'll be starting C192_124_97. Thread about the error in here: [url]http://www.mersenneforum.org/showthread.php?p=448675#post448675[/url]

Reserving C196_137_66 (14e).

Reserving C207_136_110 (14e).

Reserving C214_140_94 (14e).

Reserving C227_134_112 (14e).

Reserving C239_140_53.

C207_136_110 (14e) factored.
 

[code]
p61 factor: 2555146372944539334592474655849356647578025703405127535259757
p147 factor: 331297832621455069305009395097475908087578283559753701740485670673360790591595647983845035434721925828267759176739882109696896990201172770450871817
[/code]

Log: [url]http://pastebin.com/K21UBssT[/url]

C214_140_94 (14e) factored.
 

[code]
p57 factor: 220293335954286432681515799716015819127627225413869706941
p77 factor: 10241055692138502278564163709111221514235095510173512396555906690223293147209
p82 factor: 1465722678220974151388909152873090487215162972069637547268878206642125463259929509
[/code]

Log: [url]http://pastebin.com/3EEJDnyQ[/url]

Reserving P54 (48911...)^5-1 (14e).