20090504, 11:21  #34 
"Phil"
Sep 2002
Tracktown, U.S.A.
1118_{10} Posts 
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"!

20090716, 19:29  #35 
Jun 2003
Ottawa, Canada
2×3^{2}×5×13 Posts 
Everyone using Prime95/mprime may want to upgrade to the new 25.11 version announced here: http://www.mersenneforum.org/showthread.php?t=12155
There is a speedup for zeropadded FFTs. I saw an increase in speed from 0.011 sec iteration time to 0.009 sec. Jeff. 
20090722, 01:05  #36 
Jun 2008
Wollongong, .au
267_{8} Posts 
I'm not seeing that scale of improvement, previously at 0.011s, still at 0.011s. The expected improvement was only 34%, so I could just be within that significant figure. Hopefully other people will see more impressive improvement!

20090722, 01:30  #37 
May 2007
11^{2} Posts 
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. Last fiddled with by engracio on 20090722 at 01:32 
20090722, 19:10  #38  
Jun 2003
Ottawa, Canada
2×3^{2}×5×13 Posts 
Quote:
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. 

20090723, 03:00  #39 
May 2007
79_{16} Posts 
Core 2 also, might have been the wu too. Oh well.

20090723, 05:37  #40 
Jun 2008
Wollongong, .au
183_{10} Posts 
Any improvement is good! A 3% speed increase on my current workunits helps by 23mins. Every little bit helps :]

20090726, 18:23  #41 
May 2007
11^{2} Posts 
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. 
20090915, 22:48  #42 
"Phil"
Sep 2002
Tracktown, U.S.A.
2·13·43 Posts 
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 doublechecking 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? 
20090916, 01:03  #43 
A Sunny Moo
Aug 2007
USA (GMT5)
3·2,083 Posts 
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 redo 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 64bit residuals rather than the 62bit 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 residualsboth Prime95 v25.11 and PFGW v3.2.2 should be the exact same speed. Last fiddled with by mdettweiler on 20090916 at 01:07 
20090916, 01:25  #44 
Jun 2008
Wollongong, .au
3·61 Posts 
Doublechecking is only being done for the two open sequences. I think if the error rate is minimal, we should continue to focus on firstpass testing. If the error rate is significant, well, further discussion is required.
Last fiddled with by paleseptember on 20090916 at 01:27 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
P1 discussion thread  Rincewind  Five or Bust  The Dual Sierpinski Problem  57  20110206 21:53 
Sieving discussion thread  jasong  Twin Prime Search  311  20101022 18:41 
Sieving discussion thread  philmoore  Five or Bust  The Dual Sierpinski Problem  66  20100210 14:34 
Theological Discussion Thread  clowns789  Soap Box  3  20060309 04:05 
New Sieve Thread Discussion  Citrix  Prime Sierpinski Project  15  20050829 13:56 