Re: Mersenne: End of list
At 10:38 AM 4/23/2004 -0700, John R Pierce wrote: say, who runs the DNS for mersenne.org ? ok, the domain is registered to George Woltman... so he'd have to contact sbsi-net to do this. Contact Scott at [EMAIL PROTECTED] He'll need to do whatever is required. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Where is M23494381?
At 10:48 AM 12/29/2003 +, Doug Feather wrote: I've had the same experience with some exponents assigned to me. My guess is that someone has been doing trial factoring work semi-independent of PrimeNet and has just reported all the work that they have done. This is probably a good explanation - especially in light of your point #2 1. For a long time on this page: http://mersenne.org/primenet/ there where no exponents in the range listed 21.9M to 22.0M. This has recently changed with them now all being listed as available for first time Lucas Lemer testing. These exponents were manually reserved a year and a half ago for some trial factoring work. Yesterday, I cancelled that reservation and added the exponents to the server. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: 40th Mersenne Prime verified and word is getting out
Hi all, Michael Shafer discovered the 40th known Mersenne prime, 2^20996011-1. Congratulations Michael. This prime is over 6.3 million digits, beating the previous world record prime by over 2 million digits. Scott has handed out the press release and already the first online article of the discovery has appeared: http://www.newscientist.com/news/news.jsp?id=ns4438 You can also read Scott's press release http://www.mersenne.org/20996011.htm I'll try to add more links to the http://mersenne.org web page as they become available. Well done everyone, George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: 50% CPU?
At 04:35 PM 11/3/2003 -0800, John R Pierce wrote: I don't know if the affinity stuff will work in linux, however.. Mprime ignores the affinity settings in the ini files. We'll have to add it when linux 2.6 is released. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Linux
At 04:48 AM 11/2/2003 -0600, Michael Kilfoyle wrote: George, et al: I have an old intel pentium pro server that i am converting to Linux. Once i get it going and have learner enough to be dangerous on the is OS I wan to add the prime search tools. Question is what version do i download. What is the difference between Mprime Sprime? The support web page tends to mix the OS and the architecture. SO for UNIX on SUN go one place for Intel go another place. So this is Intel (Compaq 5000 quad 200mhz pentium pro) and RedHat Linux. mprime and sprime are the same program just linked differently. Try mprime first. It uses less runtime memory (shares the C runtime library with other running programs). If that fails (I linked to one version of the C runtime libraries, but you have an incompatible set of runtime libraries installed), then try sprime. Regards, George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: version 23.5
At 10:40 PM 7/5/2003 +, Russel Brooks wrote: Speed improvements of 3 to 8% can be expected for Athlon, Duron, Pentium 3, and Celeron 2 owners. Is this speed improvement for LL tests only or will I also see a factoring improvement? LL and P-1 factoring will be faster. Trial factoring will be unchanged. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: version 23.5
Version 23.5 is available. See http://www.mersenneforum.org/viewtopic.php?t=3 for downloading links. This is a beta release, but should work OK. Speed improvements of 3 to 8% can be expected for Athlon, Duron, Pentium 3, and Celeron 2 owners. Four or five changes have been added to reduce the chance of another false prime report. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Error 12002
At 12:47 PM 7/1/2003 -0800, Gordon Bower wrote: Looking through the Forum archives it appears Error 12002 is a version 21-specific problem that occurs when entropia.com is down even if mersenne.org is up. On Saturday entropia.com was indeed down. However, entropia's website has been up since sometime Sunday, and I have *still* been getting hourly 12002s on three different systems. I would also ask the keeper of the faq to add a few new lines to it about these new (since 2 years or so ago) error messages that aren't described in the online information. As suggested, I've added error 12002 to the FAQ. I've also emailed Scott to see if he can get Entropia to restart GIMPS message forwarding process _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: M#40 - what went wrong?
At 07:52 PM 6/15/2003 -0700, Luke Welsh wrote: I'm fishing What about +/- INF ? Yes, they would be treated just like a NaN. Prime95 checks if the sum of the FFT inputs is NaN, or +/- INF every iteration (generating the common ILLEGAL SUMOUT error). What about corruption of any of the pre-computed arrays? Yes, if the first weight value was NaN, then that would corrupt the entire FFT data array. Of course, this generates an ILLEGAL SUMOUT on the next iteration, but if this single corruption happened during the last iteration then a false positive would have been generated. Version 23.5 will now detect this. I'm also adding code to 23.5 to check EVERY iteration for an impossible result such as -2, -1, 0, 1, 2. This test will be very, very quick. FYI, six times a result of 0002 has been reported to the server. So, somehow or another it is possible for a hardware error to zero the FFT data without triggering an ILLEGAL SUMOUT. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: M#40 verification runs completed
Hello all, It is official - not prime. Both Guillermo's Mlucas run and my prime95 run return a matching non-zero residue. We will never know what caused prime95 to generate a false positive, I am studying the code for ways in which a memory corruption could cause this. Something good will come from this sorry ending. I am confidant this incident will have little negative impact on GIMPS. While the episode was probably an unhappy roller-coaster ride for one individual, the false positive problem is far less damaging to GIMPS than the version 17 shift bug disaster. This incident illustrates why most other distributed projects keep any client finds secret (even from the discoverer) until verified. If we had a similar policy this could have been swept under the rug and no one would ever have known. I kind of like our policy though. It lets everyone in on the ups and downs of the project. Thanks to Guillermo and Ernst for dedicating time to the verification run. Best regards, George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: M#40 - what went wrong?
It was once thought that a false positive report couldn't happen. So what went wrong? So far I've come up with two possibilities. 1) The FFT data is zeroed AND does not go into the -2,2,2,2 loop. I don't know how the data gets zeroed, but I've seen it happen. It has happened a lot less often once code was added to reject any save file with all zero data. The not going into the -2,2,2,2 loop can happen with the corruption of a single local variable. I've just added code that makes sure this local variable is always in the range 0 = variable exponent. 2) This case results from the way my C compiler treats floating point NaN. NaN stands for not a number. If NaN is converted to an integer, the integer is zero. So if the FFT data is all NaNs, prime95 will report a prime. Prime95 check for NaNs every iteration, but if every FFT data value becomes NaN after the inverse FFT of the last LL iteration, then we get a false positive. Furthermore, corrupting a single value (the initial carry input to rounding and carry propogation code) could set every FFT data value to NaN. I've fixed the code to make sure there are no NaNs in the final is-it-a-prime check. Which of the above is more likely? I don't know. It seems the first requires two or more pieces of memory corrupted, but it leads to a steady state. So the errors can occur at any point during the LL test. The second case requires only one failure, but at a very specific point in time. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: M#40 verification run
I've tried to keep everyone promptly informed of Mersenne news - good or bad. So, here we go... My verification run of M#40 just completednot prime. Now we wait for Guillermo Ballester Valor's run to complete in the next few days. Our runs matched at 13 million iterations. Possibilities are: 1) The original run was flawed or there is a bug in the version of prime95 used. It is hard to imagine a bug or hardware glitch that generates an all zero LL result. If memory is zeroed at some point, the next LL iterations are -2, 2, 2, 2, ... 2) My overclocked machine generated an undetected error or the prime95 version I'm using has a bug that is affecting my result. 3) I was debugging an out-of-memory bug report last night. It is theoretically possible there is an OS bug that affects other processes in these severe circumstances. I have save files every million iterations. If this really is a new Mersenne prime, then I'll rerun the last iterations again to make sure the latest prime95 does not have a bug. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: M#40 verification run
More bad news to report. I've just gotten a hold of the results.txt file from the original run. There were five SUM(INPUTS) != SUM(OUTPUTS) error during the run. Historically, five errors during a run means there is less than a 50% chance the final LL result will be correct. Now I have to try and figure out what safety checks can be added to prevent false alarms. So far, I have 2 changes planned: 1) Prime95 does not tell the server how many errors occurred for an LL test with a prime result. I'll fix this. Knowing their were 5 errors would have raised red flags earlier on. 2) I'll change prime95 to NOT delete the save files when a new prime is found. When a prime is reported, I'll ask for the save file and rerun the last 30 minutes of the test. I think this would have helped in this case. This measure also deters a hacker. It might be easy for a hacker to spoof a prime report - but he'll have difficulty generating a save file that reports the number as prime after the final 30 minutes of LL testing. There is still a chance this really is prime, we'll know on Friday. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: 40th Mersenne Prime Found (probably)!
At 09:59 PM 6/2/2003 -0700, Brian Dessent wrote: Anyone want to submit this to e.g. slashdot? I wouldn't do that until the exponent is officially announced. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: servers down completely?
At 10:11 AM 3/23/2003 -0800, John R Pierce wrote: I can't even raise the mersenne website. getting errors on entropia.com/ips too, yet entropia.com's home page comes up fine. I just heard from Brad Bernard at Entropia. They are having major problems with their ISP. The T1 lines are down and may not be fixed until Monday. They and I apologize for the problem but are at the mercy of the ISP. --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.462 / Virus Database: 261 - Release Date: 3/13/2003
Re: Mersenne: Probability
At 01:35 AM 3/22/2003 -0500, The Pope Family wrote: I just found 4 factors in a row from exponents randomly assigned by the project. So, what's the chance of finding factors using Prime 95's default settings for four randomly assigned exponents in a row? The chance of trial factoring finding a factor is about 13%. The chance for four in a row is 0.13^4 or about 0.03% chance. --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.462 / Virus Database: 261 - Release Date: 3/13/2003
Re: Mersenne: P-1 on PIII or P4?
At 07:47 AM 3/11/2003 -0500, Richard Woods wrote: However, any difference in FFT size between a P4 and other CPU, because of SSE support/nonsupport, could make a difference to the algorithm because it _does_ take FFT size into account. There was a bug in calculating the the FFT size (bytes of memory consumed) for the P4. This bug caused the P-1 bounds selecting code to produce different results than the x86 code. This is a fairly benign bug and will be fixed in version 23.3 In case you care, the details are: There is a global variable called FFTLEN that is used in many places and is initialized by the FFT init routine. The routine to select the P-1 bounds is called before the FFT code is initialized. Thus, the routine to calculate the number of bytes consumed by an FFT cannot use the global variable FFTLEN. In fact, that routine is passed an argument - fftlen in lower case. Well, you guessed it, in the P4 section of the routine I referenced FFTLEN rather than fftlen. The routine worked fine once the FFT code was initialized - only the P-1 bounds selecting code was affected. BTW, the FFT size is more than FFT length * sizeof (double). There are various paddings thrown in for better cache usage. Sadly, if I had just used FFT length * sizeof (double) as an estimate for the size in selecting the P-1 bounds this bug never would have happened and the size estimate is more than accurate enough for the purposes of selecting bounds. --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/2003
Re: Mersenne: P-1 on PIII or P4?
At 01:16 AM 3/11/2003 +, Daran wrote: I don't think George's '1 or 2 extra temporaries' theory stands up. Sure it does. I fired up the debugger and the P4 has 5541 temporaries and the x86 has 89 temporaries. Hmmm, maybe I'd better look into it a little bit further --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/2003
Mersenne: V23.2 - more P4 speed enhancments
Version 23.2 seems stable enough to use. P4 owners should see a 4 to 6% improvement in LL speed over version 23.1 My own P4 Northwood (512K L2 cache) benchmarks are: V22.10 v23.1 V23.2 384K FFT17.123 16.801 15.845 448K FFT20.686 19.817 18.732 512K FFT23.347 22.669 21.693 640K FFT30.270 29.130 27.545 768K FFT37.036 35.847 33.829 896K FFT45.737 43.370 41.071 1024K FFT 49.389 47.776 44.949 1280K FFT 69.955 63.673 60.133 1536K FFT 85.890 77.668 73.334 1792K FFT 104.573 94.767 89.636 You can get the software at: Windows: ftp://mersenne.org/gimps/p95v232.zip Linux: ftp://mersenne.org/gimps/mprime232.tar.gz ftp://mersenne.org/gimps/sprime232.tar.gz NT service: ftp://mersenne.org/gimps/winnt232.zip Let me know if you run into any problems. Enjoy! --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
Mersenne: Re: New LL thresholds
At 11:12 AM 2/13/2003 +, Robin Stevens wrote: Out of interest, where's the threshold for factoring/double checks these days? In v23, I left the factoring/double-checking boundary at a 233 MHz Pentium. --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
Mersenne: Version 23.1 Linux and NT service
As requested, the other easy ports of v23.1 are now available: Windows: ftp://mersenne.org/gimps/p95v231.zip Linux: ftp://mersenne.org/gimps/mprime231.tar.gz ftp://mersenne.org/gimps/sprime231.tar.gz NT service: ftp://mersenne.org/gimps/winnt231.zip P.S. When comparing benchmarks between v22 and v23 be aware that the two versions time different FFT ranges, so make sure you look at the FFT size on each output line rather than simply comparing the first, second, third, etc. output lines. --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
Mersenne: Small exponents for first time testing
I'm releasing about 500 exponents below 15,000,000 for first time testing. These were originally reserved manually in 2001 but results have not been sent in. So for those that like to fine-tune their work, get 'em while the getting is good. Please keep hoarding to a minimum! --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
Mersenne: Prime95 version 23.1 - Pentium 4 improvements
Version 23.1 seems to be stable enough to use although its really still Beta software. I've not run the full QA suite as I have more changes planned. The Windows version is available at ftp://mersenne.org/gimps/p95v231.zip If there is interest I'll make a Linux version available too. Only P4 users need to download it. There are a number of small speed increases to the SSE2 code. The gains are greatest for P4 Celeron and P4 Northwood CPUs. The full text from whatsnew.txt: 1) Big SSE2 FFTs now take the L2 cache size into account. P4 Celeron (128KB L2 cache) is faster for FFTs between 512K and 2M. P4 Northwood (512KB L2 cache) is faster for FFTs larger than 1M. 2) Benchmark no longer times 256K and 320K FFTs, but does time 2048K FFT. 3) Support for torture testing FFT sizes from 1280K to 4096K added. 4) A 900 MHz P-III is now required to get first time LL tests by default. 5) Slightly faster SSE2 FFTs for lengths of 5*2^N and 7*2^N (e.g. 640K, 896K). One item missing from whatsnew.txt is prime95 now pages better, resulting in improved times for several FFT sizes not listed above. This came about from noticing that the debug version was faster than the release version. The debug malloc filled memory with a constant, thus making it more likely to be allocated in contiguous physical memory. Since the FFTs are designed to fill the L2 cache evenly when the FFT data is in contiguous memory, there is a significant speedup when the FFT code is using nearly all of the L2 cache. --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
Mersenne: version 23.1 timings
In case you are interested here are the before and after benchmarks for my own P4 Northwood: Intel(R) Pentium(R) 4 CPU 1.60GHz CPU speed: 2311.52 MHz L2 cache size: 512 KB Prime95 version 22.10, RdtscTiming=1 Best time for 384K FFT length: 17.123 ms. Best time for 448K FFT length: 20.686 ms. Best time for 512K FFT length: 23.347 ms. Best time for 640K FFT length: 30.270 ms. Best time for 768K FFT length: 37.036 ms. Best time for 896K FFT length: 45.737 ms. Best time for 1024K FFT length: 49.389 ms. Best time for 1280K FFT length: 69.955 ms. Best time for 1536K FFT length: 85.890 ms. Best time for 1792K FFT length: 104.573 ms. Intel(R) Pentium(R) 4 CPU 1.60GHz CPU speed: 2311.38 MHz L2 cache size: 512 KB Prime95 version 23.1, RdtscTiming=1 Best time for 384K FFT length: 17.175 ms. Best time for 448K FFT length: 20.320 ms. Best time for 512K FFT length: 23.232 ms. Best time for 640K FFT length: 29.986 ms. Best time for 768K FFT length: 36.869 ms. Best time for 896K FFT length: 44.585 ms. Best time for 1024K FFT length: 48.950 ms. Best time for 1280K FFT length: 65.557 ms. Best time for 1536K FFT length: 80.381 ms. Best time for 1792K FFT length: 98.204 ms. --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
Mersenne: Double-checking milestone!
Congratulations GIMPSters, Yesterday the last double-check below M(6972593) came in. This proves there are no undiscovered Mersenne primes below M(6972593) making it the 38th Mersenne prime. Thanks to everyone for all their hard work in making this milestone possible. Keep on crunching and have fun, George --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
Mersenne: An officially sanctioned poach....
It's been quite awhile since I've done a release of exponents that seem to be stuck - probably over a year. I've identified 185 exponents that have had NO progress reported and are either: a) Below 12,000,000 and been assigned for 200 days or more, or b) Between 12 and 20 million and been assigned for 300 days or more Does anyone see any problems with releasing these exponents back into the pool? _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: trial factoring
At 10:15 AM 1/8/2003 +0100, [EMAIL PROTECTED] wrote: Why is the range 219. not included for TF? Someone has manually reserved that range for factoring. I guess they are only factoring to 2^60 or 2^62. I'll eventually open that range up for factoring to the correct depth. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Version 22.13
I've uploaded a fix for an ECM bug. If you run ECM on a P4 you should upgrade to 22.13. All other users can continue to use 22.12. V22.13 is at ftp://mersenne.org/gimps/p95v2213.zip and ftp://mersenne.org/gimps/p95v2213.exe The ECM bug only occurred for exponents below 172,000 and near an FFT crossover point. It did not affect any Fermat factoring. Most Cunnningham factoring was unaffected because the FFT crossovers are at 743 and 1473. If you want to determine if some of your past ECM runs on a P4 were affected, then in v22.12 turn on round-off checking, and run an ECM curve on the exponent with B1=100. If the round-off error is 0.5 then your past ECM runs were affected by the bug. The good news is v22.13 does have a P-1 and ECM QA suite implemented. There is a pretty good chance that the last serious bug in this area of the program has been found. I've run a small QA file successfully. Over time the QA volunteers will undoubtedly improve the QA suite. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Has something gone wrong with the mersenne.org server?
At 01:22 PM 12/5/2002 +, Barry Stokes wrote: I tried to look at my personal stats today, and got this: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Could not load ADVAPI32.dll Has something gone wrong? Brad was trying out a new firewall at Entropia. Why it caused this problem both yesterday and today is unknown. A reboot fixed the problem for now. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: P-1 and non k-smooth factors
At 10:31 PM 12/3/2002 +, Daran wrote: For clarity, let's write mD as x, so that for a Suyama power E, the exponent (x^E - d^E) is thrown into the mix when either x-d or x+d is prime in [B1...B2], (and only once if both are prime). This works because (provide E is even) x^E - d^E = (x-d)*(x+d)*C where C is a sum of higher order terms. The benefit of prime-pairing arises when E=2. The cost of higher E is AFAICS linear in multiplications. The benefit of higher E comes from any additional factors thrown into the mix by C. This benefit is greatest if C has factors slightly B2 For E=4, C = (x^2 + d^2) For E=6, C = (x^4 + x^2d^2 + d^4) = (x^2 + xd + d^2)*(x^2 - xd + d^2) For E=8, C = (x^2 + d^2)*(x^4 + d^4) The analysis is more complex than this. It really depends on the prime factorization of these algebraic factors. If an algebraic factor's prime factorization contains factors all below B2, then the algebraic factor does you no good. Why not take your example: on an 8.1M exponent, B1=45000, B2=731250 and varying values for D and E, I get the following results D E Stage 2 transforms 420 2 93946 420 4 98618 (the default for my memory settings) and write a program that emulates stage 2's selection of (x^E - d^E), does a prime factorization of the value, and keeps track of which factors above B2 get included. It should be possible to calculate your increased chance of finding a factor (someone please fill in the formula here). Then you can run this on several D,E options and compare it to your count of FFT transforms and come up with the optimal choice of D and E. I'd be greatly interested in such a study. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: P-1 and non k-smooth factors
At 06:05 PM 11/27/2002 +, Daran wrote: if (D = 180) E = 2; else if (D = 420) E = 4; else if (D = 2310) E = 12; else if (D = 6930) E = 30; else E = 48; I understand why it chooses the values of D that it does, but why these values of E? I understand why E must be even, and that higher powers ought to be highly composite, but wouldn't 6 be a good intermediate value? 24? 60 for the top end? No good reason. As far as I know, there haven't been any studies on the best values to choose for E. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: New small exponents released ?
At 12:48 AM 11/25/2002 +0200, Nuutti Kuosa wrote: for triple checking ? Yes. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Poach?
At 01:30 PM 11/19/2002 +0100, [EMAIL PROTECTED] wrote: Last week this was a 1st test assignment, now it's a double check? Unfortunately there was a server sync in the meantime, so I can't check the cleared.txt. But I find in hrf3.txt: 11976787,berra,WV1 The berra test had errors and the exponent was re-released for first-time testing. I did this by manually setting the exponent's state. My guess is the database sync caused the server to once again notice it has a result for the exponent and now flags it as a double-check. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Request for help (especially ECM)
Many thanks to all the ECM curves with group orders that were sent to me over the last week. I should have enough to build a reasonable QA suite. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Bug in version 22.10
At 06:58 PM 11/8/2002 -0500, [EMAIL PROTECTED] wrote: The first of these is slightly larger than 2^65, so it was likely cheaper to find via p-1 than via sieving. But the second is only a tad larger than 2^63, i.e. under the hardware long int length, and thus sieving to 2^64 should have been quite fast. George - is it faster to do p-1 for numbers this size than to sieve to 2^64? This has been discussed on the list before. It is actually better to do the P-1 factoring before doing the last one or two bits of trial factoring. It is a small optimization, but maybe one day it could be implemented. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Here we go again.... v22.12 now available.
For the second time this week a P-1 bug has been found and fixed. Version 22.12 can be downloaded from http://www.mersenne.org/freesoft.htm The bug affects P-1 stage 2 in low memory situations. The bug has been present since version 20. From the whatsnew.txt file: A bug was fixed that caused some factors to be missed in stage 2 of P-1 when the available memory did not let the program allocate 12 temporary variables. If testing a number in the 16 millions using an FFT size of 768K, then each temporary takes 768K * 8 bytes or 6MB. If your memory setting was less than 72MB (6MB * 12 temporaries) then you were affected by the bug. Actual the program allocates some fixed tables so anything less than about 75MB triggered the bug. More details: If you are double-checking in the 8 millions, the bug would appear if you have less than 37MB or so allocated to prime95. This bug did not cause all factors to be missed, in fact it could cause some factors to be found that ordinarily would not be found. Specifically, in this low-memory situation prime95 steps through the range between B1 and B2 in multiples of 210. When processing a prime p, the code actually included the prime mirrored around the previous multiple of 210. For example, if 21+1 is prime, then 21-1 was improperly included. If 21+3 is prime, then 21-3 was included. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Request for help (especially ECM)
P-1 and ECM factoring is fairly complex code with several different paths based upon how much memory is available. I'd like to develop a fast QA suite for P-1 and ECM factoring. I intend to hardwire the test cases into prime95 (or read the data from a QA file) so that I can run them with several different memory settings without having to change local.ini memory settings. To make this test relatively fast I need one or two dozen fairly smooth P-1 test cases for exponents in the 1,000,000 to 10,000,000 range. This shouldn't be hard to compute. I can do it, but lets see if a volunteer would like to send me some in the next day or two. A harder problem is finding some smooth ECM curves to test. I do not have tools to compute group orders. If someone can help by finding a couple of dozen smooth ECM test cases for exponents between 1000 and 50, I would be most grateful. With your help this long overdue test suite can lead to version 22.13 and 22.14 next week! _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Bug in version 22.10
At 06:51 PM 11/5/2002 +, Daran wrote: Does this version only affect 22.10? Or versions before that? Only version 22.10 and only if the executable is dated after Sept 28. Sorry for the trouble, That's what beta testers are for. That's what was so ironic. After being in a relatively problem-free beta test period I finally called it official. Murphy's Law strikes again with a bug a few days later. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Bug in version 22.10
At 07:19 PM 11/5/2002 +, Brian J. Beesley wrote: One thing you might consider - when you change to v22.11, check out your results file. If you have a P-1 run logged on an exponent you haven't yet started LL/DC testing, make it run the P-1 again (change the ,1 at the end of the assignment line in worktodo.ini to ,0). I'd actually recommend not doing the P-1 again. If you are using enough memory to run both P-1 stages, then the bug did not affect stage 1 but did affect stage 2. If you run only stage 1 of P-1, then the bug would cause no factors to be found. In this case, you might consider re-running P-1 again as Brian suggests (but only if you used 22.10 dated after Sept 28). I did this on my own system have been rewarded with _two_ factors found - This is way above expectations! Nevertheless, I'm always happy to get the factors. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Bug in version 22.10
Hi all, Sigh If you downloaded a version 22.10 dated September 28 or later, then please upgrade to version 22.11 at http://www.mersenne.org/freesoft.htm The bug causes factors to be missed in the final stage of P-1 and ECM factoring. While this isn't the end of the world, it will cause you to run an unnecessary LL test. Sorry for the trouble, George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Torture test allocating hundreds of MB?
At 02:08 PM 10/28/2002 -0500, Nathan Russell wrote: However, when I tried to run a torture test to verify that everything was okay, I saw Prime95 suddenly allocate over 200 MB of memory for no apparent reason, and the computer began thrashing. Late version 22 executables use lots of memory to run the torture test. It uses the maximum of the daytime and nighttime memory values that you specified in Options/CPU. Since this causes thrashing, I'd reduce those values. If those values are already small then let me know as you've uncovered a bug. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Torture test allocating hundreds of MB?
At 09:34 PM 10/29/2002 -0500, Nathan Russell wrote: I had the memory usage set to the max allowable, because I wanted P-1 to succeed whenever possible, even if it inconvenienced me - I do most of my academic work via VNC into timeshares, so it isn't a big deal if the system thrashes. Is that the Wrong Thing (tm) to do in terms of improving Prime95's efficiency? Yes, thrashing reduces prime95's throughput. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
Hi, At 11:09 AM 10/22/2002 -0800, Gordon Bower wrote: It is running version 18, which was, of course, the latest version out at the time the machine was last under my control. It's beginning to experience difficult getting assignments below the the 20.x-million limit. Does anyone have any suggestions for how to stop a runaway copy of v18? Perhaps in a few weeks the server can be updated to return an out of exponents error to v18 instead of offering it an assignment it can't handle? You cannot stop a runaway v18 factoring client. It will get and discard assignments until it gets one below 20.5 million that is not factored to 2^64. Scott is supposed to be working on a server fix to give these v18 factoring clients a double-check assignment instead. Until Scott implements his fix, I periodically release these discarded exponents so that you don't have to. I've been watching about 5 machines. Email me your userid and machine name and I'll make sure your exponents get released too. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
At 07:03 PM 10/22/2002 -0700, Gary Edstrom wrote: Maybe future versions of Prime95 could have the capability of being shutdown from the server when the program does a regular check in. Actually, version 19 has that feature. Too bad its version 18 clients that are broken! _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: On v18 factoring
At 02:03 AM 10/23/2002 +, Russel Brooks wrote: How about a Black List of clients that the server will no longer give work to? I would think the problem of pcs no longer under your control would be an increasing problem. We want to give them double-checks so that the client isn't continually asking the server for work. This wastes bandwidth needlessly. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: version 22.10
Version 22.10 is the latest beta. If no problems are reported it will become the official release. You can download it at: Windows: ftp://mersenne.org/gimps/p95v2210.zip Linux: ftp://mersenne.org/gimps/mprime2210.tgz or: ftp://mersenne.org/gimps/sprime2210.tgz NT service: ftp://mersenne.org/gimps/winnt2210.zip It fixes several running-as-a-service problems (multi-processor systems, NT4, no admin privileges) Also, double-checking will now trial factor one-bit less than a first-time LL test. This is because finding a factor will save one LL test instead of two. P-1 factoring already took this into account. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: My numbers have been re-assigned to someone else...
At 10:44 AM 10/4/2002 +0100, Barry Stokes wrote: When I was checking my individual account page thing, I noticed that several of the numbers I was supposed to be factoring didn't appear in my list. I then checked the Hourly World Test Status, Assignments Report file, and found that the numbers I had have now been assigned to other people... Anyone got any ideas as to why this is happening? Oops, I blew it. I mentioned a few days ago that we are having trouble with version 18 factoring clients grabbing exponents and not processing them. Scott is working on a server fix. In the meantime, I've been locating these exponents and putting them back in the pool. Last night, I erred and freed up the wrong set of exponents (I reran a macro that was a few days old rather than running the new macro). There is no way for me to undo the damage I have done. Sorry. To avoid duplicate work, check your worktodo.ini file for assignments above 20,540,000. Then look at your individual account report. If the exponent appears in your worktodo.ini file and not in your individual account report, then delete it from your worktodo.ini file. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: ERROR 7: Server has run out of exponent to assign.
At 09:28 PM 9/30/2002 +, Russel Brooks wrote: I just got this error msg when my factoring machine uploaded results and tried to get more work. ERROR 7: Server has run of exponents to assign What now? More exponents are now available. There is a prime95/primenet bug that caused this. Version 18 factoring clients are accepting assignments and tossing them (v18 was designed to only go up to 20.something million). I'll work with Brad on a solution. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Order of TF and P-1
At 06:42 PM 9/12/2002 +, Brian J. Beesley wrote: I haven't checked the source from the latest version but the TF limits should surely be linked in some way to the LL/DC FFT run length crossovers. Many of these _have_ been lowered. Slightly, and especially for P4 systems. I have not changed the trial factoring limits in version 22. Actually, they haven't changed in years. I would have thought that, since (ignoring runs with errors - which is a reasonable first approximation) factoring before DC saves only one LL test, whereas factoring before first LL test saves two. So trial factoring (TF) depth for DC assignments should be one bit less than for LL assignments - This is actually a very reasonable and easy to implement idea. It doesn't fix all our problems, but it makes things a little bit better. Optimal trial factoring depth vs. P-1 vs. LL varies from machine to machine. To further complicate matters, the factoring, first LL test and second LL test is very likely to be done on different hardware. In essence, I've just given up on analyzing and implementing any improved solution. The good news is that implementing the absolutely optimal solution - whatever that is - would improve GIMPS throughput a very, very tiny amount. The original point of this thread, that P-1 should be run before running the last one or two bits of trial factoring is true. Unfortunately, it cannot be implemented without server changes. If we ever make P-1 a separate work type (also desirable), that would be the time to implement this. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: More error info
Trying again Our intrepid researcher broke down the non-clean run stats below. So if you get a single error, you've got a 2/3 chance of being OK. Two or more errors and your chances are not good. This is not broken down by error type (SUM(INPUTS) != SUM(OUTPUTS) vs. ROUNDOFF 0.4) Number of errors reported badgood error_rate 1 314 625 33.4% 2 192 135 58.7% 3 107 63 62.9% 4 74 36 67.3% 5 53 17 75.7% 6 48 20 70.6% 7 31 7 81.6% 8 30 10 75.0% 9 17 10 63.0% 1025 2 92.6% 10 37558 86.6% _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Error rates
A user has broken down the GIMPS error rate for exponents between 2 million and 7 million. See ftp://mersenne.org/gimps/err_rate.xls. I'd ignore the data from 6 million to 7 million as there are many triple-checks to be done. The data from 5 million to 6 million will not change much at all. The data from 2 million to 5 million is accurate. There is a lot of interesting data in this spreadsheet. Our overall error rate is roughly 3.5%. If you have an error-free run, the error rate is in the 1.4% to 2% area. If you have an SUM(INPUTS) != SUM(OUTPUTS) error or ROUNDOFF 0.40 error that is not caused by an approaching FFT crossover, then there is a 56% chance that your LL test will be no good! _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: 22.8.1 has increased iteration time
At 06:30 AM 8/29/2002 -0700, Gary Edstrom wrote: I have noticed a small but definite increase in the iteration time of version 22.8.1 as opposed to 21.4. It is possible that version 22.8 and 21.4 are using different FFT sizes. Version 22 is more conservative in selecting which FFT size to use. If I knew the exponent, I could tell you if this is the cause I am continuing processing on the very same exponent using the new version. Is this allowed? Yes. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Unable to communicate with server.
At 11:04 PM 8/28/2002 -0700, Andy Kohler wrote: Where can we download version 22.8? The webpage at http://www.mersenne.org/freesoft.htm shows only version 21.4, from 22 Sep 2001 (for Windows). Thanks --Andy The freesoft.htm page now has a link to version 22. I've hastily added it thanks to this error 29 mess. Not surprisingly, my email load has gone up with all the version 21 Windows clients raising an error. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: SV: Mersenne: Unable to communicate with server.
At 10:59 PM 8/29/2002 +0200, Torben Schlüntz wrote: What is going on? Yes, it is true I get this error message 29. Do I have to update to 22.8 when I'm mostly do trial factoring? I've contacted Brad at Entropia to figure out what is different with the server. It is my intention to get it working with version 21 again. This is not some sinister ploy to force users to upgrade to version 22! _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Mime-Version: 1.0
Version 21 seems to be back online. The problem was with the GIMPS proxy at Entropia.com. This proxy routes version 21 contacts from entropia.com to mersenne.org. Version 22 contacts mersenne.org directly. Sorry for all the difficulties! _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Unable to communicate with server.
At 09:05 AM 8/28/2002 -0700, Bob Margulies wrote: For the past several hours, while trying to get exponents from the server, I have been getting: PRIME95 caused an exception 6baH in module RPCRT4.DLL at 0187:7fb953e3, followed by a shutdown. Is there a way for me to keep running 21.4.1 while this is resolved? Make sure prime.ini contains the line UseHTTP=1. The server has been up for the last few hours, so you shouldn't be having troubles. If you still are we may need to upgrade to version 22.8 and turn on the new communication debugging option. Email me privately if we need to do this. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Question about PrimeNet Individual Account Reports
At 08:37 AM 8/25/2002 -0700, Gary Edstrom wrote: In looking at my PrimeNet individual account report, I read the following sections: Unspecified type : 1 my desktop is a 2.2GHz Pentium IV and is checked as such in Options / CPU. Am I doing something wrong, or is this normal? This is a known bug in the individual account reports. P4s are reported as unspecified type. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: access to primenet server
Hi, At 10:37 AM 8/24/2002 +0100, Gareth Randall wrote: Any chance of implementing some sort of status output to say I got to here...? Something like this: [time] PID etc DNS resolved server #think this is actually just an IP [time] PID etc Open connection to proxy [time] PID etc Connection to proxy made [time] PID etc Asked to connect to primenet server [time] PID etc Got connected to primenet server [time] PID etc Sent the data or request # you know what I mean [time] PID etc Got the expected response [time] PID etc Saved the updated state to disk # catch filesys errors [time] PID etc Closed connection to proxy Whichever is the last entry in the log is the next stage at which you should be looking at. Ideally a competent user can see immediately where it got stuck. The closest thing to this is setting Debug=1 in primenet.ini (version 22 only). It is a bit more verbose than this and the output is a little more cryptic. This sort of error tracking is particularly relevant to me at the moment, because I have recently been involved in supporting Windows apps, and no-one has designed anything to narrow down problems. I can sympathize with your plight. Administration is often a thankless job. Error messages are useless and say nothing more than er, it didn't work, and no clue is given as to which part of the procedure failed. Guilty as charged. On the subject, all programmers should try to avoid giving their error messages in little pop-ups that can't be cut and pasted. Don't just follow the crowd. Make your error messages appear in text boxes which don't require people to manually retype them. :-) But this is the Microsoft standard! The right answer is for MS to change the way windows works - to allow copying text from message boxes. Best regards, George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Status
At 07:30 AM 8/19/2002 +0100, Daran wrote: So how come I've just been given this assignment: Test=9620617,64,1 The first test of this number had 5 roundoff 0.40 errors. Since the result is highly suspect, it was re-released as a first time test. Consider yourself lucky to get such a small exponent - faster runtime and better chance of yielding a Mersenne prime than the first time tests in the 16 millions. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Question about setting available memory
At 07:16 AM 8/17/2002 -0700, Gary Edstrom wrote: It is my understanding from reading the documentation that setting the available memory only affects the P-1 factoring stage and not the main LL test. Is this correct? Yes. The reason I am asking is because of a great difference that I have noticed in the iteration time of the LL test on my 2.2GHz desktop and my 1.0GHz laptop while running comparable sized numbers on both machines. I would expect to see the laptop taking a little more than double the iteration time of the desktop. Instead, I am seeing a 5x difference. The P4 2.2GHz machine uses the SSE2 instructions for a big speed up. See the http://www.mersenne.org/bench.htm for timings from a wide variety of machines _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: dual-P4 xeon/win2k/prime95 / Re: Mersenne: GIMPS forums!
At 08:16 PM 8/15/2002 -0400, Steve Elias wrote: thanks for the new forums, George. (fora?) Thank Xyzzy, he did all the work. All I did was make the first post and announce it to the mailing list. at work lately i've been trying to set up a dual-P4 win2k system with prime95. but when it boots only one of the prime95 starts up when i log in. both are set for start at bootup each with cpu-affinity hard-coded. I'm guessing you've installed prime95 twice in two different directories. If so, what is happening is both are trying to use the service name Prime95 Service and overwriting each other. Try turning off Start at Bootup on both. Edit one of the local.ini files and add ServiceName=Prime95 Service #2. Turn on Start at bootup on both. If you run the second prime95 from the same directory with the -A1 command line argument, then you shouldn't have this trouble. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Latest version p95v21.exe ??
At 08:11 PM 8/13/2002 -0700, Anurag Garg wrote: Is it possible to find out what the FFT crossovers for x87 CPUs are with the latest version? Yes and no. This table shows FFT size, v21 x87 crossover, v22.8 x87 crossover, v21 SSE2 crossover, v22.8 SSE2 crossover. As you can see v22 is more liberal with x87 crossovers and more conservative with SSE2 crossovers. 262144 5255000 5255000 5185000 5158000 327680 652 6545000 6465000 6421000 393216 776 7779000 769 7651000 458752 904 9071000 897 8908000 524288 1033103810241018 655360 1283128912721265 786432 1530153415161507 917504 1785178917661755 1048576 2040204620182005 1310720 2535253925092493 1572864 3015301929922969 1835008 3510352034863456 2097152 4025403039783950 2621440 5000500249354910 3145728 5940595158925852 3670016 6910693668656813 4194304 7930793078367791 Now the gotcha. In v22.8, FFT crossovers are flexible. If you test an exponent within 0.2% of a crossover point, then 1000 sample iterations are performed using the smaller FFT size and the average roundoff error calculated. If the average is less than 0.241 for a 256K FFT or 0.243 for a 4M FFT, then the smaller FFT size is used. Brian Beesley has been a great help in investigating revised crossover points and analyzing the distribution of round off errors. We noticed that consecutive exponents can have a pretty big difference in average roundoff error (e.g. one exponent could be 0.236 and the next 0.247). This is why I elected to try the flexible approach described above. The 0.241 to 0.243 average was chosen hoping for about 1 iteration in a million generating a roundoff error above 0.4. We might change the 0.241 to 0.243 constants with more data - it is hard to get enough data points to accurately measure 1 in a million occurrences. One downside is the server does not know which FFT size is used and will credit you based on the v21 x87 crossovers. Thus, if you are a lucky person, you might get bonus CPU credit where you test the exponent at a smaller FFT size and the server credits you based on the larger FFT's timing. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Latest version p95v21.exe ??
At 06:35 PM 8/14/2002 -0400, Nick Glover wrote: I'm curious, where does the roundoff checking every iteration come in? This explains how the program chooses the FFT size, but what are the conditions for when roundoff checking for every iteration is used? Based on my understanding, it seems to me that if the soft crossover calculation determines that an exponent can't be run at the smaller FFT size, then maybe it should just do the exponent at that FFT size with roundoff checking every iteration instead of moving to a larger FFT size. Does the program currently do this? If prime95 decides to use the smaller FFT size (the thousand iterations average error was below the 0.241 to 0.243 threshold), then the LL test uses the smaller FFT size with error checking every iteration. This will protect you from roundoff errors up to 0.6. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Latest version p95v21.exe ??
At 10:41 PM 8/13/2002 +, Russel Brooks wrote: I'm adding a new pc running GIMPS and went to the web site where p95v21 was available. Isn't this version a bit downlevel? Try version 22.8 at ftp://mersenne.org/gimps/p95v228.zip. This is the last version 22 beta. If all goes well it will be the official release in a few weeks. Let me know if you have problems. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Double Checking Errors
At 07:28 PM 8/9/2002 -0700, Gary Edstrom wrote: That brings to mind another question. I was wondering what you do when you detect an error during double checking. Do you notify the person that sent in the erroneous result so that he can check out his computer further? No, for several reasons. 1) We don't know your double-check is wrong until a triple (or even quadruple) check is run. Thus, it could be a few months before we'd email you. 2) If a first time check is bad, it will be two or three years before the double check and triple check come in to confirm this. 3) It would be a fair amount of work for me. Right now the server does not verify double-checks. That is done by me, with the aid of a program, at home. Matching bad results with email addresses, sending the email, and wading through bounced emails is not something I would relish! Is there interest in adding a new file to ones you can download at the bottom of http://www.mersenne.org/status.htm? It could contain all the confirmed bad results (I have kept this data). This would make it easier for you folks to check and see if you have any problem computers. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V22.7C Warning
At 08:01 PM 7/30/2002 -0700, Terry S. Arnold wrote: I am running 22.5.2 on some P4 boxes and 21.4 on a mix of P III and P II boxes. What is the best version for each of these box types? You are in good shape. P4s should be running version 22.5 or later. Non-SSE2 machines only need to run version 22 if they want to take advantage of some of the minor fixes and enhancements now available. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: V22.7C Warning
To those that like to snoop in the ftp://mersenne.org/gimps FTP directory, DO NOT download p95v227c.zip. It contains some test code for the new P4 based Celeron chip with a 128KB cache. If you run this version on normal P4's it will run SLOWER than the regular version 22.7. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: W2K service installation problems
At 10:46 AM 7/29/2002 -0700, Aaron wrote: I suppose it's probably documented somewhere, but it seems that Prime95 ignores any service name settings in the existing NTPrime local.ini file... So I'm still using NTPrime on my dual CPU machines... Any chance of getting prime95 to honor the service name settings in the local.ini file just like ntprime did? Already coded and tested. Look for the fix next time I upload a new prime95 _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: P4 xeon listed as 'unspecified type'
At 07:43 PM 7/25/2002 -0700, Daniel Swanson wrote: when using p95v227.zip on a dual P4 Xeon, primenet lists this as 'unspecified type'. This is normal ? I have a similar problem. I have 3 P4 1.8 GHz machines running p95 v22.5.1. All 3 appear in my Account Report as 'Unspecified type'. This is a bug/deficiency of the primenet server reports. On the http://www.mersenne.org/primenet/status.shtml web page it is properly reported as a P4, but on your individual report it is listed as unspecified. No need to worry about it though. As long as the client knows its a P4 you will get the right work types and run the P4 optimized code. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: last synchronization
At 05:04 PM 7/26/2002 -0400, David A. Bayer wrote: I've noticed this exponent listed for the last 10 or so months on my list. After the synchronization a few days ago, it still showed up. Any idea why it is not clearing? 9724961 65 0xAB16847CD1B7CA__20-Nov-00 07:37 There are many problems with merging. Known problems exist for exponents above 2^24 and first time tests below 10,000,000. I do have your result, so if not too much trouble, just ignore the offending exponent. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Roundoff errors
At 06:49 PM 7/23/2002 -0400, [EMAIL PROTECTED] wrote: The M12898349 error may be OK as it may have been very close to the limit of the 640K FFT (I don't recall the 22.3 crossover points). According the the GIMPS status page, the 640K crossover point for the more-accurate x86 client (i.e. the non- SSE2 code) is 12.83M, Thanks to Brian's research we've revisited all the x87 crossovers. Some v22 executables had a 12.90M crossover. This has been lowered to 12.89M in v22.7. Except that P-1 stage 1 (unless I'm mistaken about Prime95's particular implementation thereof) uses the same FFT-based squaring code that the LL test does. it seems curious that Daran mentions seeing the roundoff warnings in p-1 stage 1, and not in the subsequent LL tests of these exponents. George, is error checking done more frequently in p-1 than in LL? Daran mentioned that he was only doing P-1 factoring, leaving the LL test for others. The P-1 factoring code does error checking just as often as the LL code. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Error message from prime95 on an old Win95 box
At 09:34 PM 7/16/2002 -0400, A T Schrum wrote: I didn't find a reference to this problem. My old PentiumMMX 200 Mhz box running Win95 OSR2 (with tons of patches) now has Prime95 2.26.1 on it and it runs reasonably faster (about 20ms faster at 768K FFT size). But upon startup, Prime95 reports Can't write registry value and continues on. Should I be concerned? I doubt it. Prime95 should be trying to create a registry entry to run the program at bootup. If you uncheck the Options/Start at Bootup menu item the problem should go away. I'm curious though. Do other Win95 users have the same trouble? _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Error message from prime95 on an old Win95 box
At 06:01 PM 7/17/2002 -0400, A T Schrum wrote: No go. The box was unchecked. I checked it, restarted Prime95, and the error message was not there. So I unchecked it, restarted Prime95, and the error message came back. I reactivated an old Win98 box for debugging. You are correct. The error message is harmless. I've got a fix ready for download at ftp://mersenne.org/p95v227.zip The only new feature a v22.7 is SSE2 based trial factoring for factors above 2^64. It is about 4 times faster than v22.6. Since most P4 users are getting assigned prefactored exponents, the speedup is of no value. However, if you are working on 10 million digit numbers, you may get assigned a number that needs factoring and the new code will certainly help. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Firedaemon question
At 11:53 AM 7/13/2002 -0400, Martin Felker wrote: This question might be more properly addressed to the Firedaemon people but I though someone here might know the answer really quick. I am running prime95.exe using Firedaemon RC1 for Windows XP. For whatever reason, even though I configured the XML file to indicate that prime95 is a console application, I can't bring up the console to see how I'm doing or even what process I'm running. Any suggestions?? Try version 22.6 at ftp://mersenne.org/p95v226.zip. The Start at bootup option should install prime95 as an NT service without using firedaemon. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Extrange assignament
At 02:00 AM 7/11/2002 +0200, Ignacio Larrosa Cañestro wrote: Yesterday, Primenete did assigned to one of the computers that I manage, a exponent in the 8 million rank, for first test, not for doublecheck. But in the Status page, this rank is complete for first test ... How is it possible? The factorization level is 1, if it help ... The server is having problems with exponents in the 8-10 million range. For reasons unknown it seems to have forgotten how far these exponents have been factored. I'll restore this info as I make these exponents available for double-checking. As to why you got a first test, I can think of two possibilities: 1) The server was confused. 2) Several months ago I made dozens of these small exponents available as first-time tests because the first test had errors. Maybe one of these timed out and was assigned to you. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: P-1 limits
At 12:27 AM 7/11/2002 +0100, Daran wrote: P-1 factoring with 459MB available memory, the program chose the following limits for these two exponants. 7786567B1=4, B2=64 7714127B1=4, B2=65 Why did the smaller exponant get the higher B2 limit? The short answer is I don't know. I invite someone to figure it out. Look for the last routine in commonc.c called guess_pminus1_bounds. First off, when dealing with P-1 success vs. cost analysis, the difference between 64 and 65 is negligible. Possible reasons for your case: 1) The code uses inexact interpolation and numerical integration to compute Dickman's function. 2) The GCD cost for the larger exponent is higher. This should be more than offset by the cost of the extra 72440 doublechecking LL iterations. 3) There are more trial factors with the smaller exponent in a given range because factors are 1 mod 2p. The costing routine sums up the chances of finding 65 bit, 66 bit, 67 bit, etc. factors. This should be offset by the higher exponent having a better chance of finding a smooth factor (found factors are 2kp+1 where k is smooth - larger p means smaller k which means a higher chance of success). Of course, the other possibility is a nasty bug in prime95. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Version 22 update
At 12:35 PM 6/20/2002 -0400, Nick Glover wrote: Also, I tried to fix the OLEACC.DLL problem in Win95. This version should load the DLL only if needed. Can the user that had that problem test this fix? Yeah, that fix works. However, I had this new problem on my Win95 machine when I tried to run it: The Prime95.exe file is linked to missing export Advapi32.dll:SetEntriesInAclA. I've tried the same trick of delaying the loading of this DLL. Can you try today's version of 22.5 using the old advapi32.dll? I added code in 22.5 to fix the XP bug where prime95 was not detecting prime95 being run by another user. This fix is causing your new problem. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: ERROR: ROUND OFF
At 10:20 PM 6/15/2002 +0200, Guido Lorenzini wrote: Recentely Laura, one of my PCs started testing some Exponents close to the 768K FFT size boundary (i.e. M15143XXX etc.). As you may see from the 1st line of this file, the problems started just with these border line exponents. Are these results correct or am I returning useless data to the g.i.m.p.s.? Your Pentium 4 does not have any hardware problems. Your result is likely OK as all your errors were below 0.5. Your result would only be incorrect if you had a 0.5625 error (prime95 will see that as a 0.4375 error). Here's what you need to do. Get version 22 from ftp://mersenne.org/gimps/p95v22.zip The FFT crossovers have been made more conservative (precisely because of your problem). _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Re: Mersenne: Slow Pentium 4 question - status report
Hi, At 04:56 PM 6/13/2002 -0700, Bockhorst, Roland P HQISEC wrote: WCPUID recognizes my P4 and its having SSE and SSE2 instructions. WCPUID uses the CPUID instruction to determine if SSE and SSE2 is supported. Prime95V22.3 doesn't. Prime95 uses the CPUID instruction but also tries to execute an SSE and SSE2 instruction. If an exception occurs, it is trapped and the CPU is flagged as not supporting the instruction. My next step is to upgrade to Windows98 I know that when I did my first tests of the memory prefetch on my Win95 Celeron II machine, prime95 would not work. Upgrading to Win98 fixed the problem. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Slow Pentium 4 question
At 04:53 PM 6/12/2002 -0700, Bockhorst, Roland P HQISEC wrote: I think my P4 is running like a P III, at one third speed doing Mersenne Prime testing. When I run Prime95v22 it reports my P4 as CPU features: RDTSC, CMOV, PREFETCH, MMX I'm pretty sure that Windows 95 does not support SSE and SSE2 (because the OS does not save the XMM registers on a task swap?) Get yourself Windows 98 - someone probably has an old copy lying around you can get free or cheap. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: time per iteration
At 12:43 PM 5/26/2002 -0400, Jud McCranie wrote: I've been off the mailing list for a while. I just went from ver 21.4 to 22.3 and the calculation of time per iteration seems to be off. I'm running a 15,000,000 exponent on a 1.3 GHz Athlon. It shows (what would be) a remarkable 0.037 sec per iteration, but it takes about 13 minutes for 6000 iterations, which is actually 0.13 sec/iter, 3.5 times as much. The expected completion dates under Status look right. Is there a bug in the per iteration calculation in ver 22.3? Sure looks like a bug. One of the changes in version 22 is the use of the Windows QueryPerformanceCounter system call rather than RDTSC to time each iteration. Another change is that prime95 automatically deduces your CPU speed and type. Please email me your prime.ini and local.ini files and the output of the Options/CPU dialog box (hint - you can do Options/Benchmark and the cpu information will be written to results.txt). I'm also interested in hearing from any other users that find version 22.3 is not detecting their CPU type and speed properly. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: error result
Hi all, At 08:41 PM 5/24/2002 +0200, Dieter Schmitt wrote: stage 1 GCD complete ERROR: factor doesn't divide N! contacting server etc. The help file says this bug was fixed with version 20.5 concerning P-1 or ECM. Well another bug was fixed in 22.3. You either had a hardware glitch or ran across a rare GCD bug. Your diagnosis was correct. GCD returned a factor, but when prime95 tried verifying it the factor did not divide the Mersenne number. All in all, don't worry about it. The bug is rare enough that upgrading is not terribly important. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Version 21 and P4 problem
Hi all, A user testing exponent 15145xxx on a P4 recently got a reproducible round off error of 0.5. As we all know that error ruins the LL result. Consequently, I've changed the FFT crossover point in version 22 from 15,160,000 down to 15,140,000 on the P4. In addition, the above uncovered a bug whereby a reproducible roundoff error greater than 0.48 would cause an infinite loop - backing up to the previous save file in hopes that the roundoff error will eventually become less than 0.48. To eliminate the problem in the future, version 22 will do round off error checking every iteration for exponents within 2% of the maximum exponent that can be tested by the current FFT length. The current version only does roundoff error checking every 128 iterations. If a reproducible roundoff error is greater than 0.45, then we restore the previous save file and shift the data one bit - this should change the FFT data so that a more acceptable roundoff is generated. What should you do if you are running version 21 on a P4? You can do one of the following: 1) Nothing. You are unlikely to run into trouble. Just keep an eye on your results.txt looking for an unending string of roundoff errors on the same iteration. 2) Turn on Advanced/Round Off Checking. This will error check every iteration instead of every 128 iterations. Again keep an eye on results.txt for unending error messages. Roundoff checking on the P4 is very fast. 3) Upgrade to version 22 (only the Windows version has the above fix). It isn't fully tested but should be safe. The only dangerous change I've made is compiling with maximum optimization to speed up the GCD code. Sorry for the trouble, George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Database merge
Hello all, Brad at Entropia has just done a database merge in another attempt to get rid of the exponents below 4,000,000 that have mysteriously appeared in the cleared exponents and active assignments reports. It looks like we may not have succeeded :( Just thought you folks might be curious as to why a merge took place just a week or two after the last one. -- George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Which changes have been made to the server
At 11:28 AM 4/2/2002 +0200, Henk Stokhorst wrote: Does this signify some results have been judged invalid and need retesting? 5059 7 808945 1 100 109 2 110 11911 3 120 12912 210 219 1 No, our old results are OK. I'm guessing someone has created a worktodo.ini file containing small exponents in order to do some QA (or they don't know what they are doing). This work was communicated to the server and is appearing in the reports. I'll investigate further. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: Which changes have been made to the server
Hi, At 11:07 AM 4/2/2002 -0800, Mary K. Conner wrote: Looking at the status report right after the synch, I could see that a very few results from between 7.7M and 9.9M or above 16.8M were removed, and most were left behind. Correct. This is an artifact of our kludgy merge program written several years ago. I manufacture a binary file containing all exponents up to 10,000,000 that need double checking and all exponents up to 2^24 that need testing or factoring. There are two shortcomings in the merge program: 1) If an exponent is in the binary database marked for double-checking, then the previous LL result is not cleared out. 2) If the exponent is above 2^24, the previous result is not cleared out. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Fwd: Predicting Mersenne Primes
I'll forward your attempted post. I don't remember Eric's prediction, but if true it is quite insightful (or lucky). From: Dale Horn [EMAIL PROTECTED] Subject: Predicting Mersenne Primes I tried to post this on the Mersenne mailing list at [EMAIL PROTECTED], but it never showed up. I was wondering if is was possible to predict where a Mersenne Prime will be? I ask because I was looking at the mersenne.org website and noticed that it states that on December 6, 2001, the 39th known Mersenne Prime was found. It was listed as 2^13466917-1. I was also looking through some of the past digests from the list and noticed that an Eric Hahn posted a message on July 30, 2000, stating that one of the ranges a Mersenne Prime should be found was between 2^13430227-1 and 2^13501387. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Missing assignment
At 12:32 PM 2/17/2002 +0100, Kevin Dorekens wrote: I'm one of the victims of these hacker attacks and I've decided to continue for double-checking purposes. Now I do have a question though. Will my work time still be credited in my account report? I don't think so. However, just email me with the exponent you completed and your userid and I will be happy to give you the CPU credit manually. Even if I edit worktodo.ini to tell the program that it's a double-checking assignment now the server still returns ERROR 11: Exponent already tested. I don't understand why it does this. Double-checking assignments have always been tested already, right? Yes, but I have to explicitly tell the server which exponents are available for double-checking. Currently, I've only released exponents below 8,000,000 for double-checking. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Trial Factoring: Back to the math
At 05:18 PM 2/16/2002 +, [EMAIL PROTECTED] wrote:
So the viability of the new algorithm depends on whether we can
compute P*F (mod 2^p-1) faster than we can compute 2^p (mod F).
To put it in perspective, let's say you are looking for 64 bit factors
of a 10,000,000 bit number.
The basic algorithm is:
Multiply 156,250 trial factors together to form a 10,000,000 bit
number.
do {
Multiply next 156,250 trial factors making 2nd 10M bit number.
Multiply the two 10,000,000 bit numbers together mod 2^P-1
} while there are more 64-bit factors
GCD (10,000,000 bit product, 2^P-1)
Looking at the inner loop the second step uses the fast LL multiply code.
On my P4-1400 this takes 0.06 seconds or 84 million clocks or (dividing
by 156,250) 538 clocks per trial factor. This is quite promising. I haven't
measured it but the current code can test one trial factor in about 4000
clocks.
The stumbling block is how can we quickly do the first step of the inner
loop - multiplying 156,250 bit trial factors together. If someone has a
clever algorithm that can do this in fewer than 3500 clocks per trial factor
then we may have an improved factoring algorithm!
_
Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Are problems more likely in the last 1% of a 10 gigadigit LL?
Hi, At 09:44 PM 2/12/2002 -0800, Gerry Snyder wrote: I was seeing a bunch of suminputs != sumoutputs, and after rebooting, the errors switched to round off [4] 0.40 Was I just unlucky about timing, with only about 0.3% left? Dang. That is unlucky. Looks like a hardware problem. Is the CPU overheating? Get motherboard monitor or similar program to find out. Did a fan go bad? Did airflow in the cabinet get reduced considerably? Did a memory chip go bad? Did the power supply go bad (insufficient voltages can cause this)? Or did my stupid PC just decide to take now to blow it? As far as I know, the previous part of the LL was trouble-free. W98, Prime95 V2 21.2.1. 1.3 GHz P4, 384 MB RAM Or You could have tripped over a bug in v21.2. This was a beta version of prime95 and whatsnew.txt for 21.3 states: A bug was fixed in the error recovery code. After getting a Disregard last error message, the user was treated to a new error on every iteration. The end result was incorrect. The bug only affected the error recovery of the new P4 FFT introduced in the beta version 21.2. I'm pretty sure I notified this list about the problem urging P4 users to upgrade to v21.3. I am bummed. I would be too. I hope you have a recent backup of the save file before this mess started. Thanks for advice or condolences. Condolences. Upgrade to v21.5. If you have a backup of the save file restore it. Run a torture test for several hours. Then resume the computation using the restored save file. ***NOTE: There is an important lesson to be learned here. All testers of 10M digit numbers should backup their save files regularly!! You don't want a hardware glitch, disk crash, etc. cause you to loose months of work. Sorry, George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Factoring top 10
Hi, At 11:41 AM 2/12/2002 -0800, Aaron Blosser wrote: PS - I'm just thrilled because I found a factor of an exponent that beat my previous record... 101 bit factor. I'm too lazy to look through the cleared exponents list, so does anyone know what the largest factor is that has been found by GIMPS lately? The top 10 - 39 digits for the biggest! 1433462339 56379662829467477289264041716715663 1318781335 63113922700063643342764849026462401 1075012734 4777866348588447235992766781311399 1293216734 4314676575733979321708362055504719 1050634734 2529967840093210987185485731119337 1345961334 2004522251312746653413939484232703 1454281734 1001733277749555116882783777187313 1234882933 972299186932443166370257195895087 1437882733 749393632720558083108841526201431 1311127132 35439060242916356936579100907769 _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Factoring bits
Hi, At 09:18 PM 2/12/2002 +0100, Achim Passauer wrote: And for all other readers all(?) factors with more than 99 bits which are part of the latest cleared exponents report: 14308961 103 F 9394020965332917865679071542783 There are two minor shortcoming in the prime95 to primenet protocol. It reports the first 32 digits of a found factor. Thus, the report will never display more than 103 bits as the length of the found factor. Also if P-1 finds a composite factor prime95 reports this as one gigantic factor rather than two smaller factors. Naturally, this is all cleared up when it is entered into the master database. Its just that the primenet server reports can be a little misleading. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Russian anyone?
Hey, Are there any readers that can help a Russian user install prime95 on a computer? If so, let me know and I'll forward your email address to the user. Thanks, George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Prime freezing when connecting by DSL to Primenet
Hey all, At 01:52 AM 1/12/2002 -0500, Michael Vang wrote: We have been experiencing a similar problem for about 2-3 months... Our belief is that the error is on the server end... I can sometimes duplicate the error by sending large amounts of traffic to PrimeNet... For those experiencing this trouble try ftp://mersenne.org/gimps/p95v22.zip I've fixed a bug in the communication code - the error would have been quite rare. If v21 is working OK, continue using it. The new code uses modified Linux sockets code rather than the old HTTPNET.DLL. If you try this version and still experience troubles, then set Debug=1 in the primenet.ini file and send me an annotated prime.log file telling me what happened. Also, let me know if any other problem occurs! BTW, RPC support is now gone. Thanks, George P.S. If this works, I'll port it to Linux soon. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factors
Hi, At 11:59 PM 1/15/2002 +0100, =?utf-8?Q?Torben_Schl=C3=BCntz?= wrote: I have downloaded the factor files suggested by GIMPS but it gives no meaning. How do I read the files *.cmp? From the status.htm web page: You will need a special program to decompress the known factors data The special program is: ftp://mersenne.org/gimps/decomp.zip I am also a bit annoyed about numbers less than M751 that should be fully factorized seems unavaible, or am I looking the wrong places? Do you know a site which I don't? Go to the Cunningham project at: http://www.cerias.purdue.edu/homes/ssw/cun/index.html The next step for GIMPS is a faster factoring algorithm and the way to get that will be that someone - maybe a mathematician or some beer-drinking fool like me - finds the stones of immortality. :-) Good luck finding this algorithm. Many advances have been made the last two decades. We eagerly await the next one! Besides I have the question: why does the advanced facor algortithm of prime95 somtimes find 2 factors? This happens eg. at M1289, has 108817410937 and 15856636079 as factors? I don't remember. That code is no longer supported. Best regards, George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Optimizing P4 usage
Hi, At 09:37 PM 1/13/2002 -0800, Gerry Snyder wrote: At home I have 2 PC's, My question is whether it is worth the trouble to shift the trial and P-1 factoring of the next one to one of the P3 processors You only need to do the trial factoring on the P3. P-1 testing on the P4 also uses the SSE2 instructions. As to whether this is worth the trouble, only you can answer that question! -- George _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: P4 throttling
At 06:55 PM 12/22/2001 -0500, Paradox wrote: I get approximately 0.180 seconds/iteration. According to the benchmark on mersenne.org, I should be getting closer to 0.143 seconds/iteration. Try stopping prime95 and let the CPU cool. Then run Advanced / Benchmark. Hopefully you will get timings before the CPU heats up and thermal throttling kicks in. If your timings match the benchmark page, then your machine is capable of achieving the timings others are seeing. If that is the case, then there are two possibilities. The timing you see running an LL test is an average time vs. the benchmark which shows best time. Either some OS setting or installed software is causing cycles to be wasted, or thermal throttling is kicking in. I do not know how to isolate the problem. As an aside, you would be the first to report thermal throttling so maybe your heatsink isn't installed properly or a case fan is dead or some cables are interfering with the airflow. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Database merge
Hi all, Brad at Entropia did a long awaited database merge last night. Thanks, Brad. Due to an oversight in my scripts, the compressed binary database that Brad merges in only had data for exponents below 16 million. Thus, all factoring and LL results on exponents above 16 million were not cleared out. We will get them next time. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: Database merge
At 08:09 AM 12/12/2001 -0800, Aaron Blosser wrote: Just out of curiosity though, I'm wondering why some of my cleared exponents are still there... like these ones: 8664941 65 0x87838CA31D64B5__ 16-Jun-00 07:44 WorkerBoy2 9885119 65 0x86BA14ED5C3785__ 25-Dec-00 13:45 NYFS-1 Merging is a messy inexact little-tested science. The binary database has a list of all exponents below 10,000,000 that need double-checking. Thus, these exponents were not removed from the server (and the old LL result is still visible even though we should have cleared it). _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Why is the default page...
At 06:35 PM 12/9/2001 +, Daran wrote: ... of the GIMPS website http://www.mersenne.org/ a list of other distributed computing projects? By all means link to and support these projects, but wouldn't prime.htm be a more sensible starting point? I've fixed it. Let me know if any links are now broken. Thanks _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
