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: End of list
At 11:30 AM 4/22/2004 -0700, Gordon Irlam wrote: FYI. I intend to end this list shortly. Thank you, Gordon. Your efforts have been greatly appreciated over the years! _ 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
Re: Mersenne: Single or Dual channel memory for P4
At 07:33 PM 12/26/2003 +, Brian J. Beesley wrote: I'd expect that going dual channel would give a very significant improvement in speed _for mprime/prime95_ probably around 25%. Ask for advice at www.mersenneforum.org. I think I've read that dual channel gives you around a 5% boost. _ 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
Mersenne: 40th Mersenne Prime found
As you may already know, a user has reported discovering the 40th known Mersenne prime! In the wake of the false prime report a few months ago, we added a few failsafes to quickly detect a false report. Fortunately, this user was using the new version of prime95. He emailed me the save file with 2000 iterations remaining. I reran those final iterations and my computer also reports this number prime - in my mind eliminating any chance of a hardware error. Unfortunately, we still must go through the official different machine, different program verification which will probably end in early December. So please be patient awaiting the disclosure of the number. Waiting for verification saved us from a huge embarrassment last time! Oh yes, hints. I've always given hints. The prime number is more than five million digits and less than ten million digits. Congratulations to all!! GIMPS has done it again! _ 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.4
At 09:55 AM 8/31/2003 -0400, Marcel van de Vusse wrote: > More improvements for P4 owners! You can expect up to 9% faster iteration > times compared to version 23.3! All users doing ECM should also upgrade to > 23.4. This message was from May. The web page still lists version 23 as being beta. Does anybody have any idea when the final release of version 23 will be? I think 23.6 will be the last of the version 23s. I had hoped to make a few more performance improvements for the x86 FFTs, but further improvements require a lot of coding. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Should I switch an exponent to another processor type?
At 11:20 AM 7/26/2003 +0100, Doug Feather wrote: I've currently got an exponent of the order of 20.05M running on a P4 (1.8Mhz). It has decided to run it with FFT size 1280K. It's done just over 1M iterations (and hasn't finished Stage 2 P-1 since this only runs for a few hours each night). If I'd of know that it was going to use this FFT size before it started, it would have been better for me to switch it to another processor type - since then it would have used a smaller FFT size. If I now move the saved file to another processor type would it use a smaller FFT size or is the FFT size hard coded into the save file or is this a bad idea to move the saved file for other reasons? I think you can move it to another machine without problem. The FFT size is encoded in the save file, but when the save file is opened prime95 checks to see if a different FFT length should be used and converts if necessary. The only downside to moving an exponent is that if *either* computer has hardware problems, then your result could be corrupted. You could also look in undoc.txt for options on making prime95 choose FFT crossover points more aggressively. Look in results.txt for info on how close prime95 was to choosing the 1024K FFT length. If it was a really close call you could edit local.ini to make it choose the 1024k FFT length for that exponent. While on the subject of FFT size where is the information stored about which FFT size tests have been run on each machine? This information is not recorded anywhere - my database does not care which FFT length was used on each LL result. _ 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
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
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
Mersenne: M997 factored
Bruce Dodson has found an incredible 57 digit factor of M997 using prime95's ECM. This is two digits longer than the previous longest factor found using the ECM method. Here's the output from prime95: ECM found a factor in curve #14, stage #2 Sigma=6329517009540700, B1=4400, B2=429000. UID: bd1024tmp, M997 has a factor: 167560816514084819488737767976263150405095191554732902607 Cofactor is a probable prime! Congratulations to Bruce on this improbable discovery! _ 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 12:44 AM 6/17/2003 +, Elias Daher wrote: no matter how quick this additional test will be, it will slow down all machines globally, if we consider that this additional test takes only 3 minutes per exponent overall in average, ... The test will take at most 300 clock cycles (the time to read a double from main memory). 20,000,000 iterations * 300 clocks / 1 GHz cpu speed will add only 6 seconds to the average LL test. This is 30 times better than your 3 minutes estimate. I think adding 6 seconds or even 3 minutes per LL test will have negligible impact on GIMPS throughput. Your analysis is correct, but maybe there are other small, unquantifiable factors at work. How about the possible cost of a second false alarm causing 3 people to drop out of GIMPS saying "these guys are bozos that don't learn from their mistakes"? _ 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 05:08 PM 6/16/2003 -0400, Bill Daly wrote: Occam's Razor suggests that the original report was faked. Until this possibility can be absolutely eliminated, It can't be absolutely eliminated. However, there are many indications that this was not a hacking attempt. The user has been at this 5 years. His emails we're genuine. He made no attempt at gaining publicity. He's more my age (old) rather than the typical hacker age (young). If this was a hacking attempt, why create a results.txt file showing 5 errors during the run? In the end, it doesn't really matter. Even if this we're a hacking attempt, tightening up the code to reduce the chance of a false positive is a good thing. _ 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 - 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 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: 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
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
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: 40th Mersenne Prime Found (probably)!
At 08:20 PM 6/1/2003 +0100, Daran wrote: I presume you're doing an unofficial DC on it right now. Can you give us some idea when this will be complete? I wasn't going to do one but Ernst has started his and suggests comparing residues every 1,000,000 iterations. A good idea, so I've just begun my test. Ernst will finish his official test in the June 20-21 time frame. I should finish sometime on the 11th. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: 40th Mersenne Prime Found (probably)!
Hello all, This morning a new Mersenne Prime was reported to the primenet server. It will be the new largest known prime but is less than 10 million digits. For those not familiar with the process regarding new prime discoveries, here is what will happen. The discovery will be verified using a different program and different hardware. The discoverer and the exponent will be kept secret until verification is complete. This is done for two reasons: 1) It reduces the incentive for a malicious user to hack prime95 to report a bogus prime, and 2) It makes it easier to interest a newspaper in reporting the find (they are breaking news rather than reporting 2-week old information). Congratulations to all! New primes can't be found without the thousands of unsuccessful tests contributed by everyone. Enjoy, George _ 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
Re: Mersenne: P-1 on PIII or P4?
At 09:05 PM 3/10/2003 +, Brian J. Beesley wrote: On Monday 10 March 2003 07:49, Daran wrote: > Or is there some > reason I can't think of, why higher values might be appropriate for a P4? George? The Athlon system picked B1=105000, B2=1995000 whilst the P4 picked B1=105000, B2=2126250. So it seems that P4 is picking a significantly but not grossly higher B2 value. I looked at the bounds picking code and there is no special action taken for the P4. The only place I can see a difference is in the calculation of number of temporary variables. The P4 FFT uses a denser memory layout than the x86 FFT. Thus you might get an extra temporary or two. And you just happened to hit a boundary condition where the extra temporary allowed P-1 to use a more efficient stage 2 implementation and consequently it pays to run stage 2 a little longer. Only running prime95 with the debugger on could prove this theory. --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.459 / Virus Database: 258 - Release Date: 2/25/2003
Mersenne: New record P-1 factor
Frank Hornung found the largest factor ever found using P-1. M17504141 is divisible by the 45-digit factor 426315489966437174530195419710289226952407399 Paul Zimmermann maintains a list of P-1 records here: http://www.loria.fr/~zimmerma/records/Pminus1.html --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.454 / Virus Database: 253 - Release Date: 2/10/2003
Re: Mersenne: exponent reported not prime in 'results.txt', but not communicated to primenet.
At 10:48 PM 2/25/2003 +0100, george de fockert wrote: Indeed, primenet knows nothing, and still assumes my machine is busy with that exponent. What to do now, enter it in 'worktodo.ini' manually ? That is weird. Email the result for 16519367 to me. Regards, George --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/2003
Re: Mersenne: Double-check assignment lost?
At 08:39 PM 2/22/2003 -0500, Walt Mankowski wrote: So someone's poaching double-checks now?! *Sigh* > 8970673 65 D 0x45932E28306E98__21-Feb-03 19:10 S93724 > C4159C890 > > Someone has done it. I don't know why. It is highly unlikely that someone poached this exponent. It is not near a milestone and the exponent is not of any particular significance. Most likely, either 1) you got a recycled exponent and the result was belatedly reported, or 2) someone operating manually and/or not understanding how GIMPS works tested the exponent, or 3) the server glitched and handed it out twice, or even 4) the first time tester might have tested it again for reasons unknown, or 5) some reason I haven't thought of. Sorry for your troubles, George --- Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/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: "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: 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: 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: 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: 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
Re: Mersenne: An officially sanctioned poach....
At 10:02 AM 1/28/2003 -0800, you wrote: Far be it from me to tell you that you are wrong, but that is not at all consistent with what I observe with my own exponents. For instance, exponent 19373911 shows a 9 right now, it connected a short while ago and the machine is early in the 66 bit pass. The percent complete is about to hit 12.5%, at which time I should be able to force a manual connect and then it will show a 10. Yep, it now shows a 10. I stand corrected. I wonder is some older versions used to behave the buggy way that I described. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: An officially sanctioned poach....
Thanks for the insight that some of these exponents might be reporting no progress because they were manually reserved and running on a UNIX or MAC box. I've pruned the list a little bit and released the exponents. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: An officially sanctioned poach....
At 09:36 PM 1/27/2003 -0800, Mary K. Conner wrote: Garo identified some Team_Prime_Rib exponents in there. I'll exempt all Team_Prime_Rib exponents Looking at the other exponents in the factoring range I'm not worried about reclaiming factoring assignments right now. The tsc machines show some very odd behavior. The exponents do a "red light, green light" game. One exponent I've been following started at 5, went to 2, back up to 5, then ran all the way up to 15 before dropping back to nothing and now it shows a 1. Others are similarly dancing around When factoring, the iterations will increase from 1 to 15 for each bit level. In other words, the field provides no useful information for trial factoring assignments. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: VS: Mersenne: An officially sanctioned poach....
At 10:23 PM 1/27/2003 +0100, Torben Schlüntz wrote: I don't really understand the question. If these 185 assignments have made NO progress in a year why didn't they expire in about 60 days automaticly? Do you by NO progress mean close to NO progress? Look at this example in the assignments report: 7231183, 327 days, S09625, Cel13 It looks like the machine has reserved several exponents and is slowly crunching through the first one. It checks in every 28 days and keeps all its reservations alive. It looks like prime95 is miscalculating expected completion dates and not unreserving the exponents that have not started. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
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
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
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
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
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
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
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 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: 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: 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
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
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
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 06:15 PM 10/4/2002 +0100, Barry Stokes wrote: >The trouble is, I have now >completed one of these factoring jobs, and it's no longer assigned to me, >which is quite annoying, as it means that work is going to be duplicated by >whoever now has the number. The work will not get duplicated if the exponent was picked up by one of the misbehaving v18 clients (not that this absolves me of guilt in creating this situation :) _ 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: Composite factors.
The record P-1 factor is 56379662829467477289264041716715663 or 129 bits. -Original Message- I don't think P-1 has found a "proper" factor exceeding 110 bits, yet. _ 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: More error info
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 131462533.4% 219213558.7% 31076362.9% 4743667.3% 5531775.7% 6482070.6% 731781.6% 8301075.0% 9171063.0% 1025292.6% >103755886.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
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: 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
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: 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 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: 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: 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: 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
Mersenne: GIMPS forums!
Hello all, Thanks to the dedication of a GIMPS member, we now have our very own bulletin board system. Check it out at http://www.teamprimerib.com/gimps/ The forums are empty now, but you can be among the first to start up a new thread. Sign up and introduce yourself, then we'll see what this grows into! I know some folks prefer the mailing list approach for news. I'll continue to post news on this mailing list and on the forums. The forums will let us do searches and see past posts easily. Have fun, George P.S. Don't be fooled by the "www.teamprimerib.com" in the URL. The forums are for all GIMPS members and will not be used as promotional tool for this particular GIMPS team. _ 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 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 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: 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
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: W2K service installation problems
Hi, At 09:22 AM 7/25/2002 +0200, Helmut Zeisel wrote: >I recently upgraded from WinNT to W2K and now want to install >the service version of mprime again. > >Since I previously used ntprime, I tried "ntprime -install". >This worked, but starting the service exits with > >Could not start the Prime Service service on Local Computer. >Error 5: Access is denied. > >I have administrator rights, so this should not be the cause. > >Anyway, I downloaded FireDaemon-Light-1_5-BRC1.exe and installed Prime95. >Starting FiredDaemonService: prime95 now exits with > >Could not start the FireDaemon Service: prime 95 service on Local Computer. >Error 1: Incorrect function. > >Any hints what went wrong? Not really. Please try ftp://mersenne.org/gimps/p95v227.zip The GUI version can now be installed as an NT service. Just check the "Start at Bootup" menu option. This is a new feature so let me know of any problems. Thanks, George _ 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 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: 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: 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: 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: 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: Prime95 as an NT/2000/XP service
I played around some more with the Services Control Panel Applet. If you uncheck the "Allow service to interact with desktop" and leave it in the Local System account then the new prime95 service still runs OK. Prime95 does not appear on the end user's desktop. You can still configure prime95 by stopping the service, running prime95 as a normal app (user privileges rather than Local System privileges), change your settings, exit prime95, start the service. Is this secure enough for you hardcore server admins? I could not get the new prime95 service to run in a user account. I don't know if this is merely due to my limited NT experience. At 07:06 PM 6/26/2002 +, Brian J. Beesley wrote: > > My hope is to eliminate the NTsetup and NTPrime programs with this feature. >Umm - what is the problem with keeping these? It just makes my life easier. Right now if I change a dialog box, I need to change it in Prime95 and NTsetup. I'm not against supporting the old NT service (maybe without NTsetup), but if the new scheme works it is easier to support only one style of NT service. >Really dumb question - why does a service need a GUI interface at all? You don't need it very often - just to do a status check, run a benchmark, etc. I'd bet most users play with the GUI occasionally for the first month and never use it again. As to the separate DLL or having a service talk to a gui via named piped (the MS preferred solution, I'm trying to solve the WinXP problem with a minimum amount of work on my part. Splitting the working existing GUI into two separate pieces is not an easy chore. BTW, the WinXP problem is naive home users (like me!) can set up user accounts for different family members. In V21 prime95, selecting "start at bootup" really starts at logon and does not handle logging off or a second user logging on well at all. Naive users are not savvy enough to install the old NT service version. _ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
