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.