Is there a tool that picks off small composites constantly?

[fivemack]

If I progress a sequence a bit and there is a C85 lying around at the end, I'll often find that my factors are reported as 'already found' by the time I've run twenty minutes of ECM to find them.

My assumption is that something picks up <C90 factors pretty much in real-time and processes them with resources comparable to mine (a couple of cores of a Xeon); is that true?

[bsquared]

http://factordb.com/status.php only mentions automated factoring of numbers <70 digits, but maybe there are non-local workers that do similar things with larger numbers.

Just curious... why spend that long on ECM on such numbers?

[yoyo]

Some people have workers running which fetch small composites, factors them and report them back.

[chris2be8]

I'm running a worker factoring 70-79 digit numbers. And I can see composites between 80 and 98 digits get factored fairly quickly.

EdH certainly used to be working in that range. I don't know if he still is though (look in the Other Factordb Problems thread for details).

Chris

[EdH]

Originally Posted by fivemack

If I progress a sequence a bit and there is a C85 lying around at the end, I'll often find that my factors are reported as 'already found' by the time I've run twenty minutes of ECM to find them.

My assumption is that something picks up <C90 factors pretty much in real-time and processes them with resources comparable to mine (a couple of cores of a Xeon); is that true?

I have several machines running from 76 digits up, with the current wave front at 98 digits, so <98 is actually more accurate. Although my "lesser" machines are the ones mostly assigned to composites, all are at least dual core, with a mix of i3, i5 and i7 thrown in. Can you delay submissions of smaller composites, or are you working one line at a time via the db?

Originally Posted by chris2be8

I'm running a worker factoring 70-79 digit numbers. And I can see composites between 80 and 98 digits get factored fairly quickly.

EdH certainly used to be working in that range. I don't know if he still is though (look in the Other Factordb Problems thread for details).

Chris

Per this post, I've been running 96 digits and up. Since you're now including 79 digits, I'll move my lower bound to 80, but that still doesn't help fivemack.

I remember having this same issue when I was running Aliquot sequences against the db instead of via Aliqueit. I guess I'm on the other side of it now. Any suggestions?

[EdH]

Originally Posted by EdH

Per this post, I've been running 96 digits and up. Since you're now including 79 digits, I'll move my lower bound to 80, but that still doesn't help fivemack.

Darn, missed the edit window!

The "96" above should have said "76."

[chris2be8]

What my script has been doing is:

repeat
get smallest 70+ digit composite in factordb
factor that number
until the number is over 75 digits.

So it stops once it sees a number over it's upper limit.

But since the flood of small composites seems to have stopped (touch wood) I'll set it to clear everything below 79 digits each time it's called (it can't factor the 79 digit prime that factordb thinks is composite).

Chris

[EdH]

Originally Posted by chris2be8

What my script has been doing is:

repeat
get smallest 70+ digit composite in factordb
factor that number
until the number is over 75 digits.

So it stops once it sees a number over it's upper limit.

But since the flood of small composites seems to have stopped (touch wood) I'll set it to clear everything below 79 digits each time it's called (it can't factor the 79 digit prime that factordb thinks is composite).

Chris

Since my scripts keep running after a failure, I'll grab the valid 79s that do show up as well then. The scripts are grabbing random composites from 80 (now 79) up to 100 above the lower bound. This may mean that they will hit the invalid 79 every now and then, but if it doesn't take too long to reject it, it probably isn't an issue. In fact, I've probably run it many times already. Hmm, if I aggregate all that time spent, maybe it was an issue...

[vebis]

I have also 80 cores on the small composites for some time now and around the end of last year another 120 for some time. So right now i get a new C98 factored every 2,5 min. It helped a great deal to push the piled up composites from 95/96 to now 98. Summed up around 30k composites at the time i started.

[EdH]

Originally Posted by vebis

I have also 80 cores on the small composites for some time now and around the end of last year another 120 for some time. So right now i get a new C98 factored every 2,5 min. It helped a great deal to push the piled up composites from 95/96 to now 98. Summed up around 30k composites at the time i started.

This is good to know. Hopefully, we aren't colliding too much, but I may enlarge my random number to minimize collisions even more so. I do notice some already factored hits, but not too often and the decline of the numbers tells that we're getting somewhere...

[vebis]

Runtime (H:M:S).....................: 0212:09:08
Time waiting for composites (H:M)...: 0000:20
Composite range.....................: 70 - 98 digits

Report factors for composite #......: 31499
Factored C93 in.....................: 11.9 sec.

New factors added...........: 2 / 36517
Factors already known.......: 0 / 23785
Small factors...............: 1 / 40032

Only small factors..........: 1280
Worker collisions...........: 1797

No composites received......: 8
No results from YAFU........: 3
Results not acknowledged....: 9

Total page requests.........: 64787

There are a lot of collisions. The current scheme of work distribution of factordb is suboptimal at best. There is none. In the early face of factordb is remember some kind of worker which could connect to the db and acquire work and report it back. Don't know of there was some kind of reservation system in place, but it worked to some degree. Now it's just the way it is. If you work on small composites, you'll duplicate work.