BOINC?

[Skligmund]

I thought something like that was already in effect. It seems whenever I attach a new computer or reset the project, the first few workunits are all doublechecked. I may be wrong on this though.

I like your thinking, I was thinking very similarly, but didn't express it.

[MooMoo2]

Obviously, everyone wants to get in as many accurate results as possible.

Let's say that the average PC tests 800 candidates per day, that there are 50 active users, and that the average user has 1 PC devoted to the project.

If all of the results were doublechecked:

25 users will be doing first time work
25 users will be doing double-check work

Therefore, there are 20,000 (25*800) accurate results per day.

edit: Or, 50 users will be doing first time work for 12 hours, and do double-check work for the other 12 hours. It doesn't matter. Either way, there will be 20,000 accurate results per day.

If no double checking was used at all:

50 users will be doing first time work, but -
10% of the results are errors

Therefore there are 36,000 (50*800*0.9) accurate results per day (a 100% accuracy rate would yield 40,000 accurate results per day, but that will never happen).

Obviously, it's simple math to compare 36,000 with 20,000. If doublechecking all results are temporary and are for the sole purpose of checking what the error rate is, then it's fine. However, I disagree with doublechecking all results for an extended period of time.

edit #2: A common argument for 100% doublechecking is, "Let's say we did 1-10G with no doublecheck. What happens if there was a twin in this range, but it was missed by a false result? Isn't it worth the computing power to find that twin?" My response is that the computing power needed to doublecheck 1-10G could have been used for checking 10-20G. The chance of finding a twin in 10-20G will be over 10 times as great as the chance of finding a twin in 1-10G that was missed by not doublechecking.

[Rytis]

Error rate is about 5%, however, this includes results with empty output files, which is easily caught (we have always resent those, since the very beginning). I've again switched to 50% of new tasks to be doublechecked, however, I'll be implementing a "picky" mode for validator which would resend a task for doublecheck if the host that returned it had at least one error in the short term. But this is not going to happen this week, most probably, as I'm now in the exam session.

BTW, smh: I read your response just before going to bed yesterday, and I got really fed up with it I wrote a huge rant, but after doing that I calmed down a little and did not post it :)

But anyway, I have come to help this project for free, wasted lots of my time trying to get it right, and you're bashing me? Go figure.

[KEP]

Originally Posted by Rytis

Error rate is about 5%, however, this includes results with empty output files, which is easily caught (we have always resent those, since the very beginning). I've again switched to 50% of new tasks to be doublechecked, however, I'll be implementing a "picky" mode for validator which would resend a task for doublecheck if the host that returned it had at least one error in the short term. But this is not going to happen this week, most probably, as I'm now in the exam session.

BTW, smh: I read your response just before going to bed yesterday, and I got really fed up with it I wrote a huge rant, but after doing that I calmed down a little and did not post it :)

But anyway, I have come to help this project for free, wasted lots of my time trying to get it right, and you're bashing me? Go figure.

Glad you calmed down Rytis, it shows just how big a person you are. I may say, even though I'm not participating in any BOINC projects at the moment, that I've seen a lot of messages in this forum, most noticeable from smh, and they made me sad that I introduced you to the TPS project some time ago. Wheter or not you have to give up supporting TPS in the future, I should not decide, but it just seems sometimes, that people are acting disrespectfull towards your decisions, and towards your support. I can add by the way, that I think we should de a 100% double check, because it is a really big waste of ressources if we are going to have a bad residue, when in fact it was a twin prime. Well it's up to you what you decide to do for your feature, but I think if the attention and replys you get is to frustrated, you should definently cut them off for a while, and switch back to your main goal, which is to find normal "big" primes :)

Now finally: "Congratulations to skligmund for overtaking the no. 1 position on the top LLR primefinders page on primegrid, I'm a good champ, and of course you should be gratulated by "winning" the no. 1 spot and glory it produces"

Regards!

KEP

Ps. This is a new year, and a new year should always sparkle a glimmer of hope and peace, at least for the first few months, so friends shouldn't we all try to keep a good and respectfull tone towards one another

[Prime95]

Originally Posted by MooooMoo

GIMPS's failure rate is about 1-2%. Since our workunits are a lot smaller, the expected failure rate should be lower than 0.01%.

A machine that is overclocked too much, or has heat or power supply issues, or has bad memory will spew out bad results at a great rate.

Let's assume GIMPS' error rate is 2% and that half of those errors are due to permanently bad hardware, the other half due to rather rare "glitches". That means your error rate should be over 1%. Not a terrible problem.

I think I've read in SOB forums that their error rate is around 5%. Why their error rate is higher I don't know. It *could* be because they don't have a torture test / self-test option or don't report errors that the underlying FFT code detects. I just don't know enough about their project and software to guess as to why their error rate is higher.

Anyway, to wrap up a rather long-winded post.... There are two completely unrelated issues here.

1) Double-checking everything to make sure a twin prime is not missed. This is an inefficient use of resources.

2) Double-checking a few results to let the user know his hardware is not up to snuff. This idea has some merit as it will encourage the user to fix the machine so that it can start producing good results for the project. It could be the difference between a 5% error rate and a 1% error rate.

Final thought: Assuming the 5% and 1% numbers are about correct, the project can safely devote 4% of it's resources to spot double-checking and still break even.

[Prime95]

Originally Posted by Rytis

...and I got really fed up with it I wrote a huge rant, but after doing that I calmed down a little and did not post it :)

But anyway, I have come to help this project for free, wasted lots of my time trying to get it right, and you're bashing me? Go figure.

Rytis, first off thank you for putting in the effort to make this project really come to life.

Having run a project for 10 years I can assure you that you will hear many complaints. Some are from ingrates/miscreants. Some are trying to offer helpful suggestions but the shortcomings of a English-only written medium makes it read like a complaint.

I've learned to ignore the ingrates and give the benefit of the doubt to the latter. Remember that there are dozens of satisfied and grateful users for every complaint.

[jmblazek]

Thanks b2 for your input.

Originally Posted by b2riesel

...CPUs, memory, powersupplies, heat issues and so forth.

I presume these are some of the reasons for residual discrepancies. If so, then these problems can technically come up at anytime...not just at the beginning of the project.
However, I like the idea of a "burn in" time for new hosts. Call it their "ante" for participating in the project. Maybe 100 double check WU's to determine their fail rate. Catching a bad machine earlier rather than later is ALWAYS better!

Originally Posted by Rytis

I'll be implementing a "picky" mode for validator which would resend a task for doublecheck if the host that returned it had at least one error in the short term.

This too is good as it will monitor those machines that go bad after their "burn in" time (eventually cutting them off if not resolved). Also, this is a focused approach...pinpointing double checking to the areas that "need" it...that have a specific concern while leaving "good" machines to push ahead.

Originally Posted by b2riesel

I can't tell you how many times a simple change of a PSU has made most of our bad residual problems go away.

I presume again that in order to determine there are bad residual problems, the residuals need to be compared to something...is there any other way of discovering bad residuals without double checking?

Originally Posted by b2riesel

Then dedicate a few machines that audit random user/hosts full time.

I like this as well. Rytis already had something similar in place with his 90%/10% double check. This was system wide distributed across all machines. However, dedicating a few machines to do double checking would allow "concerned crunchers" to feel good that their machines are not doing double check.

Summary of possible changes:

1. Implement a "burn in" with new hosts...100, 200, 500, 1000, ??? WU's? (on average machines, 475-600 WU's is about a days worth)
2. Continue random double checking with one of the following:
a. 90%/10% system wide
b. 96%/4% system wide
c. 10% double check with dedicated machines*
d. 4% double check with dedicated machines*
e. or some other method
* solves the "concerned cruncher" problem
3. Implement focused double checking (picky validator) for identified "problem" machines

Rytis probably has enough data to determine the best course of action now. 1 & 2 seem viable and extremely reasonable. 3 is insurance, builds integrity, and uses a minimalist approach to "wasted" cpu cycles. Actually, it's only implemented after 2 has identified a discrepancy.

At the very least, 1 & 2 can be implemented and most people will be happy. Implement 3 and most of the rest will be happy.

And by gosh, if that twin slips by after all this, it deserves to remain undiscovered!

I think there's a light to the end of this debate.

Thanks again for your input b2.

p.s. Rytis, focus on your exams...not on these trivial issues.

p.p.s. Thanks Prime95 for your input...it's always valued!

[Skligmund]

Originally Posted by KEP

"Congratulations to skligmund for overtaking the no. 1 position on the top LLR primefinders page on primegrid, I'm a good champ, and of course you should be gratulated by "winning" the no. 1 spot and glory it produces"

Regards!

KEP

The glory of trying to keep everybody behind you?
Actually, I have more than double the primes found than the next guy in line at primegrid... Woo Hoo! lol

I 86'd the K6-III+ 600 to make way for another Athlon64....

[biwema]

I also think, it makes no sense to doublecheck the whole range. with a reasonable low error rate, it is much more efficient to do first time checks instead. Unlike Gimps, wi do not want to find all primes, but only one. (Reason is alread listed in earlier posts).

Nevertheless some points to consider:
I assume, that one WU is not one LLR test. A LLR is rather splitted into smaller WUs, that they do not get too large. Does one Computer do all WUs in a LLR (that the intermediate file does not need to transferred every time), or do they get the WU randomly?
(Until now I did not download the bonic client but do more manual work, therefore I do not know the background).
About computer with errors: If one WU in a LLR is is invalid, the whole result is wrong. Therefore it is better not to mix computers too much.

Even if 5% error rate is high compared to GIMPS, it won't harm the project TPS too much. That is also a reason I recommended to sieve a 25G range instead of 5G (and a 100G range for 333333). So the chance of finding a twin is still pretty good even if some results are bad.

There is another issue, that could be a problem. almost in every DC project there are users that want to increase their credit score and are cheating for that purpose. If all workunits were doublechecked, these people can be identified. Also factors of sieving can be verified.
If people now fake residuals of LLR that they do not need to complete so many tests, it is a bit more difficult to detect. It is an advantage, that many non-twin primes are found before a twin is discovered.
If some users find a significantly lower number of primes in a range, it could make sense to doublecheck some random chosen parts of these results to see if these people are cheating or not. Now it can determined if it is just astatistical gap or if there are any missed primes/twins.

[smh]

Originally Posted by Rytis

BTW, smh: I read your response just before going to bed yesterday, and I got really fed up with it I wrote a huge rant, but after doing that I calmed down a little and did not post it :)

But anyway, I have come to help this project for free, wasted lots of my time trying to get it right, and you're bashing me? Go figure.

I never intended to get you fed up. I apologize if i did. Might be my inability to express myself in a foreign language.

I feel like saying a lot more, but decided not to...

[QUOTE=KEP;95440]Glad you calmed down Rytis, it shows just how big a person you are. I may say, even though I'm not participating in any BOINC projects at the moment, that I've seen a lot of messages in this forum, most noticeable from smh, and they made me sad that I introduced you to the TPS project some time ago./QUOTE]Thanks KEP, you've mad your point. I'm clearly not wanted here.

[Rytis]

Well, maybe we all overreact sometimes :) Maybe it was also English being not my native language :)

To come back to doublechecking issue, we had 8 false primes reported yesterday. I have a feeling that it was done deliberately and doublecheck would have solved this. For example check http://www.primegrid.com/orig/range_...&range_id=2798.

What I'm not sure is why doublechecking did not happen in this case, I tried to report false prime and script caught my attempt by doublechecking and later nullifying my result because it wasn't reported as a prime by subsequent checkers. The workunits that report possible prime are supposed to automatically enable doublecheck... I will investigate this and resend the bad workunits.