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.

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.

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)

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


Lars[/QUOTE]

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

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.

Thats alot of CPU time we could have saved.

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.

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.

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?

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

Could you post your calculations?