-   Five or Bust - The Dual Sierpinski Problem (
-   -   PRP discussion thread (

philmoore 2009-05-04 11:21

I see that our currently active reservations span a range of 240,000 and have all been reserved within the past 3 weeks! It may be some time before this happens again. Welcome, new participant "unconnected"!

Jeff Gilchrist 2009-07-16 19:29

Everyone using Prime95/mprime may want to upgrade to the new 25.11 version announced here: [url][/url]

There is a speedup for zero-padded FFTs. I saw an increase in speed from 0.011 sec iteration time to 0.009 sec.


paleseptember 2009-07-22 01:05

I'm not seeing that scale of improvement, previously at 0.011s, still at 0.011s. The expected improvement was only 3-4%, so I could just be within that significant figure. Hopefully other people will see more impressive improvement!

engracio 2009-07-22 01:30

I hate to say it, I actually went back so I put back the old .exe. Does this update have any other upgrades or was it just some minor bug fixes??

Paleseptember, I saw you post and I thought dang he found another prime, lucky dingo.

Jeff Gilchrist 2009-07-22 19:10

[QUOTE=engracio;182166]I hate to say it, I actually went back so I put back the old .exe. Does this update have any other upgrades or was it just some minor bug fixes??[/QUOTE]

It was mostly improvements for other non-GIMPS projects (such as this one) but not major bug fixes. If your old binary is faster, just continue using that. What kind of processor do you have?

Mine (Core 2) is now at 0.010s almost a week later so still faster but not as much as before. Maybe I'm now just hitting a slightly higher range so it rolled from 0.009 to 0.010.

engracio 2009-07-23 03:00

Core 2 also, might have been the wu too. Oh well.:smile:

paleseptember 2009-07-23 05:37

Any improvement is good! A 3% speed increase on my current workunits helps by 23mins. Every little bit helps :]

engracio 2009-07-26 18:23

Yep I am sticking to 25.9.4 since I tried to use the 25.11 new client and it went down from .011/sec to .012/sec on my Q6600 boxes. I let them run on the same wu but different version. .001/sec might not be much but everything helps.

As stated it was a minor upgrade so I am sticking to the older ver.:smile:

philmoore 2009-09-15 22:48

double checking residues
Just a bit of news, and an invitation to weigh in on the issue of double checking. Ben and I are currently double checking all the residues for exponents between zero and 1.24 million (but only for the 40291 and 41693 sequences.) The principal reason for this is that these candidates were all originally checked with pfgw version 20050213, which had some problems with FFT boundaries, and sometimes returned "ERROR IN PROCESSING" messages when errors were detected. The problems were particularly severe for the 2131 sequence, and many residues had to be retested with the older 20041129 version of pfgw, slower by a factor of 2, but apparently accurate and stable. Pfgw only did error checking on the first 25 and the last 25 iterations, so some times, errors were not detected but the residues were still wrong. These undetected errors often occurred near other detected errors, so I generally ran long sequences of retests in the vicinity of any "ERROR IN PROCESSING" messages. But we still cannot rule out the possibility of other errors in this data, hence the retest. I did have some errors in the 40291 sequence, but not in the 41693 sequence, and I am wondering if pfgw just did not happen to detect some errors there. Our retesting should require a total of about 1.5% of our total prp effort to date.

I began using Prime95, version 25 for exponents starting at 1.24 million, slightly smaller for 2131. Therefore, our double checking should provide us with a complete set of Prime95 residues for all exponents up through our current ranges. I hope to be able to verify most of the residues below 1.24 million using the older pfgw data.

I have had the general impression that our data since the project initiation last October at n > 1.4 million has been quite accurate. I have checked a few of Ben's and Engracio's residues and found no discrepancies. Nevertheless, an undetected error at a low exponent could cause us to unnecessarily search to an extremely high n value. Seventeen or Bust has found two of their eleven primes so far by double checking. Reports are that their error rates were considerably higher than GIMPS, so apparently there were some unstable machines returning results for awhile. Serge has suggested doing some selective double-checking to get an idea of our accuracy rate. We could also do some systematic double checking of the smaller exponent values, but knowing our accuracy rate would help us choose an optimal goal if we also do systematic double checking. We could start by checking, say, a random 1% of our tests over the entire range (for just the 40291 and 41693 sequences, of course.)

Any comments or suggestions?

mdettweiler 2009-09-16 01:03

One comment: Based on what you were saying, it sounds like you're doublechecking all five original sequences. Since PRPs have already been found for three of those, as far as the conjecture is concerned, there's no need to bother with those at all now. Of course, there is always the chance of a lower prime having been missed, which could be possibly useful to check for.

BTW: for the tests that you've had to re-do with an older version of PFGW, would it be possible to simply use the latest version of PFGW (3.2.2)? Ever since 3.2.0 PFGW has given true 64-bit residuals rather than the 62-bit ones from before, so the first character of most residuals will be different from those produced by earlier versions, but the remaining part of the residual is compatible, and just as useful for doublechecking purposes. As long as you ignore the first digit (which can be rather easily screened out with a simple script), you should be able to take advantage of the full speed of the latest versions. You could even use Prime95 v25.11 for this as long as you do the same thing with the residuals--both Prime95 v25.11 and PFGW v3.2.2 should be the exact same speed.

paleseptember 2009-09-16 01:25

Double-checking is only being done for the two open sequences. I think if the error rate is minimal, we should continue to focus on first-pass testing. If the error rate is significant, well, further discussion is required.

All times are UTC. The time now is 05:32.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.