mersenneforum.org An unnecessary triple check ?
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

 2008-09-20, 07:03 #1 S485122     Sep 2006 Brussels, Belgium 2×5×167 Posts An unnecessary triple check ? I have been assigned the exponent 18992531 for a double check. When I look in the V5 database I get the following result : Unverified test results Exponent,User name,Computer name,Residue,Error code (if any),Date found 18992531,C. Cooper / S. Boone,wde2610-21,2FF535C1CB3A92__,, 18992531,C. Cooper / S. Boone,hum115-009,2FF535C1CB3A92__,, As far as can see the exponent IS already verified. Of course if both results where turned in with the same shift value, the second result cannot be counted as a verification. I regret the loss of shift data that is a consequence of the migration of the database to V5 (there where some 780000 results with and 250000 without such a value in the latest LUCAS_V.) There is the possibility that the data is still in the database but that it is intentionnally hidden. Jacob
 2008-09-20, 11:29 #2 Mini-Geek Account Deleted     "Tim Sorbera" Aug 2006 San Antonio, TX USA 10AB16 Posts Besides the shift value possibly being the same, it's possible that there's a difference in the last two hidden hex digits. I have to admit, that does seem pretty unlikely (with all other digits matching), but it is a possibility.
 2008-09-20, 11:50 #3 Brian-E     "Brian" Jul 2007 The Netherlands 63058 Posts Somewhere (sorry, I cannot remember where) I remember reading that an exponent must be independently re-checked by someone else if both completed LL-tests were completed by the same person - or, in this case, team of two. I did read that it would then be re-checked by specific machines at PrimeNet, but maybe the double testing by the same user is happening too frequently for that to be possible nowadays.
 2008-09-20, 13:32 #4 markr     "Mark" Feb 2003 Sydney 23D16 Posts The last ever hrf3.txt (the old file of unverified LL results) from February has the same two results, so the v4 server also thought they didn't add up to a verified result. Code: 18992531,curtisc,wde2610-21,WZ5,00000000 18992531,curtisc,hum115-009,WY5,00000000 Note that hrf3.txt didn't show shift values either; it's not just a v5 feature.
2008-09-22, 21:02   #5
S00113

Dec 2003

23×33 Posts

Quote:
 Originally Posted by S485122 I have been assigned the exponent 18992531 for a double check. When I look in the V5 database I get the following result : Unverified test results Exponent,User name,Computer name,Residue,Error code (if any),Date found 18992531,C. Cooper / S. Boone,wde2610-21,2FF535C1CB3A92__,, 18992531,C. Cooper / S. Boone,hum115-009,2FF535C1CB3A92__,, As far as can see the exponent IS already verified.
Both results were returned by the same person(s). In theory, since they had access to the first result, they could be cheating by reurning the same result again. For this reason GIPMS should not trust a double check done by the same person who did the first time check. It must be a bug which caused the double check assignment to go to the same tester in the first place.

2008-09-22, 21:39   #6

"Richard B. Woods"
Aug 2002
Wisconsin USA

1E0C16 Posts

Quote:
 Originally Posted by S00113 Both results were returned by the same person(s). In theory, since they had access to the first result, they could be cheating by reurning the same result again.
True.

Of course, a far more common reason is that users who are running lots of computers, like Cooper/Boone, occasionally accidentally duplicate a worktodo line on different systems.

Quote:
 For this reason GIPMS should not trust a double check done by the same person who did the first time check.
... regardless of the reason for, or suspicion about, duplication.

Quote:
 It must be a bug which caused the double check assignment to go to the same tester in the first place.
In the absence of data about the particular PrimeNet assignments involved, another possibility is that these were both, from the viewpoint of the systems running them, first-time tests -- neither was assigned as a double check. It's possible that PrimeNet actually made only one assignment, as a first-time test, to computer ID 'wde2610-21', then, on the Cooper/Boone end, some mistake caused computer 'hum115-009' to get a duplicate line in its worktodo.

Or it could have been that after 'wde2610-21' finished and reported its result, that computer failed, and Cooper/Boone then re-allocated its entire list of assignments, both completed and uncompleted, to system 'hum115-009' with only good intentions: in order to be sure that each test was successfully completed and reported.

PrimeNet won't reject any result report just because it's from a computer to which it had not assigned that exponent. It just won't credit that result to that user on the PrimeNet Top Producers list at http://mersenne.org/ips/tops.shtml (not to be confused with the GIMPS Top Producers list at http://www.mersenne.org/top.htm).

Last fiddled with by cheesehead on 2008-09-22 at 21:56

 2008-09-23, 05:02 #7 S485122     Sep 2006 Brussels, Belgium 32068 Posts With a team like Cooper/Boone I see one other and much simpler posibility : they were assigned the exponent as a first time check and some years later the exponent was assigned to them as a double check. I do not think PrimeNet verifies if the computer requesting doublecheck workunits is member of a team that already did the first time check pn the numbers it assigns. Jacob
2008-09-23, 05:06   #8
Uncwilly
6809 > 6502

"""""""""""""""""""
Aug 2003
101×103 Posts

2·4,787 Posts

Quote:
 Originally Posted by S485122 With a team like Cooper/Boone I see one other and much simpler posibility : they were assigned the exponent as a first time check and some years later the exponent was assigned to them as a double check. I do not think PrimeNet verifies if the computer requesting doublecheck workunits is member of a team that already did the first time check pn the numbers it assigns.
Something for the v5 server wishlist.

2008-09-23, 22:24   #9
Prime95
P90 years forever!

Aug 2002
Yeehaw, FL

22·1,873 Posts

Quote:
 Originally Posted by S485122 Exponent,User name,Computer name,Residue,Error code (if any),Date found 18992531,C. Cooper / S. Boone,wde2610-21,2FF535C1CB3A92__,, 18992531,C. Cooper / S. Boone,hum115-009,2FF535C1CB3A92__,, As far as can see the exponent IS already verified.
The shift count was identical. The run started on one computer and finished on two different computers. Not good enough to count as a double-check.

 2008-09-24, 13:41 #10 mdettweiler A Sunny Moo     Aug 2007 USA (GMT-5) 3×2,083 Posts Somewhat off-topic, but still related to the topic of extra unnecessary re-checks of exponents: just curious, if I was to do a doublecheck via V5, would V4 eventually do an unnecessary triple-check, since it won't be aware of the fact that it was previously done in V5? (Specifically, that is, if I was to pick out a particular exponent by hand--i.e., it's not in any "special" range that one server or the other has been pre-warned not to hand out?)

 Similar Threads Thread Thread Starter Forum Replies Last Post houding PrimeNet 14 2015-12-21 09:34 Bdot Software 5 2012-12-22 22:34 S485122 PrimeNet 8 2009-08-16 23:16 opyrt Prime Sierpinski Project 3 2009-01-02 01:50 GP2 Completed Missions 13 2004-08-12 00:41

All times are UTC. The time now is 07:24.

Fri May 14 07:24:09 UTC 2021 up 36 days, 2:05, 0 users, load averages: 1.54, 1.50, 1.65