Stats milestone - Page 4

VJS · 2006-06-20, 12:53

Citrix,

I'm pretty sure that LTD commented about this before the number of non-matching residues is zero or very close to zero thus far.

This makes sence for PSP since errors seem to be more time dependant as opposed to n-size. The PRP tests for PSP are still very very short relative to mersenne or SoB. I personally wouldn't worry about missed primes yet. Think of it this way the first pass n value is less than half of sob's second pass n and computers are alot faster now for PSP compared to SoB or mersenne when their n's were at the same level.

As for sieve, the question about is sieve eliminating candiates faster than prp, the answer is probably yes and no. We are probably eliminating more k/n pairs per day over the entire 991-50M range. However, I'm pretty sure PSP is testing more n in the 2-5M range than sieve is eliminating.

I'd like to see a "all things sieve page" for PSP not nessarily a daily update but something monthly or weekly?

In either case the sieve should certainly continue at least, I'd even suggest more effort in that area.

Citrix · 2006-06-20, 18:27

Thank you for the information. I was basically trying to get the stats page to refelect if any triple check were pending so we could finish them, as they arise.

ltd · 2006-06-20, 18:35

For the moment i see no chance that i will find the time to create something like "all things sieving". There are to many other things that need to be done.

That normal stats pages need to be redesigned. They are very ugly in my opinion.
Then there are the addional stats requests like showing factors removed
from reservation files by sieving or some performance graphs.
There are some more internal optimisations needed.(At the moment the stats run does more then it needs to do)
Very important also. I like to have a web based factor/residues submission form that puts the manual results into the DB automatically.

My problem is that there is the real world alsowhere i have a very demanding job.

One more thing if there is anybody who has suggestions for better structured stats please tell me. I am a programmer and not a designer. I never manage it to produce something with a nice look and feel. ( One of the reasons why i only programm backend things in my job).

Lars

Edit: Forgot to answer the question about the error rates. Still the rates are extremely low. Problem with giving numbers is that sometimes it is not possible to distinuish if there was an wrong residue or if one of the result comes from an older llr client which produced PRP compatible results and the other one came from the new client. There is no way for the llrnet server to prduce such an information.
To be sure i would need to make a fourth check. (which i make sporadic when there are alot of errors from one user tomake sure that it is only incompatible results and not a PC problem)

Citrix · 2006-06-20, 18:40

Quote:

Originally Posted by ltd

Then there are the addional stats requests like showing factors removed
from reservation files by sieving or some performance graphs.

Lars

How many tests have we done so far, for which a factor was found later?
(No need to put this on the stats page, I am just curious about the number of avoidable tests)

Thanks

ltd · 2006-06-20, 19:30

That is easy to answer.

When looking at all k in the DB we have 10190 factors for prp tested candidates while there were 146957 prp tests done inb total.

When we look only at the k values that are active at the moment we have the following numbers: 92741 prp tests done and 7183 factors for candidates which are already prp tested.

Citrix · 2006-06-20, 19:31

Thats alot of CPU time we could have saved.

ltd · 2006-06-20, 19:52

One more number that shows that we should not push double cheching:

When looking at the active k values and check how many factors are found for candidates that have already been double checked you find that there are 1764.

The factors returned today by vaughan, hhh, and AMDave alone saved us from doing 14 double checks and even better it removed a test that would have been handed out by the llrnet server within the next 24 hours.

So sieving is very important and i encourage everybody with an AMD to help sieving.

VJS · 2006-06-21, 14:47

I think we will find this to be true even with the current levels of prp until sieve reaches about 1000T. More than 5X higher than the current level, if sieve were around this level then I'd think about pushing prp a little harder.

I'd seriously not even think about secondpass or error rates until prp = 5M. At that point at least 1 k and probably more like 2 or 3k will be elimated.

Citrix · 2006-06-25, 06:32

Could p-1/ECm/P+1 have avoided all those tests and saved time? Should we start a factoring thread. We are almost at 2.5M.
How long does each p-1 test take and what bounds will be best?

ltd · 2006-06-25, 08:28

My internal tests show that with our sieving depth at the moment "p-1" would start to make sense somewhere around at least n=3.5M.

For "p+1" or "ECM" the numbers are even worse as for p+1 you need three runs with around the same runtime as "p-1".

And very simplified "ECM" is runing lots of "p-1". (Yes i know that you do not run "p-1" but the runtime per curve is in the same range)

So there is no time saving by trying these factoring methods.

Lars

Citrix · 2006-06-25, 08:37

Could you post your calculations?

2006-06-20, 18:35	#36
ltd Apr 2003 2²×193 Posts	For the moment i see no chance that i will find the time to create something like "all things sieving". There are to many other things that need to be done. That normal stats pages need to be redesigned. They are very ugly in my opinion. Then there are the addional stats requests like showing factors removed from reservation files by sieving or some performance graphs. There are some more internal optimisations needed.(At the moment the stats run does more then it needs to do) Very important also. I like to have a web based factor/residues submission form that puts the manual results into the DB automatically. My problem is that there is the real world alsowhere i have a very demanding job. One more thing if there is anybody who has suggestions for better structured stats please tell me. I am a programmer and not a designer. I never manage it to produce something with a nice look and feel. ( One of the reasons why i only programm backend things in my job). Lars Edit: Forgot to answer the question about the error rates. Still the rates are extremely low. Problem with giving numbers is that sometimes it is not possible to distinuish if there was an wrong residue or if one of the result comes from an older llr client which produced PRP compatible results and the other one came from the new client. There is no way for the llrnet server to prduce such an information. To be sure i would need to make a fourth check. (which i make sporadic when there are alot of errors from one user tomake sure that it is only incompatible results and not a PC problem) Last fiddled with by ltd on 2006-06-20 at 18:42

2006-06-20, 19:52	#40
ltd Apr 2003 2²×193 Posts	One more number that shows that we should not push double cheching: When looking at the active k values and check how many factors are found for candidates that have already been double checked you find that there are 1764. The factors returned today by vaughan, hhh, and AMDave alone saved us from doing 14 double checks and even better it removed a test that would have been handed out by the llrnet server within the next 24 hours. So sieving is very important and i encourage everybody with an AMD to help sieving. Last fiddled with by ltd on 2006-06-20 at 19:53

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Another milestone!	tcharron	PrimeNet	3	2013-08-29 06:44
Another milestone	frmky	Msieve	7	2012-04-25 22:12
New Milestone	opyrt	Prime Sierpinski Project	65	2010-10-06 13:18
CSVs for stats available + New combined stats	opyrt	Prime Sierpinski Project	3	2010-05-31 08:13
Stats Milestone - NEW	Chino112	Prime Sierpinski Project	59	2010-01-15 17:19

2006-06-20, 12:53	#34
VJS Dec 2004 13·23 Posts	Citrix, I'm pretty sure that LTD commented about this before the number of non-matching residues is zero or very close to zero thus far. This makes sence for PSP since errors seem to be more time dependant as opposed to n-size. The PRP tests for PSP are still very very short relative to mersenne or SoB. I personally wouldn't worry about missed primes yet. Think of it this way the first pass n value is less than half of sob's second pass n and computers are alot faster now for PSP compared to SoB or mersenne when their n's were at the same level. As for sieve, the question about is sieve eliminating candiates faster than prp, the answer is probably yes and no. We are probably eliminating more k/n pairs per day over the entire 991-50M range. However, I'm pretty sure PSP is testing more n in the 2-5M range than sieve is eliminating. I'd like to see a "all things sieve page" for PSP not nessarily a daily update but something monthly or weekly? In either case the sieve should certainly continue at least, I'd even suggest more effort in that area.

2006-06-20, 18:27	#35
Citrix Jun 2003 2×7×113 Posts	Thank you for the information. I was basically trying to get the stats page to refelect if any triple check were pending so we could finish them, as they arise.

2006-06-20, 19:30	#38
ltd Apr 2003 2²×193 Posts	That is easy to answer. When looking at all k in the DB we have 10190 factors for prp tested candidates while there were 146957 prp tests done inb total. When we look only at the k values that are active at the moment we have the following numbers: 92741 prp tests done and 7183 factors for candidates which are already prp tested.

2006-06-20, 19:31	#39
Citrix Jun 2003 11000101110₂ Posts	Thats alot of CPU time we could have saved.

2006-06-21, 14:47	#41
VJS Dec 2004 13×23 Posts	I think we will find this to be true even with the current levels of prp until sieve reaches about 1000T. More than 5X higher than the current level, if sieve were around this level then I'd think about pushing prp a little harder. I'd seriously not even think about secondpass or error rates until prp = 5M. At that point at least 1 k and probably more like 2 or 3k will be elimated.

2006-06-25, 06:32	#42
Citrix Jun 2003 2·7·113 Posts	Could p-1/ECm/P+1 have avoided all those tests and saved time? Should we start a factoring thread. We are almost at 2.5M. How long does each p-1 test take and what bounds will be best?

2006-06-25, 08:28	#43
ltd Apr 2003 2²×193 Posts	My internal tests show that with our sieving depth at the moment "p-1" would start to make sense somewhere around at least n=3.5M. For "p+1" or "ECM" the numbers are even worse as for p+1 you need three runs with around the same runtime as "p-1". And very simplified "ECM" is runing lots of "p-1". (Yes i know that you do not run "p-1" but the runtime per curve is in the same range) So there is no time saving by trying these factoring methods. Lars

2006-06-25, 08:37	#44
Citrix Jun 2003 2×7×113 Posts	Could you post your calculations?