|
multiple (3+) Unverified LL -- how common?
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. |
[QUOTE=S34960zz;259301]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?[/quote]Depends on your definition of "common". It's much less than 1% of the time, but I've seen it happen before. [quote]When there are multiple (3+) mis-matched residues, are more than two matching residues required (perhaps 3 of 5, not just 2 of 4) ?[/quote]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. [quote]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.[/QUOTE]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? |
[QUOTE=cheesehead;259310]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?[/QUOTE]
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. |
[QUOTE=S34960zz;259312]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.[/QUOTE]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. |
When I downloaded the data for [URL="http://www.mersenneforum.org/showpost.php?p=243380&postcount=28"]plotting the error rate[/URL] 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).
|
[QUOTE=patrik;259387]When I downloaded the data for [URL="http://www.mersenneforum.org/showpost.php?p=243380&postcount=28"]plotting the error rate[/URL] 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).[/QUOTE]
Is this about the number you'd expect by chance? (I don't know the overall numbers or I could calculate it.) |
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: [CODE]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 [/CODE]138 tests are unaccounted for, since they are unverified with two or more [I]matching[/I] residues, i.e.they have been reported twice (or more) by the same user. |
Patrik: Thanks for all the detail and cross-reference to your previous analysis.
[QUOTE=patrik;259479]138 tests are unaccounted for, since they are unverified with two or more [I]matching[/I] residues, i.e.they have been reported twice (or more) by the same user.[/QUOTE] "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: [url]http://www.mersenneforum.org/showthread.php?t=15353[/url]) |
[QUOTE=S34960zz;259518]"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: [url]http://www.mersenneforum.org/showthread.php?t=15353[/url])[/QUOTE]
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). |
It is actually "same random shift count" regardless of user and CPU. :smile:
|
This was the "record" (most unverified tests per exponent) before I realized that I ought to filter these out.[CODE]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 [/CODE] |
Isn't it nice to have a record in something? :w00t:
It was a database hiccup. Some V5 switchover childhood disease? Ah, the good ol' days... |
[QUOTE=ckdo;259524]It is actually "same random shift count" regardless of user and CPU. :smile:[/QUOTE]
So, if I'm understanding you correctly, someone could doublecheck their own first-time test, and have the result accepted as a full verification, as long as the shift count is different? |
[QUOTE=mdettweiler;259561]So, if I'm understanding you correctly, someone could doublecheck their own first-time test, and have the result accepted as a full verification, as long as the shift count is different?[/QUOTE]
Yes. OTOH you can not simply create two accounts and submit all results twice. Compare [URL="http://www.mersenneforum.org/showthread.php?t=10680"]here[/URL], for example. |
[QUOTE=ckdo;259564]Yes. OTOH you can not simply create two accounts and submit all results twice. Compare [URL="http://www.mersenneforum.org/showthread.php?t=10680"]here[/URL], for example.[/QUOTE]
Ah, makes sense. Thanks! :smile: |
[QUOTE=cheesehead;259335]<snip> 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.[/QUOTE]
This might be a reasonable question to ask of a machine -- approximate elevation. That bias might provide a good measure of cosmic ray error frequencies! (But my machines at "robotics" might cheat...they live in the UVA (decomissioned) nuclear reactor building, and, while radiation is supposed to be close to background, I have no real proof of that) |
[QUOTE=patrik;259387]When I downloaded the data for [URL="http://www.mersenneforum.org/showpost.php?p=243380&postcount=28"]plotting the error rate[/URL] 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).[/QUOTE]
Just for fun I cleared [URL="http://mersenne.org/report_exponent/?exp_lo=41940097&exp_hi=10000&B1=Get+status"]41940097[/URL]. |
[QUOTE=sdbardwick;259688]Just for fun I cleared [URL="http://mersenne.org/report_exponent/?exp_lo=41940097&exp_hi=10000&B1=Get+status"]41940097[/URL].[/QUOTE]
That doesn't quite make sense --- do you mean you re-did the LL test and got a matching residue? That would take me a month and a half or so. Or did you get a factor from P-1 testing? Or something else? I'm willing to let a core do some backup checking when there's a good reason like this, as soon as the next box is up and running. |
Double check LL on 4 cores of i5-2500k.
|
[QUOTE=Christenson;259693]That doesn't quite make sense --- do you mean you re-did the LL test and got a matching residue? That would take me a month and a half or so. Or did you get a factor from P-1 testing? Or something else?[/QUOTE]
The link provided ([url]http://mersenne.org/report_exponent/?exp_lo=41940097&exp_hi=10000&B1=Get+status[/url]) shows a full LL test by "Fade Out". For those with enough cores and clock speed, it can be done. 27 Apr 11 01:38 sdbardwick reports "cleared" 23 Apr 11 08:52 patrik reports "5 failures for exponent 41940097" ==================== 3 days 16.75 hours more-or-less, call it 3.67 days. Using 3 of 4 cores i7-QM840 @ 1.87 GHz, I can clear a 26xxxxxx exponent in 87 to 90 hours (3d-15h to 3d-18h). Somebody using 4 or 6 cores and a clock twice as fast would have no problem turning around a 42xxxxxx exponent in that amount of time. |
[QUOTE=S34960zz;259699]For those with enough cores and clock speed, it can be done.[/QUOTE]The test takes [url=http://mersenne-aries.sili.net/credit.php?worktype=LL&exponent=41940097]61.8GHz-days[/url] of work. A single stock-speed (3.3GHz) i5-2500K core should produce about [url=http://mersenne-aries.sili.net/throughput.php?cpu1=Intel%28R%29+Core%28TM%29+i5-2500K+CPU+%40+3.30GHz|256|6144&mhz1=3300]5.7GHz-days of work per day[/url]. Assuming decent scaling to 4 cores, that's ~22GHz-days/day, so under 3 days. If the i5 is overclocked to 4.6GHz (which is not too uncommon) it could be done in 2 days flat.
|
[QUOTE=S34960zz;259301]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. [/QUOTE] Follow-up: the 4th LL result [07-June] matched the 2nd LL result (my contribution). Two matching LL, two non-matching LL. [URL]http://www.mersenne.org/report_exponent/?exp_lo=26505287&B1=Get+status[/URL] And ... it's not prime. |
getting to verified
[QUOTE=S34960zz;259301]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.[/QUOTE] 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? |
DC
[QUOTE=S34960zz;259312]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.[/QUOTE] what does DC stand for? |
[QUOTE=woody;265800]what does DC stand for?[/QUOTE]
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 [url]http://www.mersenne.org/various/math.php[/url] to put a skeleton on the argtot.... |
[QUOTE=Christenson;265807]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.[/QUOTE] One detail: it's not the assignment ID - it's a random shift. From [url]http://www.mersenne.org/various/math.php[/url]: [QUOTE]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.[/QUOTE] 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. |
[QUOTE=woody;265800]what does DC stand for?[/QUOTE]
A 'DC' disambiguation page has now been added to the [URL="http://mersennewiki.org/"]MersenneWiki[/URL]. |
| All times are UTC. The time now is 17:00. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.