20191223, 15:38  #1 
Sep 2010
Weston, Ontario
C4_{16} Posts 
PRPtest issue
A PRPtest on a 74685digit Leyland number submitted December 21 is still "in queue" two days later while a 76029digit Leyland number submitted four hours later got PRP'd within the day.

20191225, 18:44  #2 
Mar 2018
201_{8} Posts 
There are 9,068 PRP tests queued right now. Someone is overzealous with that button. FactorDB shouldn't be forced to PRP numbers that big. Anyone is better advised to run such PRPs on their own hardware.

20191225, 22:07  #3  
Sep 2010
Weston, Ontario
C4_{16} Posts 
Quote:
But you're missing the point. There is a number supposedly "in queue for a PRPtest" since 21 December 2019 but I have added four more numbers to that queue since then (two just yesterday) and all four have been PRP'd in a matter of hours. So the number "in queue" is apparently not really in queue since it has become obvious that it will never get to the front. It was this matter to which I wanted to bring attention in case anyone else had a similar experience. 

20191226, 03:58  #4 
Jun 2003
3^{2}·19·29 Posts 
FactorDB PRP queue is LIFO. So the ones that are submitted recently gets processed before the older ones. Currently 9043 numbers are in queue. Noone knows where your number is within that queue. When the queue runs down to 0, yours would have been done as well.
Go to http://factordb.com/status.php and look at the pending column against the "Combined N1/N+1method" line (under Primality Proofs section) to keep track of the queue size. Oh, and btw, when there are certificates to be processed, that gets priority, so the PRP queue will have to wait even further. 
20191226, 04:12  #5 
Undefined
"The unspeakable one"
Jun 2006
My evil lair
1011111111100_{2} Posts 

20191226, 04:44  #6 
Jun 2003
3^{2}×19×29 Posts 
You're correct. That is not the expected behavior of "queue", but it is what it is. Note that factor db itself doesn't use any terminology  it is just a term that we used in the discussion.

20191226, 13:59  #7  
Feb 2017
Nowhere
2×31×73 Posts 
I also tried finding the number on the list of numbers with unknown status. I eventually succeeded, and also found an obviouslyrelated number. The list is sorted by number of digits only. I had to resort to trialanderror to fill in the "Digits" field to bring the requisite number of digits into range. The filledin fields didn't copypaste; I had to fill them in in the quoted portion.
Why the number of digits that worked, worked, is a mystery to me. Quote:


20191231, 13:40  #8 
May 2019
Rome, Italy
23_{16} Posts 
That massive number of tests in stack made me wonder if someone was "clearing" some digit interval in the Unknown status list. Given that is taking a really long time to test those numbers, they should be far down the list. (Question: is PRP testing time exponential in number size? By size i mean digits)
By looking at the distribution graph i found this. I then checked some numbers in the list on either side of the dips in the graph for PRP button availability: The numbers between 149012 and 149142 digits are in the stack, while numbers above 149159 digits are not. (Apparently, you can't PRP test numbers with 150 kilodigits and bigger) Of course i didn't check each number, just randomly sampled them in those intervals. Because the bulk of the numbers are beetween 149041 and 149142 digits (around 100 bins, and for each bin we have numbers in a range from 30 to 70, the total number of numbers (sorry for the repetition) is expected to be beetween 3000 and 7000. So, either i missed something/overapproximated in my backoftheenvelope calculation, or a significative part, but not all of the numbers in th stack, are >149 kilodigits. 
20191231, 13:55  #9 
Sep 2002
Database er0rr
2^{4}×229 Posts 

20200101, 12:06  #10  
Mar 2018
3·43 Posts 
Quote:
But I agree that not only this should have been called a stack, or rather actually implemented as a queue, not as a stack, it also should have been autoreordered to have smallest numbers served first, like it actually does for primality certificates processing. Oh well. Quote:
If you've only submitted these two numbers, that's no problem. Someone else who submitted 9K numbers (by which i mean "added to the queue for PRP processing"), a lot of which, I presume, take 1020 minutes each, is a problem. There's always more than enough smallest "status=unknown" numbers for FDB to autowork on, people asking for their numbres to be worked on first is an avenue I believe should be much more limited. Or uploading residues should be implemented in some way, though I don't think there's a reliable way to check them without doing a full test again which kinda defeats the purpose. Last fiddled with by DukeBG on 20200101 at 12:09 

20200101, 13:04  #11  
Jun 2003
4959_{10} Posts 
Quote:
Quote:
FactorDB auto PRP test is limited to < 20,000 digits. Why? The numbers around this size takes 510 seconds only. IMO, it should've auto worked on everything under 100k digits (smallest ones moving to the top of the queue, natch). Currently, the only way to make FactorDB work on these smaller unknowns is to submit them. 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
DC performance issue  cuBerBruce  Information & Answers  2  20170710 13:43 
GWNUM issue  ET_  Software  4  20170615 09:52 
32/64 bit gmpecm issue...  WraithX  GMPECM  15  20161219 17:42 
That's odd ... ubuntu13.10 ecm issue  fivemack  GMPECM  12  20150605 02:02 
Torture Test Issue  xavion  Software  5  20030708 02:10 