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

[woody]

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?

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.

The process of doing another LL test to find a matching residue is giving me come concern. If errors are in fact machine dependent rather than say caused by cosmic rays, then doing a LL retest on the same type of machine will find a "verified" residue. Are any checks built in to ensure that a different machine type is used?

[woody]

Originally Posted by S34960zz

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.

what does DC stand for?

[Christenson]

Originally Posted by woody

what does DC stand for?

Whoops, we do talk in code. DC = LL-D = Double-Check Lucas-Lehmer Test or Lucas-Lehmer Double check. These two bits of alphabet soup get used interchangeably.

And what you missed was that even if you do a DC on the same machine you did the original ll (lucas-Lehmer) test on, the security code 9through the assighment ID) effectively scrambles the bit pattern you are manipulating, similar to a cipher where some bits are exclusive-or'ed wtih the message.

Thus, if your computer is functioning close to correctly, it will not be manipulating exactly the same bit patterns, and any kind of systematic problem is likely to manifest itself as a different residue, which then doesn't match the first.

The theory of this works very much like a cyclic redundancy check used on communications lines, except in this case the computer running the LL or LL-D is the channel and the residue is the output.

Oh, and do look at http://www.mersenne.org/various/math.php to put a skeleton on the argtot....

[markr]

Originally Posted by Christenson

And what you missed was that even if you do a DC on the same machine you did the original ll (lucas-Lehmer) test on, the security code 9through the assighment ID) effectively scrambles the bit pattern you are manipulating, similar to a cipher where some bits are exclusive-or'ed wtih the message.

Thus, if your computer is functioning close to correctly, it will not be manipulating exactly the same bit patterns, and any kind of systematic problem is likely to manifest itself as a different residue, which then doesn't match the first.

One detail: it's not the assignment ID - it's a random shift. From http://www.mersenne.org/various/math.php:

GIMPS double-checking goes a bit further to guard against programming errors. Prior to starting the Lucas-Lehmer test, the S0 value is left-shifted by a random amount. Each squaring just doubles how much we have shifted the S value. Note that the mod 2P-1 step merely rotates the p-th bits and above to the least significant bits, so there is no loss of information. Why do we go to this trouble? If there were a bug in the FFT code, then the shifting of the S values ensures that the FFTs in the first primality test are dealing with completely different data than the FFTs in the second primality test. It would be near impossible for a programming bug to produce the same final 64 bit residues.

It would also be near impossible for a hardware problem to produce the same incorrect residue on two runs, even on the same machine. The shift is reported along with the other details of the result, and two results have to have different shifts to count as a match. And just to be clear, the random shift happens before each LL test, not just DCs.

[Uncwilly]

Originally Posted by woody

what does DC stand for?

A 'DC' disambiguation page has now been added to the MersenneWiki.