There are no reason to DC sieve WU !!!

We use to sieve to we get sec/factors about 100% of LLR time on a candidate about 75-80% of high n.level in the range.

Now with DC we get that sec/factors multiplied by 2 ( or more).

That means that there are no reason to sieve as deep as we should have done if we only did a single test.

If we miss 10% factors on a single tests we save time compare to DC.

Sieve is only to save time when running LLR !!!

If we not lose 50% or more without DC it is just a waste of time.

My goal is to minimize the time to find the primes. so I would like to stop all DC'ing on sieve wu.

Any thoughts ??

Lennart
____________

Just a thought...does it make sense to use AR?
Only small overhead but still high reliability.
____________
My stats

Just a thought...does it make sense use AR?
Only small overhead but still high reliability.

I thought the DC on the sieves was brought about due to a problem with some form of cheating. Am I not remembering that correctly? If I am remembering correctly, is that no longer a concern?

I thought the DC on the sieves was brought about due to a problem with some form of cheating. Am I not remembering that correctly? If I am remembering correctly, is that no longer a concern?

I thought the DC on the sieves was brought about due to a problem with some form of cheating. Am I not remembering that correctly? If I am remembering correctly, is that no longer a concern?

I thought the DC on the sieves was brought about due to a problem with some form of cheating. Am I not remembering that correctly? If I am remembering correctly, is that no longer a concern?

That's one of the problems. The other problem is that the lack of double checking allowed a serious flaw in the PPS sieve program to go unnoticed for many years. Since the ATI version of the PPS-Sieve program was introduced (in 2010?) it's been missing factors and we didn't discover this until recently. It's only once we started the partial double checking and made the validator really picky about matching the results that we noticed something was wrong.

The question boils down to which should we consider to be more important:

1) Getting the maximum amount of sieving done as quickly as possible, with the goal of therefore reducing the number of LLR candidates as quickly as possible, or

2) Making sure the sieve file is as accurate as we can, i.e., providing the maximum protection against both hardware and software errors, while at the same time providing the most protection against cheaters.

When I first saw the title of this thread I thought it was a poorly timed April fool's joke. However, after reviewing the responses, it's for real.  I looked further at the sieves and it appears that all of them are in full DC.  I don't know when DC went into effect but I've seen reference to it as far back as Jan 2014.  Ouch!

"Sieve DC", "pending sieve credit", "sieve replication 2" are all oxymorons. :). It's such a contradiction in terms that it must have taken extreme circumstances to reach this point of implementation...not to mention a complete failure of communication, discussion, collaboration, and problem solving.  I believe it's in this last section where the real problem exists.

Honestly, there's so many things wrong with this that I don't know where to begin.  Let me first start off with presenting an unfair cherry picked example to present one extreme occurence.   2, 3, 5, 7 are all factors of 210.  If my sieve only finds the number 7 and misses the others, it would only have a 25% accuracy rate.  Nevertheless, 210 would still be removed from the LLR test pool.

Now let's take another example where the sieve misses a factor for an n=28M SoB candidate.  This means that this candidate will now have to be LLR'd to determine if it is prime or not.

I understand there have been several issues with the PRS (PPS & RSP) sieves:

k=5 and others undersieve
p=35T-40T error
Range boundary omissions (both k and n boundaries)
Ati bug

However, even with all these issues, I can bet the farm, the winning lotto ticket, and the pension that the time lost in repairing these issues pales extremely in relationship to the time wasted with converting to full DC.

A missed factor is only a penalty after the candidate has been LLR'd.  Doing a full DC on the sieves in real time is very damaging to managed resources and a waste of time. It's like using 99.9% of the resources to find 0.1% of the problem.  Why is there no discussion at PG about this?

The depressing thing is that the PG community has drank this coolaid for at least the past 8 months with no real discussion or problem solving. Apparently, PG is failing its secondary goal of educating the community.   Does anyone see the painful irony of a PPS sieve DC and a PPS LLR AR (Adaptive Replication)?

When it comes to cheating it appears that cobblestones have overruled common sense. The pursuit of efficiency and best use of resources has been replaced by the protection of a meaningless credit. 

Don't get me wrong, cobblestones are an important part of running projects on BOINC but when it trumps finding a good solution, something is broken. 

If PG wishes to continue DCing sieves, at the very least they should hold off until the winter months so the hosts can at least be effective as heaters.   (Granted, sunlight passing through a window landing on a thermal mass will be a 100 times more effective.)

By not coming up with a good solution to the cheating issue, a few unscrupulous users have forced the entire PG community to waste their time and resources (if they so choose to participate in a sieve). 

From what I can tell, PG has GREATLY improved its internals, operations appear smooth, stats are more detailed, capacity has increased, challenges run without a hitch, and data integrity is much higher.  The ship is clean and in good form; however, someone is asleep in the wheelhouse. ;)

I understand that times have changed, that I'm out of touch, and that new perspectives are needed, but c'mon, someone needs to get into the wheelhouse or at least wake up the driver!
____________

From my point of view, AR with strict settings could be acceptable to make life of cheaters hard and minimize number of possible missed factors. AR coefficients must be tweaked in such a way that:

1. Even for most reliable hosts, probability of workunit to be DC'ed must be not less then 5-10%.
2. Host must return significant number (e.g. 50-100) of valid workunits before it's considered reliable.
3. A single "inconclusive" error must immediately return host to "unreliable" mode.
4. Host with multiple inconclusive results could be locked to "unreliable" mode or even banned from this subproject.
5. PPS sieve still returns significant number of factors per workunit, so results without factors must be forced DC'ed. Unfortunately, it's not possible for CPU sieves without significant increase of workunit size.

Of course, the challenge must be completed and DC'ed before any changes are made.

Just my two cents.

Does anyone see the painful irony of a PPS sieve DC and a PPS LLR AR (Adaptive Replication)?

Does anyone see the painful irony of a PPS sieve DC and a PPS LLR AR (Adaptive Replication)?

5. PPS sieve still returns significant number of factors per workunit, so results without factors must be forced DC'ed.

As I recall, I proposed adding some kind of checksum to PPS Sieve WUs, so that WUs could reliably be checked with AR, but that idea was rejected for some reason. Of course, this would be easier if we abandoned the CPU app, which might move this out of the scope of this thread.

When it comes to cheating it appears that cobblestones have overruled common sense. The pursuit of efficiency and best use of resources has been replaced by the protection of a meaningless credit.

...the above part of his post strikes me as painfully naive regarding the social and psychological efficiency of distributed computing. 

Don't get me wrong, cobblestones are an important part of running projects on BOINC but when it trumps finding a good solution, something is broken.

BTW, another point of possible waste of resources could be SoB. I could be mistaken, but, as far as I know, the SoB (non-PG part, of course), is not DC'ed at all. To be exact, some of their early ranges had partial verification (kind of manual AR) - the result of this DC was two missed primes... I found no traces that they changed to DC or did any new manual verification, so I'm considering their recent ranges completely untrusted. I'll be glad to hear that I'm wrong.

I'm curious, for the upcoming challenge project, TRP Sieve, in the past 8 months how many results have come back as invalid? And of those invalids, how many are attributed to people attempting to cheat and how many are due to other issues (truncated factors/boundary)?
____________

I have hidden my former post that referred to John as being "painfully naive" and wish to publicly apologize for it.


Regarding the issue in this thread, my opinion is that if the cheating issues can be held in check otherwise, then the DC efforts on the sieves at PG should be eliminated.

I want to put a few misconceptions to rest.

First of all, this idea isn't up for a vote, and I'm not soliciting opinions. This is a decision that was made a while ago, for reasons I'll explain (but will not debate). Feel free to express your opinions if you wish, but please do so with the understanding that this is not something we're looking to change in the near future.

There's three reasons for the DC, with the common thread being that without it we can't *detect* a problem. There could be no problem, a little problem, or a huge 100% problem, but without the checking we have no way of knowing. Here's the events that led up to the decision:

1) The PPS Sieve cheating went on for many months completely undetected. It was a fluke that we caught it. In the end we had to resieve months of work and we're not at all sure that there's not huge numbers of factors that were missed in other ranges that weren't resieved. We honestly don't even know the scope of the damage. Jim tabulated the number of extra factors found when we redid the sieve. It was around 7 or 10 million (I forget which.)

2) The PPS-Sieve ATI app was broken, and it was broken the beginning. It's been missing factors all the way back to 2010 or 2011, whenever it came online. Based on a limited number of data points, some 10% of all the factors that should have been found on ATI tasks were missed. There's no way of getting those back unless we resieve everything done in the last 4 years.

3) We discovered earlier this year that the Android sieve app, used for TRP-Sieve (and potentially for ESP-Sieve) was completely broken. It **ALWAYS** returned "no factors". 100% of the time. So every task done on Android missed 100% of the factors.

Those last two events have also led to an increased testing regimen for apps, as well as the increased focus on double checking.

In short, the real reason for double checking isn't so much to catch the occasional missed factor. It's to detect problems, such as cheating or bad software, or any other problem. Without the DC, we don't know when something has broken. The loss of efficiency is the cost necessary to improve quality by having an early warning system for problems.

Based on 2 and 3 above, I'm also considering whether we should adopt a policy of temporarily doing full DC on any project for a period of time (perhaps 1 to 3 months) following the installation of new versions of any app. At the present time, only PPS, PPSE, and SGS aren't already full DC, so this would only apply to those apps when a new version of LLR comes out. With the last LLR release for FMA, we didn't do this, but we did several months worth of testing of the LLR app.

We may reconsider the DC decision for the sieves at some future time if the conditions warrant, but for now it's a done deal.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I want to put a few misconceptions to rest.

First of all, this idea isn't up for a vote, and I'm not soliciting opinions. This is a decision that was made a while ago, for reasons I'll explain (but will not debate). Feel free to express your opinions if you wish, but please do so with the understanding that this is not something we're looking to change in the near future.

There's three reasons for the DC, with the common thread being that without it we can't *detect* a problem. There could be no problem, a little problem, or a huge 100% problem, but without the checking we have no way of knowing. Here's the events that led up to the decision:

1) The PPS Sieve cheating went on for many months completely undetected. It was a fluke that we caught it. In the end we had to resieve months of work and we're not at all sure that there's not huge numbers of factors that were missed in other ranges that weren't resieved. We honestly don't even know the scope of the damage. Jim tabulated the number of extra factors found when we redid the sieve. It was around 7 or 10 million (I forget which.)

2) The PPS-Sieve ATI app was broken, and it was broken the beginning. It's been missing factors all the way back to 2010 or 2011, whenever it came online. Based on a limited number of data points, some 10% of all the factors that should have been found on ATI tasks were missed. There's no way of getting those back unless we resieve everything done in the last 4 years.

3) We discovered earlier this year that the Android sieve app, used for TRP-Sieve (and potentially for ESP-Sieve) was completely broken. It **ALWAYS** returned "no factors". 100% of the time. So every task done on Android missed 100% of the factors.

Those last two events have also led to an increased testing regimen for apps, as well as the increased focus on double checking.

In short, the real reason for double checking isn't so much to catch the occasional missed factor. It's to detect problems, such as cheating or bad software, or any other problem. Without the DC, we don't know when something has broken. The loss of efficiency is the cost necessary to improve quality by having an early warning system for problems.

Based on 2 and 3 above, I'm also considering whether we should adopt a policy of temporarily doing full DC on any project for a period of time (perhaps 1 to 3 months) following the installation of new versions of any app. At the present time, only PPS, PPSE, and SGS aren't already full DC, so this would only apply to those apps when a new version of LLR comes out. With the last LLR release for FMA, we didn't do this, but we did several months worth of testing of the LLR app.

We may reconsider the DC decision for the sieves at some future time if the conditions warrant, but for now it's a done deal.

What you are saying is that you did put a untested new app in production ??

And a second app. ATI app also untested ??


Do you think you could test the app's before releasing them ??


Lennart

The main reason I saw to DC sieves was kind of opposite to that one: avoiding a prime to be wrongly ruled out of LLR by a faulty sieve. This would be problematic in conjectures as well as in MEGA PPS.

we relied on users testing it with app_info. We'll try not to make that mistake again!

First of all, this idea isn't up for a vote, and I'm not soliciting opinions. This is a decision that was made a while ago, for reasons I'll explain (but will not debate). Feel free to express your opinions if you wish, but please do so with the understanding that this is not something we're looking to change in the near future.

In short, the real reason for double checking isn't so much to catch the occasional missed factor. It's to detect problems, such as cheating or bad software, or any other problem. Without the DC, we don't know when something has broken. The loss of efficiency is the cost necessary to improve quality by having an early warning system for problems.

First of all, this idea isn't up for a vote, and I'm not soliciting opinions. This is a decision that was made a while ago, for reasons I'll explain (but will not debate). Feel free to express your opinions if you wish, but please do so with the understanding that this is not something we're looking to change in the near future.

Well that certainly dampens the mood a bit. Hopefully it doesn't deter anyone from contributing to the dialogue, maybe even brain storming for a better solution.  Heck, a good solution has already been submitted (apparently over 8 months ago as well). I'm not sure why PG doesn't encourage open discussion and collaboration to problem solve relatively simple issues.

1) Do all sieves drop off the way GFN does?
2) Anyone want to try to come up with a formula for how many fewer factors we'll find because of DC? It's clearly less than 50%, and my gut feeling is it's a lot less than 50%. The question is how much less.

1) Do all sieves drop off the way GFN does?
2) Anyone want to try to come up with a formula for how many fewer factors we'll find because of DC? It's clearly less than 50%, and my gut feeling is it's a lot less than 50%. The question is how much less.

1. Yes-ish.
2. I'll leave out the calculation for GFN sieve, but for the others, use this simple formula. Number of candidates sieved out by sieving from p1 to p2 is N*(1-log(p1)/log(p2)), where N is the number of candidates we have after sieving to p1.

If we take p1=1P (10^15), and p2=2P. That amounts to N*0.019 or about 1.9% candidates sieved out. Feel free to plugin different values for p1 and p2.

Incidentally, due to the existence of this formula, we can pretty accurately estimate how much factors we're supposed to find for specific (large-ish) sieve ranges.

EDIT:- Formula not applicable for SGS where we do triple or quad sieve. It is not part of this discussion, but just thought everyone should know.

1) Do all sieves drop off the way GFN does?
2) Anyone want to try to come up with a formula for how many fewer factors we'll find because of DC? It's clearly less than 50%, and my gut feeling is it's a lot less than 50%. The question is how much less.

1. Yes-ish.
2. I'll leave out the calculation for GFN sieve, but for the others, use this simple formula. Number of candidates sieved out by sieving from p1 to p2 is N*(1-log(p1)/log(p2)), where N is the number of candidates we have after sieving to p1.

If we take p1=1P (10^15), and p2=2P. That amounts to N*0.019 or about 1.9% candidates sieved out. Feel free to plugin different values for p1 and p2.

Incidentally, due to the existence of this formula, we can pretty accurately estimate how much factors we're supposed to find for specific (large-ish) sieve ranges.

EDIT:- Formula not applicable for SGS where we do triple or quad sieve. It is not part of this discussion, but just thought everyone should know.

Thanks, axn.

That's lower than I thought. Cutting the sieve duration in half reduces the number of factors found by less than 2 percent. Playing with the numbers a bit, it looks like the percentage goes down as p1 and p2 get higher.

That's very, very helpful. Thanks!

Today:

That is not changing anything .
If the sieve to 1P takes a year it will be 2 year with DC.

Lennart

[8/3/2014 8:31:56 AM] Lennart Vogel: if we dc siieve wu we have to lower our calculated optimal sieve deep /2
[8/3/2014 8:32:01 AM] Lennart Vogel: or more
[8/3/2014 8:32:21 AM] Lennart Vogel: that means we will stop sieving on a much lower P

At this point, I'd like to comment on the title of this thread:

"DC on sieving using CPU is Only waste of TIME."

I disagree with that. It saves time. What it wastes is computing resources.

Since we have a way to calculate density of factors at a specific P (or we can have a look at recent figures), then we can expect a certain number of factors per a number of tasks. Say we expect one factor to be returned per 100 tasks, then if a host doesn't return a factor after 300 WUs, we DC those tasks to see if there's a problem there.

Also at some depth of a sieve when factors become so scarce so there's no point to DC, we can stop DCing and continue sieving, only double-checking suspicious hosts occasionally.

I was also thinking about working out a point of optimal sieve depth. Since we know all factors returned for a range, is it possible to estimate time saved by sieving?

I think that GPU sieving depth is a little bit more difficult to understand. First, it's difficult to compare GPU to CPU time spent. We could compare watts used?

Second, if at some point we decide that we should stop GPU sieve and don't want to sieve a higher n-range, then we can just loose all our GPU power to other projects. Not all of our members will move their video cards to GFN. I'm saying that GPU power is "free" for PrimeGrid and as long as we have a good paying [cobblestones] sieve like PPS, we can freely use GPUs. But once we stop sieving, we will loose them. So we shouldn't stop sieving at any point as it's free.

Double check everything, without exception.

--G

Double check everything, without exception.

--G

I find the reasoning made earlier in this thread regarding detecting errors in the software to be compelling. Sure, if we only miss 1% of the factors and therefore needlessly LLR them, OK, I can see where sieving double-check in that case is overkill and a waste. But what if we're missing 50% of the factors. Or 90%. We don't know what that ratio is without a reasonable mechanism to notice it.

Do we put untested software out there? No, hopefully not. I've tested here myself quite a bit. But software is written by humans, and tested by humans, and humans make mistakes... no matter how much "beta" test is done. Maybe the double-check is like a "peer review" prior to publication in academic journals (that's far from a perfect analogy, I know).

As for the "cheating" aspect, well, detecting cheating is good, just on a moral basis, and that makes me feel good and want to continue to contribute. As for *why* someone would want to cheat, I believe I understand the reasons, but they are better discussed by a psychologist than a computer programmer, and is off-topic, I guess.

Perhaps some guidance can be provided by the number of "invalid" tasks that come out of the current TRP Sieve challenge.
Cheers,
--Gary

I find the reasoning made earlier in this thread regarding detecting errors in the software to be compelling. Sure, if we only miss 1% of the factors and therefore needlessly LLR them, OK, I can see where sieving double-check in that case is overkill and a waste. But what if we're missing 50% of the factors. Or 90%. We don't know what that ratio is without a reasonable mechanism to notice it.

Do we put untested software out there? No, hopefully not. I've tested here myself quite a bit. But software is written by humans, and tested by humans, and humans make mistakes... no matter how much "beta" test is done. Maybe the double-check is like a "peer review" prior to publication in academic journals (that's far from a perfect analogy, I know).

As for the "cheating" aspect, well, detecting cheating is good, just on a moral basis, and that makes me feel good and want to continue to contribute. As for *why* someone would want to cheat, I believe I understand the reasons, but they are better discussed by a psychologist than a computer programmer, and is off-topic, I guess.

Perhaps some guidance can be provided by the number of "invalid" tasks that come out of the current TRP Sieve challenge.
Cheers,
--Gary

Perhaps some guidance can be provided by the number of "invalid" tasks that come out of the current TRP Sieve challenge.
Cheers,
--Gary

Do ESP and PPS sieves have any output other than the factors file?

The PPS Sieve was modified to say "No factors" when no factors are found some years ago. It's just one version wasn't upgraded at PrimeGrid for awhile.
____________