multiple (3+) Unverified LL -- how common?

[S34960zz]

One of my computers performed a double-check LL on an exponent 26,xxx,xxx. When the residue was submitted to PrimeNet, it did not match the first result, so both results were noted as "Unverified LL" and the exponent was assigned to a third computer for re-evaluation.

That third result was submitted a few days ago. None of the first three residues match, and the exponent is presently out for its fourth LL test.

Is this common? Not _un_common?

When there are multiple (3+) mis-matched residues, are more than two matching residues required (perhaps 3 of 5, not just 2 of 4) ?

+++++

As a matter of curiosity, shortly after the result from my computer (second test) did not match the result from the first test, I re-ran the exponent off-line over a long weekend using 4 cores; that private test came back with the same result as my officially submitted result. So I'm quite curious about the final results for this exponent.

[cheesehead]

Originally Posted by S34960zz

One of my computers performed a double-check LL on an exponent 26,xxx,xxx. When the residue was submitted to PrimeNet, it did not match the first result, so both results were noted as "Unverified LL" and the exponent was assigned to a third computer for re-evaluation.

That third result was submitted a few days ago. None of the first three residues match, and the exponent is presently out for its fourth LL test.

Is this common? Not _un_common?

Depends on your definition of "common". It's much less than 1% of the time, but I've seen it happen before.

When there are multiple (3+) mis-matched residues, are more than two matching residues required (perhaps 3 of 5, not just 2 of 4) ?

No, just two.

BTW, there are some people who are systematically conducting triple-checks and even quadruple-checks where there are already two matching residues. You can see some examples of a third LL check even though the first two matched, in the exponent status report, or LL results report, for 1499001-1500000. There are examples of a fourth LL check even though the first three matched, in the exponent status report, or LL results report, for 499001-500000.

Their progress is, of course, slower than the leading edge of LL and DC reports, but eventually they'll reach the exponents that are now being reported as DCs.

AFAIK they haven't yet uncovered any instance where two earlier matching residues were later shown to be erroneous.

As a matter of curiosity, shortly after the result from my computer (second test) did not match the result from the first test, I re-ran the exponent off-line over a long weekend using 4 cores; that private test came back with the same result as my officially submitted result. So I'm quite curious about the final results for this exponent.

That you can reproduce it on your system is a good indication that your result will eventually be shown to be correct. Have you ever had any of your other reported DC results not match the earlier residue in the database?

[S34960zz]

Originally Posted by cheesehead

That you can reproduce it on your system is a good indication that your result will eventually be shown to be correct. Have you ever had any of your other reported DC results not match the earlier residue in the database?

I only have this one not-match example. Just wondered about verification procedure when this happens.

The only reason I would expect my private DC to be consistent (with prior computation) but not to be _correct_ (mathematically) would be if there was an issue between software versions and the version I used had a bug. The private-double-check was on the same machine, but run as 1-worker 4-thread, compared to original as 1-worker 1-thread (mostly), so the computation hardware was "different" / varied.

My recent work has been a handful of DC (all but one match original LL) and first-time LL (nothing to compare with, yet) plus trial factoring (on my main laptop plus a netbook).

The first-time LL work I did (2001-2005 timeframe) was on a different computer and the online "look at results" stuff was different back then. I probably ought to go look, just for fun.

[cheesehead]

Originally Posted by S34960zz

The only reason I would expect my private DC to be consistent (with prior computation) but not to be _correct_ (mathematically) would be if there was an issue between software versions and the version I used had a bug. The private-double-check was on the same machine, but run as 1-worker 4-thread, compared to original as 1-worker 1-thread (mostly), so the computation hardware was "different" / varied.

The code that computes the residue is pretty thoroughly tested now for several years, and hasn't changed.

The chances of a mismatch because of a hardware malfunction are much higher than the chances of a software bug that would affect the residue but show no other symptoms of error.

Hardware glitches happen all the time on overclocked or inadequately cooled systems, or with memory chips of inferior quality, and even because of cosmic rays (seriously). If the GIMPS database had data on the altitude of each system that reported a result, we could probably see a small bias toward more errors from systems at higher altitudes -- seriously.

[patrik]

When I downloaded the data for plotting the error rate on December 25, 2010, there were 376 exponents with three or more non-matching residues. Of these 14 have four or more non-matching residues, and one has five (41940097).

[CRGreathouse]

Originally Posted by patrik

When I downloaded the data for plotting the error rate on December 25, 2010, there were 376 exponents with three or more non-matching residues. Of these 14 have four or more non-matching residues, and one has five (41940097).

Is this about the number you'd expect by chance? (I don't know the overall numbers or I could calculate it.)

[patrik]

I'm not sure how to compute this, since exponents disappear from the list of unverified exponents as soon as they are verified (so there is also a time factor). The exponents that could be easier to estimate would be those above the leading edge of double-checking (around 27M). 310 of the 376 triples are above 27M (including all with 4+ tests).

The ones that have more than one test above the leading edge of double-checking are mostly those that had an error code in the first test. However, a few of these are still good and will disappear from the unverified list after the second test. The last test can also be a bad test but with a zero error code. There were 448289 unverified tests above 27M in the list, and of these 12354 have non-zero error code.

For exponents above 27M, the number of exponents with non-matching residues are:

precisely 1 test: 424270 exponents
precisely 2 tests: 11468 exponents
precisely 3 tests:   296 exponents
precisely 4 tests:    13 exponents
precisely 5 tests:     1 exponent

138 tests are unaccounted for, since they are unverified with two or more matching residues, i.e.they have been reported twice (or more) by the same user.

[S34960zz]

Patrik: Thanks for all the detail and cross-reference to your previous analysis.

Originally Posted by patrik

138 tests are unaccounted for, since they are unverified with two or more matching residues, i.e.they have been reported twice (or more) by the same user.

"Same user" or "same computer" -- presumably PrimeNet distinguishes at the per-machine level, since some users represent many (for many := from two to hundreds) machines. Admittedly, the same user (machine) getting the same exponent to re-test seems somewhat unlikely, until one considers the relatively small number of users, some with multiple machines, and large numbers of exponents being tested, at which point "unlikely" turns back into "likely, soon enough." (For a variant of this thought, see also: http://www.mersenneforum.org/showthread.php?t=15353)

[mdettweiler]

Originally Posted by S34960zz

"Same user" or "same computer" -- presumably PrimeNet distinguishes at the per-machine level, since some users represent many (for many := from two to hundreds) machines. Admittedly, the same user (machine) getting the same exponent to re-test seems somewhat unlikely, until one considers the relatively small number of users, some with multiple machines, and large numbers of exponents being tested, at which point "unlikely" turns back into "likely, soon enough." (For a variant of this thought, see also: http://www.mersenneforum.org/showthread.php?t=15353)

Hmm...I would think that PrimeNet would need to distinguish solely at the per-user level, just to be on the safe side, in case of someone reinstalling Prime95 on the same computer and choosing a different computer name. (I can imagine this happening quite easily--say, someone reinstalls their OS and capitalizes the machine name differently; or they decide to use a personalized computer name instead of the default-assigned one; etc.)

Presumably, the system is designed to avoid even assigning a DC to a user who's already submitted an LL test of any kind for that exponent; most likely, the results in the database reported multiple times by the same user were the result of something outside of PrimeNet's direct control, such as someone choosing an assignment manually, or a computer re-testing the same exponent due to disk/permissions hangups (not an uncommon issue by any means).

[ckdo]

It is actually "same random shift count" regardless of user and CPU.

[patrik]

This was the "record" (most unverified tests per exponent) before I realized that I ought to filter these out.

Exponent,User name,Computer name,Residue,Error code (if any),Date found
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 18:55
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 18:58
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:03
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:06
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:08
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:11
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:16
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:19
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:22
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:25
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:29
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:32
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:42
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:45
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:55
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 19:59
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 20:08
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 20:11
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 20:21
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 20:24
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 20:34
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 20:37
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 20:47
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 20:50
37307737,Serge Batalov,Q6600F,2A0BDF36A0D073__,,2008-07-08 20:51