[QUOTE=RichD;357201]I was going to get the rest of the .dat file to run with you but noticed it is already removed from the server. I also see Greg is running this number so he'll have the results in a few days. I guess he got impatient and needed to free up some space on the server.[/QUOTE]
I'm kind of impatient myself. This job is tying up the machine I had running all my others for both ecm and sieving, so I spent today changing everything over to another machine. I finally have the others running ecm again, while the main one works on the c166. Now it shouldn't bother me to "let it be.":smile:

It would be more than frustrating to try to upload the .dat file somewhere - my upload speed is severely limited. It may only be 1/10 my download, which took several hours.

If you guys can't wait for my "slow butt," that's perfectly fine. If it was factored faster by someone else, it really wouldn't upset me in the least. It would free me up that much sooner. But, if it can take a while, I should have something in about 287h31m...

c167 @ i5160
 

2^4 * 3 * 31 * ... * c167

Excellent! I was still at 243h30m. I will have to seriously rework some things before I try anything that large again.:sad:

By how far did we miss the probability of finding the p(rp)63 during ECM?

And, a sincere "Thank you" to whomever "bailed me out.":smile:

Greg did the post-proceasing as shown at the bottom of [URL="http://escatter11.fullerton.edu/nfs/crunching.php"]this page[/URL].

We barely got started toward t60 so we were just past t55. Not a near miss by any standards.

Sorry. I somehow completely missed that you were running it.

[QUOTE=frmky;357462]Sorry. I somehow completely missed that you were running it.[/QUOTE]
That's quite all right! I was in over my head. It took me all day to d/l the relations and then find out I really didn't have the required memory. Even after increasing the memory it was looking like a couple weeks to finish it.

Thanks for all...

c128 @ i5164
 

2^3 * 3 * … * c128

The C128 has been fully ECMed. A moderately easy GNFS task for an individual for a few days. I have moved on to assist in a larger project.

[QUOTE=RichD;357474]2^3 * 3 * … * c128

The C128 has been fully ECMed. A moderately easy GNFS task for an individual for a few days. I have moved on to assist in a larger project.[/QUOTE]
I'll try to knock it out "overnight" - let's see what happens...:smile:

[QUOTE=RichD;357474][COLOR="Red"][B]2^3 * 3[/B][/COLOR] * … * c128

The C128 has been fully ECMed. A moderately easy GNFS task for an individual for a few days. I have moved on to assist in a larger project.[/QUOTE]*cough* *cough* Hey, don't do that when I'm taking a drink! Did anyone else notice what happened just 2 lines after the big gnfs c166? That's right:[code] 5161 . c178 = 2^4 * 3 * [COLOR="Green"]31^2[/COLOR] * [COLOR="Blue"]p173[/COLOR][/code]:party:
Talk about extraordinary luck! It's just a shame that the '3' was there. Without it, there was a chance it could have avoided 2^3 * 3.....but you still can't argue with that escape! :cool:

An interesting find this morning:
[code]
GMP-ECM 6.4.4 [configured with GMP 5.1.2, --enable-asm-redc] [ECM]
Using B1=43000000, B2=240490660426, polynomial Dickson(12), 2 threads
Done 1/20; avg s/curve: stg1 568.2s, stg2 161.3s; runtime: 737s

Run 1 out of 20:
Using B1=43000000, B2=240490660426, polynomial Dickson(12), sigma=2256742655
Step 1 took 569323ms
Step 2 took 161338ms
********** Factor found in step 2: 23725821245086537435130711983948448089958946186929
Found probable prime factor of 50 digits: 23725821245086537435130711983948448089958946186929
Probable prime cofactor 681239635497746997442332642051682014873561471115153741181581865369559689620039 has 78 digits

****************************************
[/code]on one machine, and:
[code]
Sat Oct 26 07:49:17 2013 prp50 factor: 23725821245086537435130711983948448089958946186929
Sat Oct 26 07:49:17 2013 prp78 factor: 681239635497746997442332642051682014873561471115153741181581865369559689620039
[/code]on another.

In case there is interest, the following numbers of curves had been reported back to the ECM controlling machine at the time of the find:
[code]
300@2e3 814@11e3 4815@5e4 972@25e4 1820@1e6
4020@3e6 4660@11e6 1400@43e6 148@11e7 56@2e8
[/code]

Another index down and now there's a c149 at i5156.

Just a protocol query - should a post be made each time another index is factored, or is it enough to inform the db?

My system is set to automatically submit the factors and it may be quite some time before I notice, so I can post here.