On Sunday 09 June 2002 08:22, Daran wrote: > I'm currently concentrating exclusively on P-1 work. The primenet server > doesn't support this as a dedicated work type, so my procedure is to > reserve some DC exponants, imediately unreserve any which have the P-1 bit > already set, P-1 test the rest, then unreserve them without doing any LL > testing. > > One problem I have discovered is that the server doesn't always 'recognise' > that a P-1 result has been returned. It can take several days before my > individual account report removes the * indicating that factoring work is > necessary. In these cases I hold on to the exponant until the result is > recognised in order to stop the subsequent 'owner' from doing a redundant > P-1 check. In other cases, the P-1 result is recognised imediately.
Though I'm not looking for P-1 specifically, I have seen something similar on a large number of occasions. My current assignment report - the DC part of which follows - contains a number of examples. 6493831 D 64 3.3 33.8 93.8 07-Jun-02 07:25 06-Jun-02 06:02 cabbage 0 v18 6530189 D 64 2.3 27.8 64.8 08-Jun-02 06:02 07-Jun-02 06:02 nessus-b 266 v19/v20 6672569 D 64 31.3 13.8 73.8 14-May-02 07:43 09-May-02 06:05 cabbage 0 v18 6881321 D 64 6.3 23.8 63.8 06-Jun-02 06:06 03-Jun-02 06:06 nessus-j 332 v19/v20 6972001 D* 64 0.3 14.7 60.7 09-Jun-02 04:02 caterpillar 654 v19/v20 7009609 D 63 3949088 24.3 9.8 64.8 07-Jun-02 06:04 16-May-02 06:06 nessus-m 266 v19/v20 7068857 D 63 5887578 25.3 0.8 60.8 06-Jun-02 06:06 15-May-02 06:05 nessus-j 332 v19/v20 7076669 D* 64 5617988 30.3 3.8 63.8 07-Jun-02 06:02 10-May-02 06:04 nessus-b 266 v19/v20 7099163 D 63 2693359 14.3 11.8 65.8 09-Jun-02 06:26 26-May-02 06:43 T4070 366 v19/v20 7908091 D 64 3080191 17.7 15.4 60.4 08-Jun-02 21:12 22-May-02 19:17 broccoli 400 v19/v20 7937717 D 64 2359295 10.5 7.6 60.6 09-Jun-02 02:04 30-May-02 00:30 caterpillar 654 v19/v20 7938407 D 64 1310720 10.3 12.3 60.3 08-Jun-02 20:29 30-May-02 04:16 vision.artb 495 v19/v20 7940447 D 64 9.8 16.8 65.8 09-Jun-02 06:24 30-May-02 17:39 Simon1 1002 v19/v20 7951049 D 64 65536 7.5 10.7 60.7 09-Jun-02 04:31 02-Jun-02 00:40 rhubarb 697 v19/v20 6972001 and 7076669 are "starred" although the "fact bits" column seems to indicate that both trial factoring to 2^63 and P-1 have been run. This is _definitely_ true for P-1 on 7076669, the fact is recorded on my system in both results.txt & prime.log. So far as 6972001 is concerned, the database (dated 2nd June) indicates P-1 has been run to a reasonable depth but trial factoring has only been done through 2^62. My system definitely won't have done any more trial factoring yet, let alone reported anything, since that system is set up with v22 defaults i.e. defer factoring on new assignments until they reach the head of the queue. 7009609, 7068857 & 7099163 are not "starred" although the "fact bits" column is one short. The "nofactor" & "Pminus1" databases (dated 2nd July) give these all trial factored through 2^62 & Pminus1 checked to B1=35000, B2=297500 (or higher). The P-1 limits seem sensible for DC assignments, but shouldn't these have been trial factored through 2^63 like most of the other exponents in this range? > > Currently, I have nine exponants 'warehoused' whose P-1 results have been > returned but not recognised, the oldest was done on May 14, which is rather > longer than I would expect. There's no question that the server has > correctly recieved the result, because it is contained in a recent version > of the pminus1.zip file downloaded this morning along with another four > exponants 'warehoused' from May 20. Three more, whose results were > returned on June 3 have not yet been recorded in this file. > > There is an entry in the file for the last of the nine, returned on June 5, > but the limits are much smaller than the test I did. The most likely > explanation is this is a previous owner's P-1 result which wasn't > recognised before the exponant was given to me. I wonder what happens if you're working like Daran and someone returns a P-1 result "independently" (either working outside PrimeNet assignments, or perhaps letting an assigned exponent expire but then reporting results); if PrimeNet gets two P-1 results for the same exponent, which does it keep? This is not trivial; e.g. if you get "no factors, B1=100000, B2=1000000" and "no factors, B1=200000, B2=200000" there might still be a factor which would be found if you ran with B1=200000, B2=1000000. Also, if the database says that P-1 stage 1 only has been run (probably due to memory constraints on the system it ran on), at what point is it worthwhile running P-1 for the possible benefit of finding a factor in stage 2? > > Does anyone have any idea what is going on? If this problem could be > ironed out/worked around, then a separate P-1 work type could be > implemented in the client using the procedure outlined in the first > paragraph above, without any changes to the server software. Nope, it's all a bit mysterious. I guess we should expect the odd discrepancy so long as the "official" & server databases are maintained seperately, and until the server can cope with P-1 assignments directly. Daran, my advice would be to concentrate on exponents above the current DC assignment range which have already been LL tested but not P-1 checked, or on exponents above the current LL assignment range which have been trial factored but not P-1 checked, according to the official database (updated weekly - you will need the pminus1, nofactor & hrf3 database files, plus the "decomp" utility to unscramble nofactor). Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
