[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.

Paul[/QUOTE]

Ok Paul but what about the numbers from [url=http://www.leyland.vispa.com/numth/factorization/cullen_woodall/snfs.txt]here[/url]? How much ecm was done on them? RSALS could easily sieve them and I do the post-processing averaging 3 per day. In a month that table would be done.

[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]

I though the rule was to run ECM for 2/9 of the *time* it would take to factor the number with SNFS (or up to 1/3 if it's near the point where GNFS would be faster).

Chris

[QUOTE=pinhodecarlos;304040]Ok Paul but what about the numbers from [url=http://www.leyland.vispa.com/numth/factorization/cullen_woodall/snfs.txt]here[/url]? How much ecm was done on them? RSALS could easily sieve them and I do the post-processing averaging 3 per day. In a month that table would be done.[/QUOTE]All have been done to the 2/9 level. It's because of that fact that they are present in that file and why some of them have been processed by RSALS already.

With just my own resources, assuming that relatively little is diverted to ECM pre-processing of subsequent candidates, I could also do them all in a month.

If you would like to do some, please let me know and I'll reserve them for you. Each takes about 3-4 days on a modern multicore machine.


Paul

[QUOTE=chris2be8;304041]I though the rule was to run ECM for 2/9 of the *time* it would take to factor the number with SNFS (or up to 1/3 if it's near the point where GNFS would be faster).

Chris[/QUOTE]That's essentially the same thing if the same resources are available for each process. In the present case, the ECM resources are different from the sieving resources are different from the post-processing resources. That changes the optimization problem.

[QUOTE=xilman;304043]All have been done to the 2/9 level. It's because of that fact that they are present in that file and why some of them have been processed by RSALS already.

With just my own resources, assuming that relatively little is diverted to ECM pre-processing of subsequent candidates, I could also do them all in a month.

If you would like to do some, please let me know and I'll reserve them for you. Each takes about 3-4 days on a modern multicore machine.


Paul[/QUOTE]

Right now I can't use the machine to sieve only for post-processing. CPU is getting temps very high even when sieving on 4 cores, I suppose I need to change/clear the thermal paste with a new one. I didn't have time yet to do so.

Looking at GW_4_387 it needs more relations for a 31-bit LP task or not? Are those unique relations or raw?

Those are raw relations, as usual :smile:

At the time of this writing, ~68.1% of the results for the q=30M-117M range have been returned, and the forecast (optimistic, as always, as it's a simple linear extrapolation) is ~210M raw relations. If I want to target 210M raw relations in the end, the range will indeed have to be expanded, but this one is a relatively easy 31-bit LPs task, so ~200M relations ought to do the job.

66667_249
 

I can start 66667_249 if Dmitry or others don't want it.

Go ahead :smile:

66667_249
 

Downloading now.

Edit: I'll also need the .fb file posted.

I would like to reserve 11113_206