Thanks :smile:
I've erased the raw relations from the server.

[QUOTE=frmky;283431][CODE]prp102 factor: 229934752018663433790816089704455960409496303096129166998814354315006220097834364217532934532047090137
prp104 factor: 21302098099223460477495392045652203308362544303655926143295639698848061306876811138291149137442556871987
[/CODE][/QUOTE]Nice split.

Paul

Taking 347_89_minus1.

Dear frmky,

Could you also do 269_101_minus1? It is already for post-processing and it is a 31 bits integer. I will then pick up 1021_79_minus1 when I finish 347_89_minus1 (less than 88 hours).

Thank you.

Carlos Pinho

[QUOTE=pinhodecarlos;283639]
Could you also do 269_101_minus1? It is already for post-processing and it is a 31 bits integer. I will then pick up 1021_79_minus1 when I finish 347_89_minus1 (less than 88 hours).[/QUOTE]
I'm running 10M590, which will take a week or so to finish.

[QUOTE=frmky;283671]I'm running 10M590, which will take a week or so to finish.[/QUOTE]

I could run it but with 4 cores I think it is a 250 hours task so probably it's better to you to run. I will run next 1021_79_minus1 or 487_83_minus1 and 457_83_minus1 and 431_83_minus1, these three 29 bits tasks can be done in 2-3 days. I think to free rapidly some free space on the server I should do the 29 bits tasks and then the 30 bits task.
I suppose Mathew wasn't expecting that his integer would take so long so I'll wait another day to see if he would like to do a 29 bits task instead of a 30 bits task.

Carlos

[QUOTE=Mathew;282483]debrouxl,

I would like to reserve 257_97_minus1 (currently downloading).[/QUOTE]

[CODE]prp71 factor: 21837843537095360107718053007588997704684560651993129964159135043469783
prp121 factor: 1199357456843287866292080431795712729888397763772511262981033044745863148795425274475123907966991324066912658540610083631[/CODE]Results have been added to the factordb

Thanks, Mathew :smile:
Server cleaned up, and while at it, moved 251_97_minus1 to the "postprocessing" state.

[QUOTE=debrouxl;284045]Thanks, Mathew :smile:
Server cleaned up, and while at it, moved 251_97_minus1 to the "postprocessing" state.[/QUOTE]

You can also move 347_89_minus1 to "postprocessing" state.
Please reserve 487_83_minus1 and 457_83_minus1.

Carlos Pinho

Done :wink:

In several days, "20003_245" (near-repdigit, SNFS 245, 31-bit LPs) ought to be ready for post-processing by fast computers. If it's not, I'll expand the range of q values a bit.
(don't pay attention to the indications of the crunching.php page for this number: it was manually re-queued after the DB crash, and has more than 13.6e9 bytes of raw relations at the time of this writing)
When I queued it to RSALS, it had received t55 with curves at B1=11e7 + nearly another t55 with curves at B1=26e7, so we'd be very unlucky and unhappy if it turned out to be psmall * plarge :smile:


On a general note: wblipp and I are happy that in the current state of things, there's sufficient ECM power to keep RSALS fed with OddPerfect composites which have received ECM up to 2/9 of SNFS difficulty. ECM misses are reasonably unlikely :smile:

487_83_minus1 is done. 457_83_minus1 is running. Reserving 1021_79_minus1.