mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > FactorDB

Reply
 
Thread Tools
Old 2018-01-18, 15:25   #1
fivemack
(loop (#_fork))
 
fivemack's Avatar
 
Feb 2006
Cambridge, England

7×911 Posts
Default 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 <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?
fivemack is offline   Reply With Quote
Old 2018-01-18, 15:50   #2
bsquared
 
bsquared's Avatar
 
"Ben"
Feb 2007

25·3·5·7 Posts
Default

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?
bsquared is offline   Reply With Quote
Old 2018-01-18, 16:19   #3
yoyo
 
yoyo's Avatar
 
Oct 2006
Berlin, Germany

11218 Posts
Default

Some people have workers running which fetch small composites, factors them and report them back.
yoyo is offline   Reply With Quote
Old 2018-01-18, 16:56   #4
chris2be8
 
chris2be8's Avatar
 
Sep 2009

52×79 Posts
Default

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
chris2be8 is offline   Reply With Quote
Old 2018-01-19, 15:18   #5
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

22·883 Posts
Default

Quote:
Originally Posted by fivemack View Post
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?

Quote:
Originally Posted by chris2be8 View Post
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 is offline   Reply With Quote
Old 2018-01-19, 17:06   #6
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

22·883 Posts
Default

Quote:
Originally Posted by EdH View Post
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."
EdH is offline   Reply With Quote
Old 2018-01-19, 17:17   #7
chris2be8
 
chris2be8's Avatar
 
Sep 2009

36678 Posts
Default

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
chris2be8 is offline   Reply With Quote
Old 2018-01-19, 22:51   #8
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

22·883 Posts
Default

Quote:
Originally Posted by chris2be8 View Post
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...
EdH is offline   Reply With Quote
Old 2018-01-22, 08:18   #9
vebis
 
vebis's Avatar
 
Oct 2015

6810 Posts
Default

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.
vebis is offline   Reply With Quote
Old 2018-01-23, 17:10   #10
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

22×883 Posts
Default

Quote:
Originally Posted by vebis View Post
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...
EdH is offline   Reply With Quote
Old 2018-01-24, 09:46   #11
vebis
 
vebis's Avatar
 
Oct 2015

22×17 Posts
Default

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.
vebis is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
a lyric finding tool MattcAnderson Soap Box 1 2017-01-01 15:18
Auto-XYYXF tool fivemack NFS@Home 3 2016-07-06 04:01
Sieving with powers of small primes in the Small Prime variation of the Quadratic Sieve mickfrancis Factoring 2 2016-05-06 08:13
One thread constantly restarting 25.7 build 3 OneOfMany PrimeNet 3 2008-10-29 23:03
tool to help with Top 5000 list Mini-Geek Lounge 6 2008-05-04 03:19

All times are UTC. The time now is 06:10.

Sun Jan 17 06:10:42 UTC 2021 up 45 days, 2:22, 0 users, load averages: 1.20, 1.34, 1.46

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.