BOINC?

[smh]

Originally Posted by Rytis

I've switched to 100% double check. There are a lot of such results.

A lot of mismatches still doesn't warrant a double check of all numbers. Remember that we are looking for a twin, not all primes in a range.

Whats the percentage of mismatches?
Can you track down the mismatches to a few individual users or computers?

I don't mind doing a double (or triple) check every now or then, but i'm NOT planning to waste half of my cpu cycles on useless double checking.

[jmblazek]

If a twin has already be skipped then that's EXACTLY what we're doing...wasting cpu cycles...when we should have moved on to n=333333.

For example, if a single replication has returned a false residue and is not prime, there's no telling whether it was a prime or a twin.

This double checking stuff is always touchy. Hopefully, Rytis, you'll find the residue issue is a small percentage and are able to locate the source.

Maybe double checking doesn't need to be an issue until we've exhausted all 25G that's been sieved??? Wasted cpu cycles or not!

[MooMoo2]

Originally Posted by Rytis

Fail rate is 0.2874% :)

(a few weeks later)

Originally Posted by Rytis

I've switched to 100% doublecheck. There are a lot of such results.

So what's the current error rate (percentage of wrong results, not number of wrong results)? A 1% error rate isn't worth a 100% doublecheck, but if over a third of all results are errors, then a complete doublecheck may be of some use. Also, I'd suggest some penalties for reporting wrong results. Submitting 5 wrong results in a week gets you a warning to fix your computers and/or reduce the overclock, and submitting 10 or more wrong results in a week prevents you from contributing to the project for a few days.

Anyway, I don't think the wrong results are a serious problem now. On the stats page, PrimeGrid's density of primes is 1 prime every 6.5M, which is only a bit off the expected density (1 prime every 6M).

[smh]

Originally Posted by jmblazek

If a twin has already be skipped then that's EXACTLY what we're doing...wasting cpu cycles...when we should have moved on to n=333333.

But do we need 50% of the resources to find out that 2 or 3% of the numbers have a wrong residue?

On average, doing no double checking at all will find the twin fastest.

Anyway, if double checking continues, i'll be of BOINC.

[jmblazek]

Originally Posted by smh

But do we need 50% of the resources to find out that 2 or 3% of the numbers have a wrong residue?

Yes, we need 50% of the resources to double check... Once discovered, then everyone can discuss the best course of action. If only 2 or 3% have wrong residue, that seems small enough to return to 90%/10%...if less than 1% then maybe we can go to 95%/5%.

Originally Posted by smh

On average, doing no double checking at all will find the twin fastest.

Absolutely true! As prime95 said, we're not looking for the "smallest" record twin...we're looking for "a" record twin.

Originally Posted by smh

Anyway, if double checking continues, i'll be of BOINC.

Why not wait a few hours and see what Rytis discovers. No need to jump ship when there's a small leak that can be plugged with a paper clip. Then again, if we reach 25G with no twin, I'd say the paper clip didn't work.

[MooMoo2]

Originally Posted by jmblazek

No, we don't need 50% double check...we need 100% double check to determine the problem.

A 100% double check means 50% of the resources will be used for double checking, and the other 50% of the resources will be used for first-time checking.

[jmblazek]

Am I missing some logic? How can you determine where the problem is coming from if you don't double check 100%?

I'm not suggesting 100% double check 100% of the time, just until the discrepancy is understood.

Is there a more efficient way of troubleshooting?

p.s. Remember, I'm the one who wants 1G a week...but what good is that if there's no integrity to the results.

[MooMoo2]

Originally Posted by jmblazek

Am I missing some logic? How can you determine where the problem is coming from if you don't double check 100%?

I'm not suggesting 100% double check 100% of the time, just until the discrepancy is understood.

Is there a more efficient way of troubleshooting?

p.s. Remember, I'm the one who wants 1G a week...but what good is that if there's no integrity to the results.

If you do:

1.) Check a candidate
2.) Double check the residue

Then the breakdown is: 50% of the resources for doublechecking, another 50% of the resources is used for first-time checking.

If you do:

1.) Stop all checking of new candidates
2.) Double check all old candidates

Then the breakdown is: 100% of the resources for doublechecking.

[jmblazek]

Already got it...see previous edits.

[smh]

Originally Posted by jmblazek

Why not wait a few hours and see what Rytis discovers. No need to jump ship when there's a small leak that can be plugged with a paper clip.

I haven't jumped ship yet. Just put on my life jacket, just in case.

Originally Posted by jmblazek

Then again, if we reach 25G with no twin, I'd say the paper clip didn't work.

You're wrong again. There's about 83% chance a twin will be found before 25G. Even at 50G, there's a 3% chance to not find a twin.

[Rytis]

100% in my post means that all tasks are now sent in two copies. We are not looking back at old ones (although I will surely feel bad if we missed the prime in the previous ranges!).

I am not able to get the actual amount of results that fail to return matching residues as the database is at it's peek load times now. I will try to get more info tomorrow in the morning. I also haven't looked if a specific user is returning non-matching results, however, he would be automatically stopped soon because daily result quota gets halved for every invalid result. Also, new users come into the project. I'll look into non-matching results now and will update you with new info.

About my average prime rating: 1600-1700M only yielded 9 primes. I think it's way too little. This range was done with 10/90 doublecheck (10% of tasks were sent out twice). I think it would be good if someone checked at least 20M from this range and compared the results...

[edit] Skligmund and Beta-guy are in a lot of non-matching results. The question now is, is it because their computers generate bad results, or because they do most work? Investigating further.