mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > FactorDB

Reply
 
Thread Tools
Old 2017-10-04, 03:28   #210
axn
 
axn's Avatar
 
Jun 2003

495910 Posts
Default

Quote:
Originally Posted by EdH View Post
Sorry, but I'm unsure what I will do about this
Write to Syd. He will be able to increase the limits for your account. Alternatively, use multiple internet connections and/or proxies so that each client uses a different IP.
axn is offline   Reply With Quote
Old 2017-10-04, 03:54   #211
rcv
 
Dec 2011

11·13 Posts
Default

Quote:
Originally Posted by EdH View Post
I'm about frustrated out of the composites. If I'm not allowed to keep up with the input, why bother? Now, all of my machines are errorring for over half their time:
You have reached your hourly limit of XXXXXXXX.
This is even messing up my automated Primo certificate reporting.
Sorry, but I'm unsure what I will do about this
I e-mailed Markus a couple of days ago about the massive number of IDs being created. He responded a few hours ago. He has done something to stop the egregious user, but it also seems he has reinstated account limits. [I have started to get messages about exceeding my hourly CPU limit, as I have been trying to apply algebraic factors to some of these junk numbers.]

If I recall from a few years ago, once you hit your quota, you can no longer do anything with the database until the 1-hour window expires. So, until Markus responds to you, I would suggest you submit your Primo certificates at the start of your hourly quota period. (Shortly after it resets the counters to zero.) I would assume processing of the Primo certificates won't count towards your quotas.

As far as processing factors, until Markus responds, would it be practical for you to queue your responses to FactorDB, and submit them at a rate that doesn't exceed your quota?
rcv is offline   Reply With Quote
Old 2017-10-04, 14:16   #212
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

72018 Posts
Default

I'm exploring other avenues, but the automation I have running for the PRP certificates has limited checking for duplication. It relies on the db to screen out pending candidates when it gets a new batch.

I guess the real problem is that a large number of the new composites consist of large numbers of small factors that process quickly and they are driving up the new IDs that are created. If I process 900 of these across all my machines, it's not hard to reach the limit.

Another issue is that I can only have one machine logged in at a time. They bump previous ones off if I log in a second one. So, I'm only logging in with the primo poster. The db won't even accept certificates or provide candidates once it's limit locked.

For now, I've decreased my machines and raised some of the baselines. I'll probably pursue using proxies (as axn suggested) and see how things turn out in the next few days.

Thanks for the replies...
EdH is offline   Reply With Quote
Old 2017-10-06, 15:51   #213
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

47×79 Posts
Default

Since the uploader is now purposely creating thousands of composites with ~20 small factors each, there is no way to keep up with the attack. One of my machines alone can lock the db up for me in less than 15 minutes. Therefore, I will no longer be working composites, unless the attack is eradicated.
EdH is offline   Reply With Quote
Old 2017-10-09, 16:24   #214
chris2be8
 
chris2be8's Avatar
 
Sep 2009

7F816 Posts
Default

At least some of the composites with a lot of small factors are factors of a large number, you can see if you click More Information. I think factordb runs ECM against large numbers with too high a B1 for the first pass, so it finds a composite factor which is the product of all the small factors of the original number.

The backlog has been cleared to 83 digits now, partly by me but a lot by someone else.

But I've had to slug my script for factoring small numbers by making it factor a larger number every so often to avoid getting locked out.

If you call up the list of composites and click on such a number factordb will often partly or fully factor it. Which is one way to deal with them (at some risk of RSI if you do it by hand).

Chris
chris2be8 is offline   Reply With Quote
Old 2017-10-09, 16:56   #215
richs
 
richs's Avatar
 
"Rich"
Aug 2002
Benicia, California

4DB16 Posts
Default

I've cleared about 46,000 composites in the past four days.
richs is offline   Reply With Quote
Old 2017-10-09, 17:08   #216
rcv
 
Dec 2011

14310 Posts
Default

Ed/Chris: I'm not quite sure how factordb counts new ID's against your limit, but if you are getting a lot of small factors, would it be possible to simply split the 80-100-digit composites into two equal-sized halves? (Then let factordb's internal workers finish the job.) [IMHO, providing a factor to an extant composite shouldn't count against your limits, at all. But adding new ID's, which come out of thin air should be strictly limited. But, that's a decision for Markus.]

Among a random sampling of composites in the 90-digit range, I also see the majority of those numbers appear to be children of the millions of numbers the vandal uploaded in a spree 7 to 11 days ago. [Thanks, Chris, for your explanation of what causes these.]

(I am also running a crawler and submitting factors. It isn't specifically aimed at the 80-100 digit composites, but it should be cleaving some of those.)

Last fiddled with by rcv on 2017-10-09 at 17:19
rcv is offline   Reply With Quote
Old 2017-10-09, 18:20   #217
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

47·79 Posts
Default

Quote:
Originally Posted by chris2be8 View Post
At least some of the composites with a lot of small factors are factors of a large number, you can see if you click More Information. I think factordb runs ECM against large numbers with too high a B1 for the first pass, so it finds a composite factor which is the product of all the small factors of the original number.

The backlog has been cleared to 83 digits now, partly by me but a lot by someone else.

But I've had to slug my script for factoring small numbers by making it factor a larger number every so often to avoid getting locked out.

If you call up the list of composites and click on such a number factordb will often partly or fully factor it. Which is one way to deal with them (at some risk of RSI if you do it by hand).

Chris
I left one of my less impressive machines running from 76 up and see it is now working at 83 digits. I don't know how many composites it cleared, but I didn't notice any lockouts, either.

If choosing composites individually would be a good idea, I have some scripts that could do a lot of them in a short time. My hesitation is that this is pushing back onto the db, a lot of the work which would not normally be expected to be accomplished by the db. OTOH, if these are generated by the db, perhaps we should attempt to send the work back into its operations.

Thanks richs for your help!

Quote:
Originally Posted by rcv View Post
Ed/Chris: I'm not quite sure how factordb counts new ID's against your limit, but if you are getting a lot of small factors, would it be possible to simply split the 80-100-digit composites into two equal-sized halves? (Then let factordb's internal workers finish the job.) [IMHO, providing a factor to an extant composite shouldn't count against your limits, at all. But adding new ID's, which come out of thin air should be strictly limited. But, that's a decision for Markus.]

Among a random sampling of composites in the 90-digit range, I also see the majority of those numbers appear to be children of the millions of numbers the vandal uploaded in a spree 7 to 11 days ago. [Thanks, Chris, for your explanation of what causes these.]

(I am also running a crawler and submitting factors. It isn't specifically aimed at the 80-100 digit composites, but it should be cleaving some of those.)
My understanding from observation, is that every one of the small factors from such a composite receives a new ID, unless that number was already in the db. Very few seem to already exist.

As to breaking the composites into smaller composites and giving them back, again I am in a conflict as whether to give back unfinished work to the db, or finish the factoring while I have the original composite.

Currently, I'm not seeing the endless small factor runs that were locking me out. I may venture back in with a machine or two more, but the PRPs have also piled up. And, right now, they are holding my interest a bit more.

If you guys think it OK to do the things I had reservations about, let me know and I will try some of them.
EdH is offline   Reply With Quote
Old 2017-10-09, 19:29   #218
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

E8116 Posts
Default

I just ran a script to touch 1000 of the 89 digit composites and it cleared 666 of them, so that is a possible direction for attack. If you guys think I should pursue this on a more widespread basis, let me know and I'll put a machine to work. Also, if it's a go, let me know what region to work, i.e., 76 dd and up, or limited to a certain digit range.
EdH is offline   Reply With Quote
Old 2017-10-09, 19:33   #219
yoyo
 
yoyo's Avatar
 
Oct 2006
Berlin, Germany

61210 Posts
Default

I think you don't need a script for it. There is page which allows you to download e.g. 500 composites starting with length X. This checks also internaly all.

Select plain text here: http://factordb.com/listtype.php?t=3
yoyo is offline   Reply With Quote
Old 2017-10-09, 20:45   #220
EdH
 
EdH's Avatar
 
"Ed Hall"
Dec 2009
Adirondack Mtns

47·79 Posts
Default

Quote:
Originally Posted by yoyo View Post
I think you don't need a script for it. There is page which allows you to download e.g. 500 composites starting with length X. This checks also internaly all.

Select plain text here: http://factordb.com/listtype.php?t=3
Indeed, you are correct!

I just tried that with 1000, 92 digit composites and it cleared 592 of them. In light of this new info, I'm going to try to clear all of this type in the 8x region...

Last fiddled with by EdH on 2017-10-09 at 20:46
EdH is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
A suggestion for factordb. enzocreti FactorDB 10 2021-01-05 19:49
Extending Factordb carpetpool FactorDB 6 2017-01-23 11:04
FactorDB PRP's smh FactorDB 231 2015-07-28 02:30
bugged sequence in factordb firejuggler Aliquot Sequences 2 2010-06-15 14:03
FactorDB question Raman Factoring 15 2010-01-28 10:24

All times are UTC. The time now is 17:18.

Sat May 8 17:18:33 UTC 2021 up 30 days, 11:59, 0 users, load averages: 3.40, 3.05, 2.93

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.