[QUOTE=xilman;155594]I've just posted the last update of 2008.
[/QUOTE]

Hi Paul,

For some reason none of the factors I sent you a while ago seemed to have made it in your final update for 2008.

3_437-2_437
4_351+3_351
4_352+3_352
4_353+3_353
4_354+3_354
4_355+3_355
4_356+3_356
4_357+3_357

Jeff.

[QUOTE=Jeff Gilchrist;155650]Hi Paul,

For some reason none of the factors I sent you a while ago seemed to have made it in your final update for 2008.

3_437-2_437
4_351+3_351
4_352+3_352
4_353+3_353
4_354+3_354
4_355+3_355
4_356+3_356
4_357+3_357

Jeff.[/QUOTE]

AFAIK, the 4,3+ numbers are all beyond the current table limit (exponent = 350)

[QUOTE=R.D. Silverman;155659]AFAIK, the 4,3+ numbers are all beyond the current table limit (exponent = 350)[/QUOTE]

I didn't realize there was a limit, there is nothing on the web pages that says exponent=350 is the highest value it would take. The 3,2 tables go up to 500.

Just like in Cunningham's tables, the digit size (~complexity) appears to be the imposed limit. If it were up to n<=500 everywhere, then 12^500+[FONT=Times New Roman]ε[/FONT], 11^500+[FONT=Times New Roman]ε[/FONT] etc would be impractical, while 3^500+[FONT=Times New Roman]ε[/FONT] is fine. So by design the top complexity is similar in all tables, e.g. 500*log3 ~= 350*log4. One day, the most complete table will be advanced (I am guessing), or all at once...

The best place to check out a wanted number is [URL="http://www.chiark.greenend.org.uk/ucgi/~twomack/homcun.pl?sortby=snfs"]Tom's reservation page[/URL]

[QUOTE=Batalov;156073]The best place to check out a wanted number is [URL="http://www.chiark.greenend.org.uk/ucgi/~twomack/homcun.pl?sortby=snfs"]Tom's reservation page[/URL][/QUOTE]

Thanks. I started accidentally extending the table before I realized there were still composites left so I stopped after the ones I listed above and started working on what is left. I figured since I did the work, they might as well be reported.

[quote=xilman;120955]Another update to the tables has just been uploaded.

There are 52 composites remaining in these tables, so extensions to some of them will be added shortly.

Over the last couple of months I've found a few thousand small factors from the extensions, and several dozen relatively large ones. Chad Davis has also helped enormously by factoring dozens of numbers in the C70-C100 range by mpqs. Thanks Chad![/quote]
The name of the game is to get the number of composites under [B][SIZE=3]50[/SIZE][/B]. THEN the tables will be extended.

..this sounds easy 'nuff... :whistle:

Response 666: ECM is still worthwhile
 

If you're cracking the larger composites, don't be shy about putting some B1=11e6 and B1=43e6 curves into them.

Why would I say this? The last two factors I pulled were a p51 and a p43.:smile:

BTW, this is post #667, and response #666. Normally I don't care, but it looks really nice to see the [U]666[/U] by the link for this thread.

[QUOTE=FactorEyes;157057]If you're cracking the larger composites, don't be shy about putting some B1=11e6 and B1=43e6 curves into them.

Why would I say this? The last two factors I pulled were a p51 and a p43.:smile:

BTW, this is post #667, and response #666. Normally I don't care, but it looks really nice to see the [U]666[/U] by the link for this thread.[/QUOTE]Indeed. Another ECM factor came in yesterday. It is a p45 from 11^7-7^11 C193 and the cofactor is prime. The server is allocating tasks with B1=11e6

Paul

[quote=FactorEyes;157057]
Why would I say this? The last two factors I pulled were a p51 and a p43.:censored:
[/quote]
While it is surely true for larger composites, for a snfs-179 I wasn't terribly disappointed having pulled a p45 (so far, the smallest fish out of ~20 runs). It only took one 8-cpu-night.

For snfs-200's, throwing a t45 at 'em is a good thing to do.

[QUOTE=xilman;157376]The server is allocating tasks with B1=11e6

Paul[/QUOTE]
Does the server weight work unit allocation according to the SNFS/GNFS complexity of the number?

The reason I ask is that I once left a few cores in fire-and-forget ECMNET mode, and returned a few days later to discover that 8 core-days had been sunk into a number I could have SNFS'ed in less time. Actually, this has happened more than once.

I should have set the length between server refreshes on my clients to just a couple of hours, as the allocation tends to hand out the same number to each client requesting work in the same given time window. This behavior was known to me, so I should have thought to set small, varying refresh intervals to stagger the timing of the client work requests.

Does the allocation algorithm weight assignments toward larger numbers?

[QUOTE=FactorEyes;158860]as the allocation tends to hand out the same number to each client requesting work in the same given time window. ...

Does the allocation algorithm weight assignments toward larger numbers?[/QUOTE]

The ecmserver can be configured to avoid handing out the same assignment to nearly everybody. The candidates are sorted according to some preference scheme, but then the first candidate is given with probability "p", and if not selected the next with probability "p" on down the list. By making p a small number - 5 to 15 percent - the assignments get spread out.

The various sort orders can also be selected in a probability fashion - making 10-35% of the assignments completely random also spreads the work out. There are sort orders to prefer shortest numbers, prefer least worked numbers, and prefer least combination - selecting some weighted combination of these also spreads the work around.

There isn't an option to weight the larger numbers more heavily, but it is possible to prevent some numbers from getting suddenly far ahead of others, so that occasional administrative action to inactivate a number is good enough to avoid the problems you describe. Some of this configuration flexibility was added when rogue rewrote the ecmnet server a few years ago.

That all said, I don't know if Paul has actually configured this server to spread the load around.