mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > FactorDB

Reply
 
Thread Tools
Old 2019-12-01, 16:51   #12
BudgieJane
 
BudgieJane's Avatar
 
"Jane Sullivan"
Jan 2011
Beckenham, UK

2·32·13 Posts
Default

Quote:
Originally Posted by Happy5214 View Post
It's been 18 hours, and it still has the same message.
It now says "Full database check (will take some time)"
BudgieJane is offline   Reply With Quote
Old 2019-12-01, 19:17   #13
MDaniello
 
MDaniello's Avatar
 
May 2019
Rome, Italy

1F16 Posts
Default

I briefly got access back to factordb, but then i got a "2002: SQLSTATE[HY000] [2002] Connection refused" error and now is back to "Full database check (will take some time)".

The database was 80.xx %, so Syd managed to recover part of it.
MDaniello is offline   Reply With Quote
Old 2019-12-01, 19:30   #14
RichD
 
RichD's Avatar
 
Sep 2008
Kansas

C1416 Posts
Default

I had brief access also. When I inquired into AS 4788 it only returned the first few hundred indices. Each subsequent inquiry added a few more terms each time. I guess the internal workers were factoring the small numbers. I wanted to see what happen when it got to a C70 but it went offline too soon.

As I previously mentioned it looks like all the numbers are there but the links or association with its larger composite is missing. Which makes the data base useless in its current form. I am guessing the links make up the missing 4% which unconnected stated earlier. (Status page showed 80% when I had brief access.)
RichD is offline   Reply With Quote
Old 2019-12-02, 19:59   #15
MDaniello
 
MDaniello's Avatar
 
May 2019
Rome, Italy

31 Posts
Default

It seems the site is available again, while it keeps debugging the db in the background (it's actually showing the IDs it's working on in the status page).
The database is 817,667MB (81.77% used)
MDaniello is offline   Reply With Quote
Old 2019-12-02, 21:14   #16
DukeBG
 
Mar 2018

100000012 Posts
Default

I tried uploading a primality cert. Looks like it started processing. Hopefully this won't bother any recovery processes if they are still happening
DukeBG is offline   Reply With Quote
Old 2019-12-03, 16:56   #17
chris2be8
 
chris2be8's Avatar
 
Sep 2009

2×33×5×7 Posts
Default

Quote:
Originally Posted by RichD View Post
I wanted to see what happen when it got to a C70 but it went offline too soon.
I've restarted my script to factor numbers between 70 and 78 digits, so they are being cleared out. But it runs on an old and rather slow PC so can take some time if there are a lot to do.

It wasn't factoring numbers above 54 digits before the outage but is now clearing them up to 70 digits. Which saves me from having to work in that area. And I still have to skip over a few errors (at 71 and 75 digits I think).

Also factordb's load average is about 20 now. Is someone hammering it?

Chris
chris2be8 is offline   Reply With Quote
Old 2019-12-03, 19:31   #18
yoyo
 
yoyo's Avatar
 
Oct 2006
Berlin, Germany

58710 Posts
Default

There are some scripts running which fetch the last entry of a e.g. Aliquot Sequence. The Aliquot Sequence tables are tmp tables which were truncated. Now they are recreated on first access by using the known factors. This leads to millions of DB requests.
yoyo is offline   Reply With Quote
Old 2019-12-04, 16:54   #19
chris2be8
 
chris2be8's Avatar
 
Sep 2009

76216 Posts
Default

Now nearly all the 79 digit composites have been factored (kudos to whoever did them) I've update my script to clear 70-79 digit numbers.

Chris
chris2be8 is offline   Reply With Quote
Old 2019-12-04, 17:56   #20
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

1101000100002 Posts
Default

Quote:
Originally Posted by chris2be8 View Post
Now nearly all the 79 digit composites have been factored (kudos to whoever did them) I've update my script to clear 70-79 digit numbers.

Chris
I did turn some cores loose yesterday (over 100), but not sure how responsible I was, since when I stopped them all last night, almost all were crashed for some reason.

I've also created a Colab instance that factors via GMP-ECM with the GPU branch. I ran that for a while against the 80 dd composites, but it's much slower than the YAFU version for most composites.
EdH is offline   Reply With Quote
Old 2019-12-05, 17:02   #21
chris2be8
 
chris2be8's Avatar
 
Sep 2009

2·33·5·7 Posts
Default

Can your cores cope with factordb handing them a prime number when they ask for a composite? My scripts have had to skip over 1111111111111111111111111111111111111111111111111111111111111111111111111111091 an annoying number of times.

Also there's at least one broken 79 digit entry in factordb. wget returns "500 Internal Server Error" when it tries to download it.

If you want to set them loose again aim at 80 digit numbers, there's plenty of them now.

Chris
chris2be8 is offline   Reply With Quote
Old 2019-12-05, 23:59   #22
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

24·11·19 Posts
Default

When I really turn my machines loose on the composites for any length of time, I have an RPi, tracking the composites received, to cut down on duplication. The troublesome 79 digit gets run once and then all the machines ignore it. In reality, if I don't have the RPi running, my script processes the 79 digit number so fast it doesn't take too much time before it's on to the next, but it does show up often.

Something caused most of my machines to fail yesterday when they were running the composites. I didn't investigate, but every one of the failed machines was stuck in a failure loop trying to retrieve the next composite. A restart of the script succeeded without issue, but as to what was going on, I don't know. This is what was showing:
Code:
unrecognized token: td
Error, no result found
Factoring 9 digits: width=14%
All my machines are running a CADO-NFS job now, but I have a Colab session running the 80 digit composites, also. The Python3 script I'm playing with right now on Colab is using the GPU branch of GMP-ECM and only hitting everything lightly (11e2/11e3). It's having a success rate of a little over 50%. (The last run factored 21 of 30 in, I think, about five minutes.) Unfortunately, it also means only smaller factors (<20 digits, mostly) are found and the composites that survive will have to be run again. To counter that duplication, I hope to build a YAFU version, similar to the one I already have, that uses the GPU, but I'll have to modify the ECM calls within the YAFU code and limit the curves sent with higher B1s, or the ECM part will take a huge amount of time trying to process >3000 stage 2 residues across only two CPU cores for higher b1s.
EdH is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Spammers in FactorDB wpolly FactorDB 5 2019-04-16 11:19
A suggestion for factordb. enzocreti FactorDB 0 2018-03-02 09:12
Extending Factordb carpetpool FactorDB 6 2017-01-23 11:04
FactorDB PRP's smh FactorDB 231 2015-07-28 02:30
FactorDB question Raman Factoring 15 2010-01-28 10:24

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

Sat Sep 19 09:54:17 UTC 2020 up 9 days, 7:05, 0 users, load averages: 1.62, 1.73, 1.67

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, 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.