Author |
Message |
|
Since today the new WUs that got released into the buffer are all tasks that have already been completed by a single host (Initial replication of 1).
Is there a high probability that primes were missed or how come those tasks have to be re-checked? |
|
|
|
If it is the case, that results of tasks with minimum quorum of 1 cannot be trusted, why use adaptive replication at all? |
|
|
John Honorary cruncher
 Send message
Joined: 21 Feb 06 Posts: 2875 ID: 2449 Credit: 2,681,934 RAC: 0
                 
|
Since today the new WUs that got released into the buffer are all tasks that have already been completed by a single host (Initial replication of 1).
Is there a high probability that primes were missed or how come those tasks have to be re-checked?
We invite independent searchers to upload their residues. These tests are completed outside of PrimeGrid. Therefore, the error rate of these hosts are unknown. We have now reached a range that had a lot of activity outside of PrimeGrid.
For all imported residues, a full double check is completed. For candidates that don't have imported residues, they are handled through AR.
By having independent searchers upload their residues, this allows us to save a good deal of extra testing. Only a single test is needed to confirm those tests are valid.
____________
|
|
|
|
... and now many of those get "aborted by project"...
what's up with that?! |
|
|
|
... and now many of those get "aborted by project"...
what's up with that?!
I am experiencing the same behavior.
When I look at the details of the workunit I see they have been aborted numerous times on different hosts but never completed and validated.
here is an example:
http://www.primegrid.com/workunit.php?wuid=183628924 |
|
|
|
Same here - it appears to be a general problem with PPS LLR and i've seen another server abort in the last hour.
Admins - any idea what the problem is here? |
|
|
|
Seems like the problem got fixed...
I still get WU's that have been "aborted by server" numerous times (http://www.primegrid.com/workunit.php?wuid=183651101)
but my computation doesn't get stopped by server anymore... |
|
|
|
Not that I want to complain or anything but...
How many of those "imported residues"-double-checker WU's remain in the buffer?
Because I like to search for primes and not only to double-check 'old' results... |
|
|
|
While I can't answer your question directly, don't write off double-checks as a way to find primes. I got one in another project which was explicit double check testing, and it was the 56th biggest known prime at the time. |
|
|
mfbabb2 Volunteer tester
 Send message
Joined: 10 Oct 08 Posts: 510 ID: 30360 Credit: 11,549,356 RAC: 0
                    
|
One of the reasons for the double check is to make sure nothing got missed!
____________
Murphy (AtP)
|
|
|
|
One of the reasons for the double check is to make sure nothing got missed!
Captain Obvious.
____________
|
|
|
John Honorary cruncher
 Send message
Joined: 21 Feb 06 Posts: 2875 ID: 2449 Credit: 2,681,934 RAC: 0
                 
|
Not that I want to complain or anything but...
How many of those "imported residues"-double-checker WU's remain in the buffer?
Because I like to search for primes and not only to double-check 'old' results...
Double checks are inherent in all LLR projects. There are millions of imported residues but compared to our entire search space, a very small percentage.
The 900K-920K range just happened to be widely searched and to a lesser degree, the 920K-940K. Not all k's were searched so there's still first pass work going out. After 940K, we will return to "normal" activity.
We are currently at 908K; so we should reach 920K in less than a week. Of course, the more resources, the faster we'll get through it. ;)
____________
|
|
|