[QUOTE=xilman;303808]Excellent!

I had hoped there would be at least one with a very large penultimate factor.

Paul[/QUOTE]

So far it was the only one except for one p68. The rest are in the p50's. (My runs)

[QUOTE=pinhodecarlos;303953]So far it was the only one except for one p68. The rest are in the p50's. (My runs)[/QUOTE]That's not too surprising. ECM had been run to the 2/9 rule. (2/9)*210 = 47 and so p5x can't reasonably be described as an ECM miss. Even a p45, though disappointing, wouldn't be too unreasonable in light of the way in which ECM sometimes gets unlucky.

A batch of numbers in the C235-240 range are presently being crunched to 2t50 in the ECMNET server at 83.217.167.177:8194. Lionel will add them to the RSALS queue in due course. Unless more clients join in the new batch won't be tested for at least another couple of weeks.

Paul

[QUOTE=xilman;303959]A batch of numbers in the C235-240 range are presently being crunched to 2t50 in the ECMNET server at 83.217.167.177:8194. Lionel will add them to the RSALS queue in due course. Unless more clients join in the new batch won't be tested for at least another couple of weeks.[/QUOTE]Note that (2/9)*240 = 53. A t53 test will [b]not[/b] be run unless a great deal more ECM resources can be found. Right now it's easier to acquire SNFS processing than ECM and so the (2/9) rule, which has only ever been a rough guide, has to be relaxed slightly.


Paul

[QUOTE=xilman;303960]Note that (2/9)*240 = 53. A t53 test will [b]not[/b] be run unless a great deal more ECM resources can be found. Right now it's easier to acquire SNFS processing than ECM and so the (2/9) rule, which has only ever been a rough guide, has to be relaxed slightly.


Paul[/QUOTE]

Have you talked to yoyo?

RSALS is soaking a varying fraction of yoyo@home's resources on other numbers :smile:

At the moment, RSALS is not sieving OddPerfect numbers, because the OddPerfect queue of numbers which have received "enough" ECM was exhausted several weeks ago.
As a result, I've turned to other projects for feeding RSALS. For instance, RSALS has split several Aliquot composites, a dozen of GCW composites, and killed all of near-repdigit's best SNFS targets of difficulty < 230 with t50 ECM work (third table of [url]http://homepage2.nifty.com/m_kamada/math/wanted.htm[/url]).
But near-repdigit is not in danger of running out of t50 numbers yet, especially as OddPerfect's queue must have rebuilt somewhat, and as the activity on the RSALS grid has been low since last week-end.

I just managed to start GC_9_217. Matrix was built.

[QUOTE=Batalov;303754]Will do 26669_227[/QUOTE]
This one split 3 ways (and I was able to grab the two factors on the two first parallelly run dependencies! It's nice to have the "latest" msieve):

[CODE]Tue Jul 3 14:32:12 2012 found factor: 888518752606082537319165724001429308533060064413491617456152690273401854243407316079039
Tue Jul 3 14:32:23 2012 found factor: 2132061026377600811841418834204894172503809734573087
# the remainder is 92486883614116431114430062148848947197772142121553285414573012185780980613562181479
[/CODE]

[QUOTE=Batalov;303981]This one split 3 ways (and I was able to grab the two factors on the two first parallelly run dependencies! It's nice to have the "latest" msieve):
[/QUOTE]

Can you share a 64-bit windows version? Was that a tweak from Tom? I can't find the thread where he explained how to run under linux the square root phase in parallel.

[QUOTE=debrouxl;303967]RSALS is soaking a varying fraction of yoyo@home's resources on other numbers :smile:

At the moment, RSALS is not sieving OddPerfect numbers, because the OddPerfect queue of numbers which have received "enough" ECM was exhausted several weeks ago.
As a result, I've turned to other projects for feeding RSALS. For instance, RSALS has split several Aliquot composites, a dozen of GCW composites, and killed all of near-repdigit's best SNFS targets of difficulty < 230 with t50 ECM work (third table of [URL]http://homepage2.nifty.com/m_kamada/math/wanted.htm[/URL]).
But near-repdigit is not in danger of running out of t50 numbers yet, especially as OddPerfect's queue must have rebuilt somewhat, and as the activity on the RSALS grid has been low since last week-end.[/QUOTE]

When are you going to implement the 64-bit linux version of the siever?

I only do linux, Carlos.

I was actually fooling around with the "latest" phrase: this feature (reporting factors as they are found) is in msieve for (I think) at least a year. I remember that some members (who probably wish to be unnamed) declared many times "msieve crashed, so I will stick to using msieve 1.41 until the day I die" or something of that kind. :razz:

GC_9_217 done
 

[code]
prp75 factor: 813570124146057284441426328638840720068581697285028685963112989571715868721
prp76 factor: 2705181517441933056646851213568020509310336819217889232130623343028397534793
[/code]