double check server online - Page 7

ltd · 2009-10-16, 15:32

Thanks to several ranges with manual reservation and also lots of work done on the prpnet server we are down to 1022 tests now.

We are closing in on first pass but it is still a very long way to go.

ltd · 2009-11-02, 17:21

Another update about the number of open tests.

The good news we have only 804 tests open for the k=168451 range.

The bad news we have the need to retest 200 tests from one user with some problem within some ranges. It might be that 140 tests would be sufficient but the start and endpoints of the bad ranges are a little bit unclear so we will have to run the whole set.

ltd · 2009-11-02, 17:37

Correction: After writing my post I received another big resultset from a manual tester (thanks opyrt

) and now we are down to 750 tests for k=168451.

VJS · 2009-11-04, 13:11

Quote:

Originally Posted by ltd

The good news we have only 804 tests open for the k=168451 range.

The bad news we have the need to retest 200 tests from one user with some problem within some ranges.

I'll say it again Lars, the good news is that you found a user requiring a 200 test retest.

Yeah it sucks that there are errors but proves the method, who knows could be a prime in there.

opyrt · 2009-11-04, 13:33

Quote:

Originally Posted by VJS

I'll say it again Lars, the good news is that you found a user requiring a 200 test retest.

The really good news is that the user still had the logfiles, so we'll only have to retest the candidates from the faulty computer, not all tests from that user during that time window!

ltd · 2009-12-06, 17:24

We are down to 623 lines for k=168451 and at the same time have brought k=156511 to 4M and also run several tests for suspicious results.

It looks like we will have to decide how to proceed in January.
We could either run dc on all remaining k or let the DC rest till we have some more test again and concentrate on first pass.

Then I have the offer from Primegrid to help us to bring DC to 5M for all K.
Here I am still unsure what way I should go. On one hand with these tests we will be "sure" (as sure as you can be without a real factor) that we have no missed primes. But n the other hand the error rate is so low so far that it might be better to run first pass tests to find a new prime first before using resources to make dc tests.

All comes down to the question how confident are we not to have missed a prime. So far the overall error rate is quite low (<2%) with most of the errors concentrated to special users/machines.

Any opinions how we should proceed?

japelprime · 2009-12-06, 22:19

Maybe you DC folks have reduced the error rate down to < 1% by finding this error pattern already?
On the other hand when calculating all candidates that have been tested up to 5M I would not be sure if there are hidden prime in there. Even if the error rate is only 0,5%. If we have the privilige having Primegrid helping here, I will wote for DC to 5M for all k. Then we do not have to worry if there are missing candidates in there......unless we have missed some already in sieving stage.

That makes me wonder if this errors that are already found, and are more or less eliminated to special users/machines. Did this machines do some sieve-works ?

VJS · 2009-12-06, 23:27

buggy machines are the best machines to have in sieve.
If they make error they only miss factors.

If a buggey machine reports a factor which is incorrect, that factor would only remove a test. However all factors are check to be legit before a test is removed from the system.

I'll let Lars comment about which are which; I think there is probably equal probablility between heavy overclocks and flaky cheap memory from (dell, hp, walmart, etc...). producing errors.

As far as what level, unless you go project wide there is no way to keep double check at the correct level. I think our accorch is currently the best alternative.

opyrt · 2009-12-07, 09:03

If PG wants to DC all k's up to 5M, I'm all for that.

When it comes to strategy, I think we should try to keep k=168451 as close to first pass as possible... and with the current progress in second pass, it's only a matter of time before we catch up.

Joe O · 2009-12-07, 15:19

Having PG doing strictyly double checks is a waste of resources. Especially up to 5M. If we missed a prime, I think that it is above 5M, not below. Besides, we could double check up to 5M ourselves. Let PG continue the fight in first pass. Remember, they double check as they go. This is very important. This is one reason for our low error rate. All the PG results come in double checked and do not add to our error rate.
I also think that we should keep k=168451 as close to first pass as possible. I would go further, and bring k=156511 up to first pass and keep it there. Then when we find a prime for k=168451 we don't have to start from scratch with a new k. We will start a new k, but we will have a k in position to continue the job of quickly monitoring the quality of work while we bring up another k for a backup.

ltd · 2009-12-07, 17:05

To bring k=156511 to first pass will need another 2200 test from 4M to first pass.

About unstable PCs and sieving. An unstable sieving PC can only miss a factor but can not insert wrong factors into the database. Every factor returned is checked if it is really a factor before it is booked. This is possible due to the fact that checking if a factor is valid only takes milliseconds.

So the worst that can happen if a unstable PC is used for sieving is that we have to run a prp test due to the missed factor. There is no way to miss a prime due to wrong sieving.

An unstable PC used for PRP testing on the other hand can lead to much more trouble as there is only one way to find out if a residue is valid and that is doing a double check which needs the same time as the original one. Also a wrong residue can lead to a missed prime which in the end mean a lot of wasted resources.

2009-11-02, 17:37	#69
ltd Apr 2003 1100000100₂ Posts	Correction: After writing my post I received another big resultset from a manual tester (thanks opyrt) and now we are down to 750 tests for k=168451.

2009-12-06, 23:27	#74
VJS Dec 2004 13·23 Posts	buggy machines are the best machines to have in sieve. If they make error they only miss factors. If a buggey machine reports a factor which is incorrect, that factor would only remove a test. However all factors are check to be legit before a test is removed from the system. I'll let Lars comment about which are which; I think there is probably equal probablility between heavy overclocks and flaky cheap memory from (dell, hp, walmart, etc...). producing errors. As far as what level, unless you go project wide there is no way to keep double check at the correct level. I think our accorch is currently the best alternative. Last fiddled with by VJS on 2009-12-06 at 23:28

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
New SR5 PRPnet server online	ltd	Sierpinski/Riesel Base 5	15	2013-03-19 18:03
First PSP PRPnet 4.0.6 server online	ltd	Prime Sierpinski Project	9	2011-03-15 04:58
First check and double check llrnet servers.	opyrt	Prime Sierpinski Project	3	2009-01-02 01:50
Double-check check?	M0CZY	Software	15	2008-10-30 14:20
Double Check Server	Citrix	Prime Sierpinski Project	12	2005-10-23 20:03

2009-10-16, 15:32	#67
ltd Apr 2003 2²×193 Posts	Thanks to several ranges with manual reservation and also lots of work done on the prpnet server we are down to 1022 tests now. We are closing in on first pass but it is still a very long way to go.

2009-11-02, 17:21	#68
ltd Apr 2003 2²·193 Posts	Another update about the number of open tests. The good news we have only 804 tests open for the k=168451 range. The bad news we have the need to retest 200 tests from one user with some problem within some ranges. It might be that 140 tests would be sufficient but the start and endpoints of the bad ranges are a little bit unclear so we will have to run the whole set.

2009-12-06, 17:24	#72
ltd Apr 2003 2²×193 Posts	We are down to 623 lines for k=168451 and at the same time have brought k=156511 to 4M and also run several tests for suspicious results. It looks like we will have to decide how to proceed in January. We could either run dc on all remaining k or let the DC rest till we have some more test again and concentrate on first pass. Then I have the offer from Primegrid to help us to bring DC to 5M for all K. Here I am still unsure what way I should go. On one hand with these tests we will be "sure" (as sure as you can be without a real factor) that we have no missed primes. But n the other hand the error rate is so low so far that it might be better to run first pass tests to find a new prime first before using resources to make dc tests. All comes down to the question how confident are we not to have missed a prime. So far the overall error rate is quite low (<2%) with most of the errors concentrated to special users/machines. Any opinions how we should proceed?

2009-12-06, 22:19	#73
japelprime "Erling B." Dec 2005 130₈ Posts	Maybe you DC folks have reduced the error rate down to < 1% by finding this error pattern already? On the other hand when calculating all candidates that have been tested up to 5M I would not be sure if there are hidden prime in there. Even if the error rate is only 0,5%. If we have the privilige having Primegrid helping here, I will wote for DC to 5M for all k. Then we do not have to worry if there are missing candidates in there......unless we have missed some already in sieving stage. That makes me wonder if this errors that are already found, and are more or less eliminated to special users/machines. Did this machines do some sieve-works ?

2009-12-07, 09:03	#75
opyrt Apr 2008 Oslo, Norway 11011001₂ Posts	If PG wants to DC all k's up to 5M, I'm all for that. When it comes to strategy, I think we should try to keep k=168451 as close to first pass as possible... and with the current progress in second pass, it's only a matter of time before we catch up.

2009-12-07, 15:19	#76
Joe O Aug 2002 3×5²×7 Posts	Having PG doing strictyly double checks is a waste of resources. Especially up to 5M. If we missed a prime, I think that it is above 5M, not below. Besides, we could double check up to 5M ourselves. Let PG continue the fight in first pass. Remember, they double check as they go. This is very important. This is one reason for our low error rate. All the PG results come in double checked and do not add to our error rate. I also think that we should keep k=168451 as close to first pass as possible. I would go further, and bring k=156511 up to first pass and keep it there. Then when we find a prime for k=168451 we don't have to start from scratch with a new k. We will start a new k, but we will have a k in position to continue the job of quickly monitoring the quality of work while we bring up another k for a backup.

2009-12-07, 17:05	#77
ltd Apr 2003 2²·193 Posts	To bring k=156511 to first pass will need another 2200 test from 4M to first pass. About unstable PCs and sieving. An unstable sieving PC can only miss a factor but can not insert wrong factors into the database. Every factor returned is checked if it is really a factor before it is booked. This is possible due to the fact that checking if a factor is valid only takes milliseconds. So the worst that can happen if a unstable PC is used for sieving is that we have to run a prp test due to the missed factor. There is no way to miss a prime due to wrong sieving. An unstable PC used for PRP testing on the other hand can lead to much more trouble as there is only one way to find out if a residue is valid and that is doing a double check which needs the same time as the original one. Also a wrong residue can lead to a missed prime which in the end mean a lot of wasted resources.