mersenneforum.org Is there a tool that picks off small composites constantly?
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

 2018-01-18, 15:25 #1 fivemack (loop (#_fork))     Feb 2006 Cambridge, England 2×3,191 Posts Is there a tool that picks off small composites constantly? 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
 2018-01-18, 15:50 #2 bsquared     "Ben" Feb 2007 3,371 Posts 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?
 2018-01-18, 16:19 #3 yoyo     Oct 2006 Berlin, Germany 11378 Posts Some people have workers running which fetch small composites, factors them and report them back.
 2018-01-18, 16:56 #4 chris2be8     Sep 2009 22×3×167 Posts 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
2018-01-19, 15:18   #5
EdH

"Ed Hall"
Dec 2009

2×23×79 Posts

Quote:
 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
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?

Quote:
 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?

2018-01-19, 17:06   #6
EdH

"Ed Hall"
Dec 2009

E3216 Posts

Quote:
 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."

 2018-01-19, 17:17 #7 chris2be8     Sep 2009 22×3×167 Posts What my script has been doing is: Code: 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
2018-01-19, 22:51   #8
EdH

"Ed Hall"
Dec 2009

70628 Posts

Quote:
 Originally Posted by chris2be8 What my script has been doing is: Code: 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...

 2018-01-22, 08:18 #9 vebis     Oct 2015 22×17 Posts 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.
2018-01-23, 17:10   #10
EdH

"Ed Hall"
Dec 2009

2·23·79 Posts

Quote:
 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...

2018-01-24, 09:46   #11
vebis

Oct 2015

22×17 Posts

Quote:
 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.

 Similar Threads Thread Thread Starter Forum Replies Last Post MattcAnderson Soap Box 1 2017-01-01 15:18 fivemack NFS@Home 3 2016-07-06 04:01 mickfrancis Factoring 2 2016-05-06 08:13 OneOfMany PrimeNet 3 2008-10-29 23:03 Mini-Geek Lounge 6 2008-05-04 03:19

All times are UTC. The time now is 23:54.

Fri Mar 5 23:54:18 UTC 2021 up 92 days, 20:05, 0 users, load averages: 1.29, 1.32, 1.27