Mersenne: Linux question
Hi, I was asked this question today. Since I'm not a Linux user, any help in answering this question is appreciated. My computer is now dual boot Linux/Windows 95. I have downloaded mprime and put it in the same folder as prime95 and verified that it runs. How can I set it up so that it runs automatically when I boot Linux? It is on the Windows 95 disk and all files on that disk, as far as Linux is concerned, are owned by root and cannot be written by anyone else. Thanks, George
Mersenne: New prime95 and ntprime version (16.5)
Hi all, A quick note about today's new version. There is virtually no reason to upgrade. The new features are described below. The biggest change is that network retries will now default to 60 minutes. The NT services version now supports ECM factoring. Best regards, George New features in Version 16.5 of prime95.exe --- 1) A new httpnet.dll can provide Scott Kurowski with debugging information. Simply create a primenet.ini file with these lines: [Debug] PacketLog=1 Output file is pnHttp.txt. 2) The old network retry time has been replaced by two settings. The modem retry time (default 2 minutes) controls how often prime95 polls your modem to see if you are connected to the Internet. The network retry time (default 60 minutes) controls how long prime95 waits after a failed attempt to contact the server. 3) A timestamp and program version number is written to the prime.log file. 4) You can now switch between HTTP-based and RPC-based PrimeNet protocols from the Test/Primenet dialog box.
Re: Mersenne: Mersenne v 17
Hi, At 10:57 AM 10/4/98 -0700, Terry S. Arnold wrote: What is the expected release date for the Prime95 v17? From what I have heard that is the version that supports a modified algorithm for double checking. I have a couple of machines that would (and have for several years) do just fine for the smaller numbers. I expect to release v17 this week. Regards, George
Mersenne: Error rate
Hi all, The first results are in from version 17.0 535 results have been reported with 7 mismatched residues. Of those 7, 2 had errors reported during the version 17.0 run. Thus, very preliminary data indicates that if you get an error-free double-check run under version 17, then there is about 1 in 100 chance that you are doing a first-time check that could find a new Mersenne prime. Actually, the odds could be lower as I assumed the 5 mismatches were due to a bad initial run as opposed to a bad version 17 run. Unfortunately, my database is not well enough organized to know whether any errors were reported on the initial run of those 5 numbers. I'll post updated numbers at a later date. Best regards, George
Re: Mersenne: Error: Illegal Sumout
At 01:29 PM 10/28/98 -0700, Chuck Baker wrote: I think my Prime95 broke! I am on iteneration 479162/5518463 and get a continuous stream of "ERROR: ILLEGAL SUMOUT" messages which are constantly sent to the primenet server. I am running version 16.3.1 of Prime95. I have no choice but to shut it down until I figure out what went wrong. Any suggestions? This is probably an interaction with some new piece of software. I know that the OS should protect you from such interactions, but this problem is quite common. Have you installed any new device drivers lately - especially those that might use MMX (audio and midi cards)? Are you running any new programs? The good news is that these errors do not seem to affect prime95's accuracy (unlike other error messages). A recent double-check had 3 SUMOUT errors, but the residues matched anyway. Hope that helps, George
Mersenne: Prime95 version 17.1
Hi all, Prime95 version 17.1 is now available. As usual, go to http://www.mersenne.org/freesoft.htm to download it. The whatsnew.txt file is included below. The first new features is the ability to use ECM factoring on numbers of the form 2^N+1. See http://www.mersenne.org/ecm.htm for exponents that need work (be sure to download lowp.txt). Of special interest are three Fermat numbers: F14 = 2^16384+1 has no known factors, and F12 and F13 are the smallest Fermat numbers that are not completely factored. The 2^N+1 factorer is not quite as fast the 2^N-1 factorer and only supports power-of-two FFT run lengths. The second new feature is the ability to run prime95 with different options at different times of the day (such as a priority above a screen saver at night). You can also have prime95 sleep during some hours of the day. Barring any bug reports, ports to other platforms will occur next week. Happy hunting, George 1) The -T command line switch has been deleted. 2) You can now fine tune your control of the program by adding Time= lines to your prime.ini file - see the readme.txt file. 3) ECM factoring for 2^N+1 is now available. 4) By default, ECM factoring stops if a factor is found for exponents above 5825 and continues (if the cofactor is composite) for exponents below 5825. You can override this behavior by setting ContinueECM=0 or 1 in prime.ini.
Re: Mersenne: Primenet software under Win95 and OS/2
Hi, At 02:52 PM 10/29/98 CST, Richard G. Larson wrote: install the mersenne stuff in one directory on a drive shared by OS/2 and Win95 with them sharing the Pxxx, Qxxx etc files When I tried it, Win95 picked up the computation that OS/2 was doing when I booted it, but when I went back to OS/2, the partial computations were lost. The results.txt file is: Win95 is running version 17 which can read a version 16 save file. Unfortunately, version 16 OS/2 cannot read the version 17 save file. If you'd like, I can email a version 16 win95 program to you. Regards, George
Re: Mersenne: Question about double checking
Hi, At 03:24 PM 10/31/98 +0100, [EMAIL PROTECTED] wrote: I reserved one machine for double checking using IPS' manual reservation form. I was suprised to see that Prime95 started factoring and was even more suprised that it found several factors. Why the factoring if they have been LL-tested before? The optimal breakeven point for factoring vs. LL testing changes every time the factoring code or LL code changes. In the old days, the breakeven point was 2^56, now its 2^57. Another question is how I can be sure the program is double-checking and not doing the original LL test over again, which I am afraid it does when pasting the form's output into worktodo.ini? You must be running version 17, otherwise you are just repeating the previous test. When you're using the automatic method the server won't assign double-checks to a version 16 client, but when using the web pages the server just trusts you. Regards, George
Mersenne: Version 17.1
Hi all, Version 17.1 (with 2^N+1 ECM factoring and INI files that support a new Time= option) is now available for Linux and Windows NT service users (http://www.mersenne.org/freesoft.htm). To those using the Windows 95 version to do 2^N+1 factoring, you should download a new version. A bug was fixed: stopping a 2^N+1 ECM run incorrectly updated the worktodo.ini file, upon restart the program would start 2^N-1 ECM runs. The source code has also been updated (http://www.mersenne.org/source.htm). Best regards, George
Re: Mersenne: What computer is OK today?
Hi Yuri, At 10:48 PM 11/11/98 -0800, Yuri Sorkin wrote: I participated in GIMPS from the very beginning, Yuri was indeed one of the earliest members, LL testing exponents below 500,000 with a 486. How times have changed! And now I see that my P5-166 (SDRAM, MMX, Intel) doesn't get from Primenet anything for LL-test quite awhile. Since I'm going to buy a new desktop soon and consider its suitability for GIMPS to be a certain indicator of satisfactorily performance, I wonder what computers get exponents for a test now? In version 17, less than a P-75 will get factoring work. Less than a P-133 will get double-checking assignments, P-133 and higher will get first-time LL tests. A year from now, less than a P-200 will get double-checking assignments, P-200 and higher will get first-time LL tests. If your P-166 is getting double-check assignments now, there are three possible causes: 1) Your CPU hours per day is set below 24. A P-166 running 12 hours a day is treated like a P-83. 2) Your machine is substantially slower than other P-166s. Look in local.ini and find the line RollingAverage=xxx. If xxx if a lot less than 1000, then this is the cause. 3) There is a bug in the program. If so, please send your ini files to me by private email. For those on a tight budget, consider building a machine around the Intel Celeron 300A. There have been many success stories overclocking this chip to 450MHz with a 100MHz front-side bus. This suggestion is only for the most knowledgable hardware enthusiasts - see the Usenet newsgroup comp.sys.intel for more information and ideas. Best regards, George
Re: Mersenne: Password safety
Hi, At 11:07 AM 11/12/98 -0500, Michael Clark wrote: What (if any) are the concerns with having an account's password and user ID posted on a web page? Would someone be able to change the "Your Name" and "Your email address" fields with them? So if my school set up a web page to encourage people to join our team, could someone come along and usurp our work? Also, what would happen if someone changed (or deleted) the existing UserID and password in the middle of a LL test? On your machine, set LockUserInfo=1 in prime.ini The next time you run prime95, this will be sent to the server which will then prevent anyone from changing your user name or hijacking your results. I know this is a rather kludgy way to implement teams, but it is the only method at present. Maybe someday we can do better. If someone changes userids mid-LL test the credit will go to the new userid (presumably the owner of the machine has abandoned your team). Perhaps a web page that contained an entire directory with filled in .ini files (and LockUserInfo=1 set to disable the user info dialog box) is the best way for you to go. Scott Kurowski is the best person to answer your questions regarding any possible danger in sharing your password. Hope that helps, George
Mersenne: IMPORTANT: BUG IN VERSION PRIME95 17
Hi all, Please forgive me. I'm terribly sorry. I've discovered a bug in version 17 of prime95 and its variants (ntprime, mprime, OS/2 version). All Lucas-Lehmer tests above 4,194,304 (except those that were done as a continuation of a v16 run) are no good. I feel sick. I've uploaded version 18 of prime95 and ntprime. I'll port it to Linux and Windows 3.1 as soon as I can. Please download and install this new version immediately from http:\\www.mersenne.org\freesoft.htm Version 16 and earlier users were not affected by this bug. Neither were those users that are double-checking. I've asked Scott to change Primenet to assign double-checking work to version 17 clients in the future. I don't know if he can do this or not, let's hope so. After upgrading, you will get error messages that look like this: Error reading intermediate file: p6180331 Renaming intermediate file q6180331 to p6180331. Error reading intermediate file: p6180331 This is normal. Prime95 must discard the incorrect version 17 save files. My records indicate that 10,794 of the 59,169 Lucas-Lehmer tests above 4,194,304 will have to be discarded. This will set GIMPS back roughly 3 to 4 months. This will not affect your standings on the PrimeNet server's Top Producer's page. For those that like to look at the bright side of things, I can find only one bit of good news. This will give you a better chance to win the $50,000 EFF prize once I sort out the mess and have the server hand out smaller exponents to retest. Once again, I'm sorry for the bug and the wasted CPU cycles the last few months. Humbled, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: RE: IMPORTANT: BUG IN VERSION 17 OF PRIME95
Hi all, The fixed Linux version is ready. Please download and install this new version immediately from http:\\www.mersenne.org\freesoft.htm Regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Re: More on v17 bug
Hi once again, At 09:59 PM 4/1/99 -0500, Bryan Fullerton wrote: I just downloaded the new mprime.tar.gz from the entropia.com FTP site, and it appears to still be v17.1.2 - the binaries are dated Nov 3, 1998. Oops. It's been a long day. I'm uploading the proper ones now. Bryan wrote earlier about deleting of v17 save files when you are double-checking and uprgade to v18. The answer is yes you will lose your good v17 work. If you are double-checking, please wait to upgrade. I'll release version 18.1 that will toss the old save file only if you are testing an exponent above 4.19 million. Scott just contacted me. To have the server redirect all v17 clients to double-checking work, I'll need to tweak v18 a little more so that the server can distinguish between the two clients. Thus, unless we think of something clever a version 18.1 will be released tomorrow. Version 18.0 will work properly, but will only get double-check assignments in the future. Looks like I panicked and rushed 18.0 out a little hastily :) Aaron Blosser wrote: So, just to clarify, if there were any results of exponents under ~4.2M, they should be okay, meaning if I used 17.2 to doublecheck numbers in the 2M range, they're fine? It's only all those ones higher done with 17.x that need to be done again? And was it 17.1 *and* 17.2, or just 17.2? Yes, all 17.x results above ~4.2M are affected. Your double-checks in the 2M area are just fine. I did notice that after upgrading on my machines, even those that were double-checking exponents in the 2M range started over. Is that just to be safe? Should we consider triple-checking all those that were double-checked with 17.x? I'll fix the program as noted above to not delete double-checking save files. There is no need to triple-check. Will Scott be able to simply root out all tested numbers done with 17.x Scott and I will work it out and get the numbers scheduled for a retest. Best regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Re: Is bug a hoax?
Hi all, At 06:45 PM 4/2/99 +0200, Henrik Olsen wrote: Somehow I find it suspicious that the assignments status report http://entropia.com/primenet/status.txt shows no change at all in the pattern of assignments, something that should have been immediately visible if ~1 exponents had been recycled for first time LL-testing The first task was to fix the program. Scott and I are now working out a plan to get the 1 affected exponents back in the queue. That should happen sometime over the next few days. There should be a slight uptick in double-check assignments that go out. Unfortunately, the server cannot contact the v17 clients and tell them to ditch their current assignments and get new ones. So only those that are running low on work will get double-check assignments. Best regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: double checking
Hi Bryan, At 03:45 AM 11/18/98 -0500, Bryan Fullerton wrote: I've noticed that when I manually request exponents from the Primenet web page the lines to be inserted into worktodo.ini all start with Test=, but when the util gets double checking exponents itself the lines start with DoubleCheck=. Is there any functional difference between these two? Scott should tweak his web forms. There is only one difference. The probability of finding a new prime as reported by Test/Status is much smaller when the correct DoubleCheck= syntax is used. Best regards, George
Re: Mersenne: GIMPS Statistics
At 07:50 AM 11/19/98 EST, [EMAIL PROTECTED] wrote: There used to be a page of GIMPS statistics at: http://project.vobis.de/cgi-bin/mersenne.cgi Did it disappear? I haven't been able to access it for weeks. I've emailed Guido to see if he is still supporting his statistics page. He has not replied yet. If it is not up by Sunday, I'll upload a full stats page rather than a top 100 page at http://www.mersenne.org/top.htm Regards, George
Re: Mersenne: RE: any large groups that run GIMPS software on corporate computers?
Hi Lars and list members, At 06:13 PM 11/24/98 +0100, Lars wrote: But sometimes it happened that mprime went mad due to the fact that it had to write intermediate files onto an nfs mounted remote disk, which sometimes failed because the network wasn't properly set up. It then tended to steal more cycles than would be expected from a 'nice' process (and didn't produce anything sensible anymore). Are there any Linux experts that can clue me in on what might have gone wrong and what code I would need to prevent this in the future? I don't know if he was aware of this problem, but finally I had to obey because he insisted that his machine runs slower if mprime runs on it, I'm sure Lars, a long-time GIMPS participant knows this, but others might benefit: The time between disk writes is adjustable, the default is 30 minutes. Lars was running mprime long before this was adjustable. Version 17 now supports a Time= option in the prime.ini file. This can be used to make mprime sleep during the work day. This might be enough to convince an Administrator that mprime is safe. If there are other ideas on how to make mprime or Prime95 less intrusive please forward them to me by private email. Regards, George
Re: Mersenne: Double checked residues
At 07:56 AM 11/30/98 -0800, Greg Hewgill wrote: I was looking through the list of double checked exponents and their residues (lucas_v.txt) and noticed four exponents near the bottom that only had one listed residue: 5510339,tompete,Tom,WT1,1070460990F198F8 5704913,jhertel,hstar-sc,WT5,26CF19E736BD10DA 5704957,jhertel,hstar-wb,WT5,BFB8E1CF9DC6DE9C 5757253,jhertel,hstar-sv,WT5,E63F0DA56CB5B8E9 Why is this? A bug. They were reported by the same user using two different computer Ids. This was later detected and the duplicate removed. I just fixed the program that automatically moves items from the once tested to the double-checked list to not do this if the same userid reported both residues. Many thanks, George
Mersenne: Re: Mayer's Counter-Challenge
Hi, First off, thanks to all that have submitted ideas to my factoring challenge. A few have even started to write the assembly code. I hope to incorporate these ideas and code sometime next year. Secondly, I must apologize for not reviewing and commenting on the suggestions. I have saved them all for a thorough review at a later date. However, Mayer's idea got me thinking... At 05:12 PM 11/26/98 +0100, Mayer wrote something to the effect of: Prove that P-1 factoring won't be better than more sieving. I wrote a program to analyze P-1 factoring success rate. I assumed that GCDs are free (they certainly aren't) and that factors longer than 87-bits won't change the calculations much. Basically, P-1 succeeds if the k in the factor of the form 2kp+1 is smooth, that is, k has no large factors. My program samples a 1000 values of k to compute a success rate: A sample run: Analysis of p=1019, how_far_factored=64, B1=2, B2=20 65-bit factors: 8.5% in pass 1, 18.3% in pass 2 66-bit factors: 7.8% in pass 1, 16.6% in pass 2 67-bit factors: 6.6% in pass 1, 14.8% in pass 2 68-bit factors: 5.7% in pass 1, 13.4% in pass 2 69-bit factors: 4.7% in pass 1, 11.7% in pass 2 70-bit factors: 3.6% in pass 1, 9% in pass 2 71-bit factors: 4% in pass 1, 9.4% in pass 2 72-bit factors: 3.3% in pass 1, 8.4% in pass 2 73-bit factors: 1.7% in pass 1, 5.9% in pass 2 74-bit factors: 1.4% in pass 1, 5.2% in pass 2 75-bit factors: 1.1% in pass 1, 4% in pass 2 76-bit factors: 0.9% in pass 1, 3.7% in pass 2 77-bit factors: 1% in pass 1, 3.3% in pass 2 78-bit factors: 0.8% in pass 1, 3% in pass 2 79-bit factors: 1% in pass 1, 2.9% in pass 2 80-bit factors: 0.6% in pass 1, 2.9% in pass 2 81-bit factors: 0.7% in pass 1, 2.7% in pass 2 82-bit factors: 0.4% in pass 1, 1.5% in pass 2 83-bit factors: 0.5% in pass 1, 1.8% in pass 2 84-bit factors: 0.3% in pass 1, 1.2% in pass 2 85-bit factors: 0.2% in pass 1, 2% in pass 2 86-bit factors: 0.2% in pass 1, 1.3% in pass 2 87-bit factors: 0.4% in pass 1, 1.1% in pass 2 Pass 1 squarings: 28820 or 0.2882% Pass 2 squarings: 15722 or 0.15722% Total probability of finding a factor: 2.04448% That is, P-1 will cover 18.3% of the 65-bit factors (a .183/65 chance that a 65-bit factor will be found). And for a cost of 44542 squarings (or .445% of a LL test) you will eliminate 2.04% of the LL candidates. A winner!! So the questions are now 1) What are the optimal values for B1 and B2? and 2) Will sieving find more factors in less time than P-1 factoring? The code is available at http://www.magicnet.net/~woltman/pminus1.cpp for those that want to play with it. Some other runs: Analysis of p=1019, how_far_factored=64, B1=2, B2=40 Pass 1 squarings: 28820 or 0.2882% Pass 2 squarings: 31598 or 0.315979% Total probability of finding a factor: 2.46762% Analysis of p=1019, how_far_factored=64, B1=2, B2=80 Pass 1 squarings: 28820 or 0.2882% Pass 2 squarings: 61689 or 0.616889% Total probability of finding a factor: 2.90801% Analysis of p=1019, how_far_factored=64, B1=5, B2=50 Pass 1 squarings: 72114.5 or 0.721144% Pass 2 squarings: 36405 or 0.364049% Total probability of finding a factor: 3.0994% Analysis of p=1019, how_far_factored=64, B1=5, B2=100 Pass 1 squarings: 72114.5 or 0.721144% Pass 2 squarings: 73365 or 0.733649% Total probability of finding a factor: 3.68311% Analysis of p=1019, how_far_factored=64, B1=5, B2=200 Pass 1 squarings: 72114.5 or 0.721144% Pass 2 squarings: 143800 or 1.438% Total probability of finding a factor: 4.26091% Analysis of p=1019, how_far_factored=64, B1=10, B2=200 Pass 1 squarings: 144344 or 1.44344% Pass 2 squarings: 139341 or 1.39341% Total probability of finding a factor: 4.70716% Analysis of p=1019, how_far_factored=64, B1=10, B2=400 Pass 1 squarings: 144344 or 1.44344% Pass 2 squarings: 273554 or 2.73553% Total probability of finding a factor: 5.35872% Analysis of p=1019, how_far_factored=64, B1=10, B2=800 Pass 1 squarings: 144344 or 1.44344% Pass 2 squarings: 530185 or 5.30184% Total probability of finding a factor: 5.9836%
Re: Mersenne: Errors
Hi, At 01:21 PM 1/10/99 +0100, Ignacio Larrosa Cañestro wrote: I get the next lines in a results.txt file: Iteration: 485/6404297, ERROR: ILLEGAL SUMOUT UID: ILC/P166-Casa, M6404297 is not prime. Res64: F06542B838248F__. WT1: 1F13B5C4,403638, It's correct? Must not be the last field in the last line ? Brian is correct. The problem is that the error count didn't get written to disk. In fact, the updated error count is only written to disk at the next normal save file write. Thus, the error count could take as long as 30 minutes to get written to disk. I'll investigate a fix for the next release. Best regards, George
Re: Mersenne: mprime for QA or performance?
Hi, At 12:24 AM 1/13/99 -0800, Leu Enterprises Unlimited wrote: On one CPU, after two days worth of burn-in, the time required to complete 100 iterations on the stock number went down, as I would expect. On a second CPU, the time actually *increased*. From 1 day, 18 hours, and 55 minutes, to 1d 19h 13m! I'd be surprised if burning in had an effect on iteration times. More likely, 100 iterations is not enough to get a truly accurate timing. I don't know about Linux, but it has been noted before prime95 iteration times can vary a few percent from day to day. If anyone knowledgeable would care to comment about mprime's suitability for Q.A. mprime is great for QA. It generates heat (by FPU use) and tons of memory accesses. If there are any hardware problems there, they are likely to show up in an extended torture test. and/or performance measurements, I'd guess its as good as but no better than any of hundreds of publicly available benchmarks. Best regards, George
Mersenne: Double-checking (was Chronons)
Hi, At 07:35 PM 2/26/99 -0800, Spike Jones wrote: How about sweetening the pot for anyone who is doing double checking that discovers a mistake in the first LL analysis? How does this work? The first LL test returns a residual, then the double checking routine takes that residual and... what? How often is a result overturned by double checking? From your point of view a double-check is just like a first time test. You run a Lucas-Lehmer test and when done send in your 64-bit residue. I compare that residue to the first run and if they match, the exponent is declared double-checked. If they don't match, a third test is run to properly double-check the number. Finding an error in the first LL test is not rare. I've said about 1 in 200 are incorrect. When the entire 1,400,000 - 2,000,000 range has been double-checked I'll perform some more rigorous analysis of the reliability of first-time LL results. Best regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: preventive measures
Hi all, At 04:56 PM 4/3/99 -0600, Ken Kriesel wrote: Since we now have a wealth of exponents to be tested or retested, requiring a total expenditure of billions of cpu-hours, perhaps we could introduce a little more formalism into the program-validation process. I volunteered months ago to test 1 or 2 exponents in each runlength. Several have completed. Brian Beesley offered to double-check my results, and George has assigned them to Brian as double-checks. The nature of the just-discovered bug suggests that more test cases are in order. I propose the following be considered, for each future version released (and for the versions in heavy use currently): 1. Code review by qualified volunteers. A good idea for the C code, I doubt the assembly code qualifies. 2. George and such other people as are qualified, determine which exponents make good test cases, based on a review of the code. My input: 1) Those near the end of each range should be checked for excessive convolution error. In fact, it would be nice it the QA suite recommended the crossover points for the FFTs. 2) Exponents that are close to a multiple of the FFT length. Crandall's "magic numbers" are very sensitive here. 3. Volunteers with some cpu-power run LLtests and double-checks on the test cases selected. As pointed out earlier, a few hundred iterations *should* suffice. But Ken may decide a few more lengthy checks are required. And as v17 pointed out, the shifting code needs to be checked in the above tests. Since this project is in a sense George's baby, I feel he has the right to ok or nix this. If he says ok, I volunteer to be the contact point for volunteers to enlist as either code reviewers, testers, or both. After a week or two I will summarize to George. OK, I never turn down a volunteer! I hereby appint Ken the coordinator of the official GIMPS QA project. First order of business is a plan of action - formulating the QA test suite. How much CPU power are we going to require? Would enough tests to keep 5 volunteers busy for 24 hours suffice? Will the ports run shorter suites? This QA suite will not be my baby, so don't be shy folks in chiming in with ideas or offering to help Ken out. I'll put in whatever hooks you folks need. Now for some good news Prime95 v19 is under way. It involves rewriting ALL the FFT code! So this QA project is quite timely. What's new in v19? It should support FFT lengths from 32 up to 4M with PFA lengths (3*power-of-two and 5*power-of-two) supported. It has a slightly modified memory model that should be more efficient in using the Pentium's TLB (translation look-aside buffers) cache for larger FFT sizes. A little less memory traffic for some FFT lengths. P-1 factoring support. What isn't coded yet: Save files for P-1 and ECM factoring. A O(n log n) GCD to make P-1 and ECM factoring on larger exponents feasible. A more memory efficient but slower stage 2 for large exponents. Several FFT sizes are not coded yet. Obviously, don't expect v19 anytime soon! Here's a teaser: A 128K FFT is 1.5% faster, a 512K FFT is 5% faster. Oh, and by the way, the re-engineered assembly code will be easily usable in other large integer programs. Best regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Top Producers Reports
Hi all, At 11:23 AM 4/4/99 -0700, Terry S. Arnold wrote: The top producers report over at Georges site appears to have wiped out all of the V17 work (and maybe some more) while the equivalent report on Scott's site has not. Could we at least be consistent. I just loaded the latest Top Producers page and v17 work should be recredited. As Scott noted, the Primenet server's page and mersenne.Org's page track two different things. Historically, mersenne.org does not track factoring work (I don't have the data to do so), decredits LL tests that were later found bad or a factor was found. It also applies the timings of the latest prime95 to produce its results. However, I understand that some people use that page as a motivator, and the v17 bug was my fault, so I've changed my programs to include those bad results. I thought about "phasing out" the credit for these v17 results (just so I don't have to track them), but did not reach a definitive decision. Note that when the next version of prime95 comes out, everyone will take a hit as the new faster timings are applied. Use the page as a rough indicator of where you stand relative to other GIMPS members. Don't take it as an overly accurate accounting of every CPU cycle you have invested. Best regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Strange Prime95 behaviour...
Hi Aaron and List Members, At 05:06 PM 5/3/99 -0600, Aaron Blosser wrote: Did the requirements for double-checking change? No. The server is out of double-check assignments to hand out. Until the problem is fixed it will hand out factoring assignments instead. The root of the problem is that the Primenet Server upgrade a couple of months back has broken our ability to do a database merge. The database of 2 months ago only had double-check assignments up to 3021377. My latest database has exponents up to 5,000,000 available, but until we can do a merge the server will hand out factoring work. Sorry for the inconvenience, George P.S. For those that don't know what a database merge is, Scott and I maintain separate databases of results. Every once in a while we merge or sync up. Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Any statistics majors out there?
Hi all, I'm working on version 19 of prime95 and I need your help. In the past, the exponents at which a larger FFT is used was picked rather haphazardly. I simply picked a few exponents trying to find one that could run a thousand or so iterations without the convolution error greatly exceeding 0.3. For this release, I thought it would be nice to use a more scientific approach. What I've done is run almost 1 iterations of an exponent and used Excel to graph the number of iterations with an error between 0.200 and 0.201, 0.201 and 0.202, etc. As you can imagine you get a Bell-like curve that peaks at some value. Since it has been 25 years since I took statistics courses in college, I am at a loss as to how to use this graph to predict the probability that N iterations will have an error below M. I could then use such information to find the exponent such that the chance of a convolution error exceeding 0.5 is less than 1 in 10^40 (or some other criteria that we agree is "safe"). Rather than mail these largish spreadsheets to the entire list, two sample graphs are at ftp://entropia.com/gimps/x1345000.xls and ftp://entropia.com/gimps/x136.xls (in the graphs a 400 on the X-axis is really a convolution error of 0.400, the Y-axis is a count of iterations). Any help is appreciated. Best regards, George P.S. A brief explanation of convolution errors: Since the FFT in prime95 is done in floating point arithmetic, round-off errors build up. After the FFT, every value is rounded back to an integer. The convolution error is the largest amount that a result value differs from the correct integer value. If the convolution error exceeds 0.5, then the round-back-to-integer step will round to the wrong integer value - a catastrophic failure. Another way to look at this: Each FFT value contains about 20 bits of data. That is, values ranging from 2^19 to -2^19. Consider an FFT of 128K elements. If each FFT value was close to the 2^19 value, then each result value would need 19+19+17=55 bits to hold the result. Since a float only holds 53 bits there would be a loss of information. Fortunately, probability assures us that it is extremely unlikely that every (or even most) FFT values will be close to the 2^19 maximum value. Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: LLL
Hi, At 12:15 AM 5/14/99 +0400, Alexey Khlyamkov wrote: I'am so sorry for this situation. No need to apologize Alexey. This is really a bug in mprime. My disk quota on the server was overfulled in that time and mprime running on several machines which connected to main server via NFS zeroed out some setting files such as local.ini and worktodo.ini. Prior to contacting the server, mprime calls the routine IniFileWritable, which should have returned FALSE and thereby avoiding contact with the server to get more work. I do not know why this routine failed - maybe it has something to do with NFS. I can't test an NFS setup, but I'll try debugging using a local disk. Best regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: New Mersenne Prime found!! Not yet verified
Hi all! The 38th Mersenne prime was *probably* discovered today. The exponent is in the 6,000,000s (the prime is in the neighborhood of 2,000,000 digits). The discoverer is a member of the top 200 contributors according to http://www.mersenne.org/top.htm As was agreed after the last prime was discovered, I'm announcing the news to this mailing list immediately. When the prime is properly verified and published, then I'll announce the exact exponent. This process was agreed to as a compromise in keeping everyone informed, yet minimizing any chance of the news prematurely leaking to the press. And now the bad news. Since the EFF award requires publication of the result in a refereed academic journal, the publication process will take longer than normal. It could be a few months. Tentative congratulations to all GIMPS members for their contribution in this exciting discovery!! Oh yeah, and special thanks to Scott Kurowski and entropia.com. We wouldn't have found this prime without his tireless Primenet server work. Now let's go find the 39th! Best regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: New Mersenne Prime found!! Not yet verified
Hi all, One more thing, thankfully this was not an exponent that was originally tested by the buggy version 17. Best regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Second LL
Hi all, At 03:26 PM 6/3/99 -0700, Aaron Schaufenbuel wrote: Congratulations to everyone from GIMPS on the new *probable* prime, especially George! Just wondering, can you tell us when the second LL test will be finished, I'm guessing that your running it on something alittle faster than a standard PIII? I've been in contact with Slowinski and Gage. Cray time is a little scarce right now. However, a volunteer has started the test today running at idle priority. It will probably take 4 weeks but could be less. Ernst Mayer has also begun a verification. It too will take about 4 weeks depending on what speed hardware he can get his hands on. Patience, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
RE: Mersenne: EFF and 10,000,000 digits
Hi all, At 02:33 PM 6/6/99 -0500, Amy and Shane Sanford wrote: My understanding of the purpose of rewards like the EFF is posting is to foster new and innovative ways to solve problems that almost seem impossible at the time. Absolutely. Otherwise, why offer a prize for a billion digit prime. Even though the Lucas-Lehmer test is virtually unchanged for the last hundred years. As recently 6 years ago, Crandall and Fagin published the details for doubling the speed of the test. Perhaps there are more theoretical or algorithmic improvements to come. (Anyone on this list working on that right now??) If asked 10 years ago who here would have thought we would be testing numbers as big as we have... George Scott's vision... Don't credit me with any great vision. I have repeatedly made boneheaded statements like "Our goal is to test all exponents below 1.3 million by the year 2000". Scott Kurowski and Luke Welsh have had much better vision. Best regards, George P.S. On the trolling issue: Don't worry about me - I have a thick skin. There is no reason to jump in to defend me. If you feel you must, please try to handle it by private email in the future. It has been a pleasure working with all the GIMPS participants. GIMPS memebers are a very pleasant and intelligent group to work with. P.P.S. And for Pete's sake, do NOT reply to this P.S. or P.P.S!! Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Prime 95 Error Messages/ Misc
Hi, At 04:39 PM 6/7/99 -0700, J. Williams wrote: Error: Illegal Sumout This error can be a hardware problem, but is very often caused by a faulty driver or program (usually related to the audio card). Is this anything I need to be concerned about and is there a listing of such messages? This error and the others are briefly discussed in the readme.txt file. Prime95 recovers from ILLEGAL SUMOUT ERRORs quite well, so there is little to be concerned about. If you get either of the other two errors, then almost certainly you have a hardware problem, and a cause for concern. Also, a while ago the program reserved about 20 numbers for testing (all the way into the year 2001) then it and released them a few minutes later. Is this normal operation? No. It is possible the program misguessed your CPU speed (say it thought you had a 2000 MHz Pentium), reserved a lot of exponents to keep you busy, and then when your actual progress was less than expected it returned the excess exponents. Any tips for optimization and usage? No, there really is little you can do other than remove screen savers and power save features that slow the CPU speed down. Finally, when and why does it communicate with the server (besides getting new numbers to test)? Every 28 days it checks in to let the server know you are still working on the number. It may also call in to let the server know of any changes in the expected completion date. Best regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Pentium Pro Optimization Help Needed
Hi all, I'm trying to optimize prime95 for the Pentium Pro/PII/PIII architecture. I'm fairly well versed in various execution units and latencies, but some mysteries remain. Are there any experts in this field - maybe even some Intel employees - that could improve the code further? Even one clock cycle in a macro that will be executed a few quintillion times is a big help. The new assemply macros are at ftp://entropia.com/gimps/lucas1p.mac for you to look at. Questions: Why is the code faster when I throw in some no-ops (actually fxch st(0) instructions)? How can I force the CPU to execute the floating point micro-ops in the optimal order? Does reordering the fstp instructions have any effect? Are there other issues I sould consider? Regards George - who is looking forward to IA-64 where I am in control of the opcode scheduling once again. Not to mention lots of registers! P.S.The clock timings were measured using the following loop. I can provide more details upon request. mov al, 0 mov ecx, 250; 1000 iterations clp1: disp four_complex_cpm_fft_3 8, 16, 32 ;;; or some other macro lea esi, [esi+64] add al, 256/4 jnc clp1 lea esi, [esi-256] dec ecx ; Check loop counter jnz clp1; Loop if necessary Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: status of exponents
Hi all, At 11:46 AM 6/13/99 -0500, several people wrote: The expiration policy is such-and-so... Prime95 reports in with new expected completion dates as well as next expected checkin date every N days where N is by default 28 days. Your exponents are reassigned if you miss your next expected checkin date by 60 days. However, prime95 version 15 used a different algorithm. The program reported an expected completion date when an exponent was reserved. The exponent expired 60 days after the expected completion date is missed. Exponents that are checked out by email do not follow a rigid formula. Generally, progress must be reported every 4 or 5 months and the range completed within a year. People I know such as Mr. Burge and Mr. Sunde are given more slack than a name I do not recognize. These exponents are usually recycled to people who cannot upgrade from version 14 or are using Macs (which work a lot better on exponents below 4.8M). Exponents above 5.2M are given to Primenet. The "problem" exponents that started this thread almost assuredly came from version 15 clients using the old expiration policy. Is "poaching" OK? No. There's nothing I can do about it, but I certainly do not encourage it. For the past two years it seems there has always been two or three people testing the lowest available exponents. I don't think they have improved their chances at all as they often report double-checks rather than first-time checks. Oh great, I reported a result and got "exponent already tested" error. Remember, you will get this error message when you retest an exponent that was originally tested by buggy version 17. It is very likely that you just completed the first CORRECT LL test. That said, accidents happen. A manual tester can enter the wrong range, an expired exponent can all of a sudden have its result reported, etc. The system will never be perfect, but fortunately works as expected 99% of the time. You should email the original person that reserved the exponent. Well, my policy is not to give out email addresses. I'm not upgrading because I think my old P-whatever should run first time checks. GIMPS does not mandate your computer do certain work. You can override the defult behavior in the Test/Primenet dialog box. Remember, you are here to have fun and if you don't mind waiting 6 months for an LL test, that's fine by me. Your checkin every 28 days will let the server know you are busy working on your exponent. (However, be reasonable. As this thread shows if you grab an exponent that will take 4 years to test, you can expect a "poacher" to finish it before you do. I would think one year completion time would be OK though). Why do we care that these smaller exponents get tested in a timely manner? The obvious answer is we want to make a relatively orderly determination on the primality of every Mersenne number. There is no sure-fire formula for detecting exponents that are no longer being worked on. Once in a great while, I analyze the database and find exponents that have "slipped through the cracks" or I think have been abandoned and release them for reassignment. I do *not* email the affected persons (I used to, but it was *way* too much work). The good news is that the current prime95 expiration policy seems to work very well. Thus, this problem should occur much less frequently in the future. Have fun, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Final (hopefully) comments on poaching
Hi all, 1) The problem is solved for all v16 and later clients. In other words it is 99% solved. Even if you check out a first time LL test on a P-75 the existing system will not time you out as long as you are running the program regularly. The Primenet status reports will show the world that you are indeed working diligently on your exponent. 2) The only good idea to come out of this thread is to allow users to send an I'm-still-working message in the manual web forms, along with a more generous initial timeout of 120 days. It is up to Scott to decide if he is willing to spend the time to implement this. 3) Other ideas for reassigning exponents that were assigned to v15 clients or by email included setting a firm policy, sending emails, waiting for responses, etc. etc. While a good idea it is more time-consuming for me. 4) M#37 was a recycled assignment. BTW, there are 9000 double-checks required before the ? is removed from M#37. 5) One of GIMPS greatest features is the lack of rigid rules. However, as this thread points out, this feature has a downside too. Since my time is limited and I've been entrusted by default with inventing GIMPS' official poaching rules, here it is: 1) Do not poach exponents. 2) I will apply the existing ad hoc policy for reassigning stale v15 exponents and email-reserved exponents. They will be recycled on an infrequent basis when I find the time. The server will then hand them out to random lucky users. I'm more aggresive with smaller exponents than larger exponents so that we will march steadily onwards. I'm more aggresive with people I don't know. If you reserved a range by email and report results every 5 months then you are safe. Have a nice day, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Linux VFAT question
Hi, Jan Scheller is having a problem (see below). Are there any Linux users that can provide help? Please include Jan in your reply as Jan is not subscribed to this mailing list. I've already recommended the "poor man's" solution of having mprime not write to disk every 30 minutes. Best regards George snip But the fact is that the performance of my mounted hdd win98 (vfat) partition is very low. All my normal linux (ext2) partitions work with normal performance. If I execute a command like `ls -l /Win98` (/Win98 is the path of may win98 (vfat) partition) it takes more than a second to get the result. The second points is, that the swapping seems to be slower than without running mprime. I run mprime every time at the lowest priority. Is there possibility to rise the performance of my vfat partition while running mprime? Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: LL Factoring DE Crediting
Hi all, At 09:59 PM 6/28/99 +0100, Gordon Spence wrote: if a factor is later found for a Mersenne number or the Lucas-Lehmer result is found to be incorrect, then you will "lose credit" for the time spent running the test." It is on www.mersenne.org/top.htm always struck me as odd I must admit. At the time the test was done it obviously WAS required, so why the subsequent penalty when we make advances and can factor much deeper? The explanation is really simple. It saves me from having to keep track of too much data (the bad results and the ones that a factor was later found). However, since the v17 bug, I've had to modify my procedures anyway and give credit for those incorrect results. I suppose it wouldn't be too hard to do the same for factors found and LL results proven incorrect. Regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Re: M#38 and a few questions
Hi all, At 04:02 PM 6/27/99 -0400, Jeff Woods wrote: Because of the EFF award money rules, we "GIMPS at large" will not be permitted to know what the exponent was, or who discovered it, until an article has been published in a peer-review academic research magazine or such. The EFF rules have been clarified such that if two claims are made on the $50,000 award, then the discovery date determines the winner. This gives us plenty of protection in announcing the new prime now. Scott gave out the press release today to the San Jose Mercury News and I should be emailing the list and updating my web pages soon. Note that sometimes these "human interest" type stories are held until the weekend for publication. I'd like to thank everyone for their patience while any kinks were worked out in the EFF claims process. They have never said we couldn't announce the new prime, but I've held off until we were sure it was risk-free to do so. Slowinski used to test huge numbers of primes...is he still doing that? David Slowinski is no longer working for Cray, so I doubt that he is still orchestrating an organized search. GIMPS does have one member who uses Slowinski and Gage's program and a Cray to look for primes. The latest prime is being verified by him. Paul Gage, who still does work for Cray, can then backup the new find. Regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: M38 = M6972593
Hi all, As the newspaper should announce the new prime on Monday or Tuesday, I've placed the info on the new prime at http://www.mersenne.org/prime.htm Congratulations to Nayan Hajratwala and all GIMPS members for our fourth success! Each Mersenne announcement is different. This time round I finally figured out how to get the press interested in the new number - tell them its a secret. The Oregonian was doing an article on Richard Crandall and when the found out there was a new prime and we wouldn't tell them what it was, their interest level went way up! I admire the resourcefulness of GIMPS members for going on a "scavenger hunt" and finding out the exponent a few days before this email was sent out. However the resourcefulness award must go to one enterprising GIMPS member that dug through all the cleared and assigned exponent lists and human-readable files and deduced the exponent in early June! (Note to Scott - create a dummy non-zero residue a stick it in the cleared exponents report). Good luck to all in the search for M39! Have fun, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: The $100,000 award for 10,000,000 digit prime
Hi all, At the risk of opening Pandora's box, I'd like to bring up the possibility of splitting up the $100,000 award for a 10 million digit prime. I'm soliciting everyone's opinion before making a decision. First off, it is by no means guaranteed that GIMPS will claim the award. Some have speculated that a search for Proth primes would have a better chance for success given equal computer power. Furthermore, version 19 will take over a year to test a single 10,000,000 digit number - so claiming the award is years away. However, a policy needs to be in place before version 19 is released. Secondly, I suspect splitting the award will require setting up a non-profit corporation. If I accept the award personally, I'd have to pay taxes -- no thanks. If there is anyone with useful insights on alternatives or how to set up and run a non-profit as cheaply as possible, please send me a private email. What follows is a possible list of beneficiaries along with a few reasons for or against: 1) A charity. There are several GIMPSers that are against any monetary awards. People should search for primes for love of math not the love of money. However, an all charity award could defeat the orinial donor's desire of encouraging advances in distributed computing. 2) Me. Some would argue that I share some of the credit for any Mersenne discoveries. Be aware that I will donate any share to charity. 3) Scott Kurowski. He has real expenses in running the PrimeNet server that should be reimbursed and has been instrumental in GIMPS' growth. 4) The discoverers of any Mersenne primes between now and the 10,000,000 digit discovery. This will encourage an orderly exploration of the exponents and keep up interest over the coming years. 5) The discoverer of the 10,000,000 digit prime. 6) Save some for Mersenne primes discovered after the 10,000,000 digit prime. This would be especially useful if the prime is discovered with lots of untested exponents below it. 7) Anyone that makes a mathematical or algorithmic breakthrough that speeds up the search process. I'm talking about a doubling in search speed not a 1% speedup in assembly code. Suggested rules for discussion on the mailing list: If you'd like to make a specific proposal (such as "all to charity" or "$50,000 for the 10,000,000 digit prime and $10,000 for all primes between now and then"), then send me PRIVATE email. Hopefully, I can form a consensus from these suggestions. Please use the mailing list for discussions on the benefits and drawbacks of the different choices. I can easily see this discussion getting out-of-hand with a corresponding increase in mailing list removal requests! Best regards, George Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: ROUND OFF error
Hi all, At 08:13 PM 7/20/99 -0700, Daniel Swanson wrote: Iteration: 6128000/7812379, ERROR: ROUND OFF (0.4026489258) 0.40 [Tue Jul 20 16:35:33 1999] Disregard last error. Result is reproducible and thus not a hardware problem. I consulted the readme file, but it wasn't very helpful. What is a "ROUND OFF" error? While it's nice that it's reproducible, will it invalidate the result of this LL test? Does the fact that this exponent (7812379) is so close to the FFT size breakpoint (782) make this type of error more likely? Yes, the fact that you are testing an exponent near the FFT size breakpoint makes this error much more likely. It will not invalidate the result of your LL test. Note that in version 19, I've decided to be a bit more conservative with the FFT breakpoints. Your exponent will be double-checked with a larger FFT size (if the double-checker uses v19). Regards, George P.S. Double-checking has not revealed any problems near the upper ranges of any FFT sizes. The more conservative FFT breakpoints will reduce the chance of an incorrect result due to an excessive convolution error. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Changes at mersenne.org
Hi all, You may have noticed that the web pages at mersenne.org haven't been updated recently. The reason is I've "lost" FTP access to update the pages. So, after several years at lushen.com, I'll be moving the web pages to entropia.com in the coming weeks. Be prepared for a few glitches as domain name servers are updated around the world. Many thanks to Marc Honey and lushen.com for hosting the site the past years and of course to Scott Kurowski for hosting it in the future. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: RE: Factoring more
Hi, At 09:05 AM 8/5/99 -0700, Eric Hahn wrote: I think as the time increases for each LL test, there would be much more time savings in attempting to do higher trial-factoring. In version 19, now being QA'ed, prime95 will factor as follows: Numbers above are factored to - --- 71002^72 57022^71 44152^70 35102^69 28132^68 21592^67 17852^66 13382^65 825 2^64 Note the new lower limit for 2^64 factoring. Previously, prime95 balanced the "chance of finding a factor" times "cost of factoring" against the "cost of one LL test". Prime95 now balances this against the cost of two LL tests. What's coming in version 20: 1) Optimized factoring above 2^64. The present factoring code is not optimized. This will lower factoring limits even further. 2) P-1 factoring. I already know that P-1 factoring will be beneficial for exponents above 10 million or so. This means there will be a new work type! I need to optimize the P-1 code further and implement a faster GCD. Extra credit: Can someone tell me the probability that P-1 factoring will find an n-bit factor? This is but one piece of the puzzle in determining the best trial factoring limits and P-1 bounds. To compute this probability the k in the 2kp+1 factor must be "smooth", that is all factors must be less than bound #1 except for one factor that must be less than bound #2. I'm sure I have the info around here somewhere, but everyone might be interested in the math behind deriving trial factoring limits and P-1 bounds. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Fermat factoring
Hi, At 12:17 AM 8/15/99 -0400, George Woltman wrote: So, is there a volunteer that would be willing to run stage 2 on their computer. I have a volunteer. Thanks, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Alpha DS20 timings.
Hi, At 01:37 PM 8/18/99 +1000, Simon Burge wrote: and for the 10^n digit fans: % ./MacLucasUNIX -C -S 10 33219281 speed: 10 iters in 4.634 seconds, 0.463 iters/sec (fft len 1024k) You can't test M33219281 with a 1024k FFT, you'll need a 2048k fft :( George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: New status page
Hi all, I uploaded a new status page to http://www.mersenne.org/status.htm The page now reflects version 19 timings and the status of exponents up to 79.3 million. If you were worried that GIMPS might one day run out of work to do, you'll notice there is now 48 million CPU years of work ahead of us :) Factoring will reduce this effort by about half, but double-checking is not included in that 48 million estimate. Also note that the stats at http://www.mersenne.org/top.htm now use the v19 timings as well. Thus, you will notice your P-90 CPU years has dropped. Since my P-90 no longer exists, my PII-400 has become the benchmark machine. If you average the v18 timings in the most popular FFT lengths, you'll find that my PII-400 equals 5.5 P-90s. The PrimeNet stats page is unaffected. It totals your CPU time as you contribute it using a different formula for each version of prime95. I expect a beta release of prime95 v19 to this mailing list later this week. General release will be a few weeks later. Best regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Several illegal sumout
Hi, At 05:17 PM 9/1/99 +0200, Dennis Jørgensen wrote: But in the test I'm running now I've had 4 of these errors (exponent just over 8 million). This seems a bit too much to me, am I right? Your result is likely OK. Prime95 recovers well from this error and it not usually an indicator that undetected errors are corrupting the results. The readme.txt file gives some ideas as to what the causes might be. I've noticed that they happen as the computer starts. This is new. The usual cause is a device driver playing a MIDI file. Probably a driver did not save the CPU state properly while initializing. With the 2 last errors I've also noticed that the tray icon appears later when the errors happen, Not unexpected. Prime95 sleeps for 5 minutes after a SUMOUT error. Celeron-400 gets 0.314 sec/interation on the exponent I'm running now, Seems right. Compare it to the PII-400 timings on http://www.mersenne.org/status.htm Remember that the timings on that page are for version 19 which is up to 10% faster than version 18. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Prime95 version 19 - better late than never
Hi all, Sorry for the delay in releasing v19. It is now available for mersenne mailing list members to beta test. If all goes well, it will be officially released to all GIMPSers in a few weeks. You can get the new version at ftp://entropia.com/gimps/p95b.zip To upgrade prime95, stop and exit the current version. Optionally make a backup of the directory containing prime95. Unzip the new version on top of the old version. Start the new prime95. Next time you contact the server, it will broadcast a welcome message to you. Let me know if there are any problems with this new feature. The message will be deleted prior to the final release of v19. This feature gives us an effective way to inform you of new versions and important bugs or news. Save files are upward compatible from previous versions, but not backward compatible. Thus, do not try this beta if you are in a dual-boot environment. The Linux and NT service versions will be available soon. I'd like to thank the excellent work of the QA team. They located many bugs, bringing you a higher quality beta. The QA team included Ken Kriesel, Brian Beesley, Tom Cage, Jean-Yves Canart, Bryan Fullerton, Marc Getty, Steinar H. Gunderson, Eric Hahn, Alex Healy, Paul Landon, Greg McIntyre, Lawrence Murray, Paul Victor Novarese, Ethan M. O'Connor, Rick Pali, Shane Sanford, Brian Schroeder, Gordon Spence, Joth Tupper, Guillermo Ballester Valor, David Willmore, and Lucas Wiman. And, of course, thanks to Scott Kurowski for his v19 enhancements to the Primenet server. Here is the relevant excerpt from whatsnew.txt: 1) Faster - in some cases as much as 10% faster!. The FFTs were recoded for improved memory and TLB efficiency. Furthermore, optimizations specific to the Pentium Pro and later processors were added. 2) New FFT lengths. The program can now test exponents as large as 79.3 million. Also, smaller FFT lengths are supported for use in ECM and P-1 factoring. 3) More conservative FFT breakpoints. This could actually result in some exponents being slower to test in this version. However, the chance of a fatal rounding error has been reduced. 4) P-1 factoring has been added. Although it is not very practical for large exponents because of a slow GCD routine, it can be used to find new factors of exponents below a few million or so. 5) ECM can now run on large exponents. Once again, the slow GCD routine and high memory requirements might make this impractical for large exponents. 6) ECM and P-1 factoring now support save files. Very handy on lengthy runs. 7) ECM and P-1 factoring lets you specify the amount of memory to use. In some cases, more memory can improve execution speed slightly. 8) A bug in guessing the CPU speed on initial install has been fixed. 9) The preferences dialog now has an option to pause prime95 when a laptop is running on its battery. 10) Error checking has been improved slightly. 11) Factoring is now "layered". That is, prime95 now factors to 2^52, then 2^53, 2^54, and so forth up to the appropriate limit. The factoring output lines have been changed to show percent complete in the current "layer". 12) A bug in running two or more self or torture tests in the same directory has been fixed. 13) Trial factoring above 2^64 is now supported. 14) More trial factoring is now done to take into account the cost of double-checking. 15) Title now contains percent complete when LL testing. By default, the percent complete value is now displayed to 2 decimal places. You can change this by setting PercentPrecision in prime.ini to a value between 0 and 6. 16) Affinity and service name settings moved from prime.ini to local.ini file. Prime95 will automatically move these settings for you. 17) An option to get only 10,000,000 digit numbers to run primality tests on has been added to the Test/Primenet dialog box. See http://www.mersenne.org/prize.htm for rules on claiming the EFF award for finding a 10,000,000 digit prime. 18) The Advanced/Clear primes menu choice has been deleted. 19) The prime95 icon turns yellow when the program is idle. After an error such as ILLEGAL SUMOUT, the icon will blink for 10 seconds. 20) The User Information dialog box allows you to request newsletters and form a team user ID where the team members cannot alter the team name. 21) A bug in the reporting of error counts in the results.txt file has been fixed. 22) The server can now broadcast important messages to the prime95 client. Prime95 will blink the icon until prime95 is activated and then it will display the message. Finally, here is the timings table from my PII-400: V18 timing V19 timing old P-90 timings -- -- 80K 0.038 0.036 96K 0.047 0.0445 0.272 112K0.058 0.0548 0.332 128K0.0645
Mersenne: Re: Factoring in version 19
Hi, At 09:43 PM 9/9/99 -0400, Matthew Smith wrote: I love the new beta. It's much faster and accomodates my PIII. But why is it factoring my most recently assigned number, and not the one I was working on before I upgraded? That's normal. The new version does more factoring than the old version. It is factoring the second number so that if it does have a factor it can get you a new exponent to test and keep your "days of work queued up" greater than 10. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Test/Status in version 19
Hi all, One more thing. The timings in prime95 have been recalibrated to my PII-400 instead of my old, deceased P-90. What does that mean? The short explanation is that you should not believe the estimates given in Test/Status. Over time these estimates will become accurate again. Why is this? When version 18 estimated my PII-400's speed it underestimated by 40%. Over time, the RollingAverage value in local.ini grew to 1400 to compensate for the poor guess and give accurate estimates in Test/Status. Well in version 19, prime95 accurately guesses my PII-400's speed and applying the rolling average of 1400 makes it bring in the expected completion dates by 40%. It won't take too long for the rolling average to come down to close to 1000 -- or you can edit your local.ini file my hand and set the RollingAverage to 1000. I hope that wasn't too confusing... Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Big problem with Prime95 version 19
Hi, At 10:18 AM 9/10/99 +0100, Michael Oates wrote: Sending expected completion date for M7657963: Sep 11 1999 Getting exponents from server Sending expected completion date for M7666349: Sep 11 1999 The new version is fast - but not that fast! I've fixed a bug that occured sometimes when the first line in the worktodo.ini file is a "Factor=" line. To those affected, download version 19 again and see if it doesn't return those excess exponents at some point. Let me know by private email if that did not fix the problem. Hope that helps, George BTW, the QA group concentrated on the math code not the client and server interaction. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: error in V19??!?
Hi John, At 11:08 AM 9/11/99 -0700, John R Pierce wrote: Iteration: 6742784/7817869, ERROR: ROUND OFF (0.4086303711) 0.40 Possible hardware failure, consult the readme file. Continuing from last save file. [Sat Sep 11 11:04:20 1999] Disregard last error. Result is reproducible and thus not a hardware problem. Iteration: 6742912/7817869, ERROR: ROUND OFF (0.4086303711) 0.40 Possible hardware failure, consult the readme file. Continuing from last save file. This is not a bug. Brian was right that v19 would ordinarily use a 448K FFT wheras v18 used a 384K FFT. However, v19 is finishing off your exponent using a 384K FFT. You now see why I was a little more conservative with the FFT crossover points. Your 0.4086 error is not much greater than 0.4 and not near the 0.5 error that would corrupt your result. I'd continue onward with your test - you probably would have gotten the same error in version 18. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Possible bug in v19 beta ECM?
Hi, At 02:00 PM 9/15/99 +0300, Jukka Santala wrote: I played with ECM-factoring some smaller exponents, and noted that altough worktodo.ini isn't changed, the curve-count displayed by the program is right, and advances as should. So it seems the "finished curves" count is saved in the intermediary savefiles. Your conclusion is correct. The curves completed count in the worktodo.ini is no longer used (except for backward compatibility). The count of curves completed is maintained in the save files. I have updated the readme.txt file and whatsnew.txt files accordingly. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Iters between screen outputs
Hi, At 10:29 PM 9/15/99 +0200, Shot wrote: I was wondering why the "Iterations between screen outputs" setting was defaultly set on 100, and I thought it was beacuse each screen output takes precious CPU time. But when I changed it from 100 i/o (usually around 0.430 sec/iter) to 10 i/o, nothing really slowed down - the time was still between 0.430 and 0.431 s/i. The timings do not include the cost of writing to the screen. To see if lowering this value is slowing you down you will have to use a stopwatch rather than relying on the value printed on the screen. BTW, the default was set at 100 because the first version of the program was in Windows 3.1 and the overhead was significant. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: primes source
Hi, At 03:01 PM 9/18/99 -0400, Darxus wrote: I've just switched to the GIMPS. Welcome aboard. I have a question though. Why make the Linux source dependant on code which needs to be assembled under DOS, when there is an assembler for Linux (as) ? There is a ton of assembly source code. Converting it from one syntax to another would be a great deal of work - and possibly error prone. As of two years ago there was not a tool to do the conversion automatically. Also, the source seems to be released something like "feel free to use this code to make the world a better place as you see fit", but doesn't actually have a license. I would incourage you to release it under either the GNU General Public License (http://www.gnu.org/copyleft/gpl.html), or if you want to allow commercial use, the BSD license (which I'm significantly less familiar with). I may look into changing this when the v19 sources are released. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Expected completion date
Hi, At 12:33 PM 9/20/99 +0200, Shot wrote: At 8178600th iteration I checked the status window, and it showed that Prime95 will be working on this for the next 5 hrs 25 mins... So, it seemed like 10 mins 10 secs later I will be given the naked truth about M8180017. That's like 5 hrs 14 mins 50 secs earlier than Prime95 thought... Prime95 updates this information on a program restart (as you found out) and every 65536 iterations. I've fixed it to update this every 128 iterations. The 18 vs. 24 hours a day info will cause the estimate to be off by 25% as prime95 assumes the 6 off hours are distributed uniformly throughout the day. Keep those bug reports coming, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Prime95 v19 oops...
Hi, At 10:09 PM 9/20/99 +0300, Jukka Santala wrote: Something I forgot from earlier playing, the manual factoring savefiles on Prime95 v19 at least don't work out too well especially on dual-CPU machines... Since these savefiles will always be named "p000" regardless of the -A parameter and exponent to test ;) This is a v18 bug that I declined to fix. Maybe I should delete that Advanced/Factor menu choice :) To work around this create one directory for each CPU. This is the only known flaw in dual-CPU environments. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: v19 manual workdodo.ini error.
Hi, At 02:42 PM 9/18/99 +0200, Lars Lindley wrote: I discovered a lost exponent in the team-report and thought I would reassign that exponent for myself. I manually edited the worktodo.ini by adding the row DoubleCheck=3393469,61 on the first line. I thought that prime95 would put the exponent I was working on on hold to do the doublecheck first as v18.1 would have. To my surprise it continued with the old exponent. I've tracked down and fixed this bug that Lars and Rick reported. Look for a new v19 beta in the next day or two (I'll announce it to the mailing list). Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Version 19 - beta #3
Hi all, Thanks to everyone for the thorough testing of v19. I've fixed several bugs mainly dealing with worktodo.ini and expected completions dates. Only one "serious" bug was found - creating the half-hourly P-1 save files would sometimes lead to ILLEGAL SUMOUT errors. The new prime95 beta can be downloaded at: ftp://entropia.com/gimps/p95b.zip The linux beta dynamicly linked with glibc 2.1 is at: ftp://entropia.com/gimps/mprb.tgz The linux beta staticly linked is at: ftp://entropia.com/gimps/sprb.tgz For the really brave, the completely untested Windows NT service version is at: ftp://entropia.com/gimps/ntb.zip Two new items: 1) Mprime and ntprime now support a -c command line argument to contact the primenet server and exit. 2) The file undoc.txt describes all the previously undocumented features of prime95. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Oops - Version 19 - beta #4
Hi all, If you downloaded beta #3 this morning please download beta #4. Beta #3 likes to repeatedly send expected completion dates. The prime95 beta can be downloaded at: ftp://entropia.com/gimps/p95b.zip The linux beta dynamicly linked with glibc 2.1 is at: ftp://entropia.com/gimps/mprb.tgz The linux beta staticly linked is at: ftp://entropia.com/gimps/sprb.tgz For the really brave, the completely untested Windows NT service version is at: ftp://entropia.com/gimps/ntb.zip Sorry for the trouble, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Oops again - Version 19 - beta #4
Hi all, Only Linux users are affected. Apparently I suffered floppy confusion or other operator error in rebuilding beta #4 for linux. The corrected beta #4 for linux is now available. The linux beta dynamicly linked with glibc 2.1 is at: ftp://entropia.com/gimps/mprb.tgz The linux beta staticly linked is at: ftp://entropia.com/gimps/sprb.tgz Sorry for the trouble, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: V19 source code
Hi, At 05:27 PM 9/23/99 +0100, Chris Jefferson wrote: Where can I get the most recent Prime95 source code from? I've just uploaded the v19 source code. You can download it from http://www.mersenne.org/source.htm The only restriction I've placed on the code is that if you use it to find Mersenne primes, you must adhere to the GIMPS prize rules at http://www.mersenne.org/prize.htm The v19 code is much more usable in other math projects. It would be interesting to see if it could be adapted to Proth prime searching (and whether it is enough faster to be worth the effort) or some other new number theory projects. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: mprime V19--correct behavior or glitch?
Hi, At 03:56 PM 9/27/99 -0400, St. Dee wrote: I have all of my machines set to get 45 days worth of work. Two of the machines, which were nearly down to having only 45 days worth of work remaining, immediately contacted PrimeNet, got an additional exponent each, and factored that exponent to 64. This morning I awoke to find that each machine contacted PrimeNet overnight and unreserved the newly factored exponent, leaving each machine with about 40 days of work remaining. Why is this? A bug. I thought the code was doing this: If all prior entries in worktodo.ini was more than 45 + 30 days then the exponent is returned. The "+30" is to avoid just what you are observing - frequent getting and releasing of exponents as the "rolling average" fluctuates. This is a lot like a thermostat where the heat comes on at 69 and off at 71 when you set the desired temperature to 70. The code was actually releasing the exponent if the prior exponents exceeded 45 days and the prior exponents plus this exponent exceeded 45 + 30 days. Now that it is common for exponents to take longer than 30 days, the bug has surfaced. I shall fix the bug. Keep up the good work, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Version 19 - release candidate #1
Hi all, At Scott's request, a computer ID is now required (one will be assigned if you don't specify one). The RdtscTiming undocumented feature has been made available plus some minor bug fixes. The math code is unchanged. I'll post the updated source code shortly. There is one report that the NT service version crashes in Windows 2000. Have there been any success stories in this environment or is this an isolated incident? Please respond by private email. Prime95 can be downloaded at: ftp://entropia.com/gimps/p95b.zip The linux beta dynamicly linked with glibc 2.1 is at: ftp://entropia.com/gimps/mprb.tgz The linux beta staticly linked is at: ftp://entropia.com/gimps/sprb.tgz The Windows NT service version is at: ftp://entropia.com/gimps/ntb.zip Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Mersenne cryptography (was: Purpose...)
Hi, At 04:15 PM 10/1/99 -0600, Aaron Blosser wrote: Hmm...no kidding. Now, correct me if I'm wrong (I probably am) but aren't those types of encryption schemes based on multiplying large primes together to generate the "key", Richard Crandall's method is not based on multiplying primes together where the message is hard to crack because factoring is difficult. Instead, his method uses eliptic curve algebra and is "safe" because finding discrete logarithms are difficult to find. The method is patented. I'm under NDA so even if I understood it at all, I can't tell you any more. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Factoring data
Hi all, At several users request I've uploaded factoring data for all exponents below 79,300,000. You'll need a special decompression program I wrote. See http://www.mersenne.org/status.htm for details. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Mprime Error 2250
Hi all, This info was reported to me. As a Linux-newbie I have no idea if it will prove helpful to others. I've just done a bit of browsing with `strace' on my machine here at work, at it's looking like a configuration issue. Running `strace' on either mprime 19 or the glibc2-linked mprime 18 reveals a slight difference in hostname lookups compared with the original libc5-linked mprime 18. The newer versions consult /etc/nsswitch.conf (exactly as expected since this was one of the changes with glibc2), while the older version consults /etc/host.conf. (I just verified that glibc2 falls thru to use /etc/host.conf if /etc/nsswitch.conf doesn't exist.) The problem on this system is that /etc/host.conf was specifying "order hosts" instead of "order hosts,bind". Making the change now allows the older mprime to contact the Primenet server. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: V19 Bug in Factoring Timing?
Hi, At 01:24 PM 10/10/99 -0400, Walt Mankowski wrote: I just upgraded this morning to the latest Linux version of Linux, v19.0.2. The box with the problem is a 486-66 running Red Hat 5.0. I'm noticing some strange numbers in its output: Factoring M10533203 to 2^64 is 39.84% complete. 310.630 sec. Factoring M10533203 to 2^64 is 39.85% complete. -3984.147 sec. I have a fix for this. Look for it in version 19.1 - no release date yet. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: pre-LL factoring
Hi, At 06:47 AM 10/15/99 +0200, Shot wrote: The question is: why didn't Prime95 factor the older one from 63 to 64? No good reason. The program doesn't do any trial factoring once an LL test has begun. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: AMD K6 and Athlon
Hi, At 02:22 AM 10/17/99 +0200, Steinar H. Gunderson wrote: On Sat, Oct 16, 1999 at 03:47:42PM -0400, Jud McCranie wrote: I tried version 19 on a PII and a Celeron, and in both cases it thought they were P-Pros. It got the MHz correct. Were these upgraded, or fresh installs? The GIMPS software (still no collective name for Prime95/Saver95/mprime/ntprime?) won't try a redetection if there already is a CPU type entry available. Prime95 does not detect Celerons very well. However, if a PIII, PII or Celeron is detected as a Pentium Pro - its no big deal. All those CPU types use the same code. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Milestone!
Hi all, At 07:07 PM 10/18/99 +0200, Wojciech Florek wrote: I was observing the progress in the last 10 exponents below 2M. Almost all had been assigned to diamonddave and almost all have been finished on schedule ... You missed one important step - the residues must match! I checked the cleared exponent report against the 3 remaining exponents below 2M. They have been completed and the residues match! The milestone was reached on October 16, at 12:09 UTC. Congratulations to all. Onwards and upwards, George P.S. It looks like diamonddave is working on an unneeded triple-check. Oh well, these things happen. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: difference between LL and double check
Hi, At 05:19 AM 10/25/99 +0200, Robert van der Peijl wrote: Why is there a difference in iteration time between the LL test and a double test. There isn't - other than double-checking is working on smaller exponents. For the same FFT-size, the double checking code has to perform a bit extra work per iteration: it multiplies by 2 before the DWT, and divides by 4 afterward. This isn't quite how double-checking works. What happens is the initial Lucas value, 4, is shifted left a random number of bits. We remember this shift count in the variable called units_bit. Each iteration does a squaring, then computes the new location of the units bit (old_units_bit * 2 modulo exponent_being_tested). Now that we know where the units bit is, it is easy to subtract two. This has the same property of having the FFT deal with different data, but without the cost of a multiply by 2 and divide by 4 on every iteration. BTW, the above is done on first-time tests too. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Error 2250 using Linux mprime
Hi all, This was just reported to me. Others may find it useful. Regards, George I took the liberty of looking at this. It appears that even w/ "gcc -static", the new glibc name resolution stuff contains explicit uses of several dynamic libraries. If these libraries aren't present, gethostbyname(3) will silently fail, yielding the 2250 errors. There's a discussion of this in the usenet archives at: http://x35.deja.com/getdoc.xp?AN=414019916CONTEXT=940892973.188547100hitnu m=0 I worked around this by moving the following .so's to my bootdisk for my ips machines: libc.so.6 ld-linux.so.2 libnss_dns.so.2 libresolv.so.2 This may not be ideal for everyone. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: fast GCD
Hi, At 04:07 PM 11/6/99 EST, [EMAIL PROTECTED] wrote: Was your code doing a true Fermat-mod DWT, or were you attempting to factor instead the Mersenne number M(2^25-1) = (2^(2^24)-1)*(2^(2^24)+1)? Prime95 uses a true Fermat-mod DWT. Impressive - can you give us a brief summary of the most time-impacting changes you made, and were these to the C source or in ASM? There were a few things in giants that were not done efficiently. For example, dividing one huge number by another was done using reciprocals and then multiplying. Well, 99.9% of the time in a GCD the quotient will be less than 2^32 and can be derived by one floating point divide on just the high order bits. It was also a bit of a memory hog. I also upgraded giants from 16-bit to 32-bit, made use of some ASM helper routines, cleaned up memory management, etc. The changes I've made have been forwarded to Dr. Crandall for possible incorporation into a future release of giants. BTW, I know of no other publicly available implemetation of the fast GCD. It was written by J. P. Buhler. I know little about it, except that Crandall mentioned it took them the better part of 6 months to get the thing written and debugged. Better them than you, right? :) Absolutely! And it is quite elegant. You should be able to incorporate it into your code with little trouble. I had little trouble upgrading it to do modular inverses too. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Linux error 2250 solved
Hi all, Mprime version 19.1 is now available. The only new feature of any consequence is a solution to the error 2250 some users of the staticly linked mprime suffered. The whatsnew.txt file describes the line you need to put in primenet.ini. You must create the primenet.ini file. Many thanks to all that helped narrow the problem down to a difference in the way gethostbyname call worked in different versions of the OS. Regards, George P.S. P-1 factorers - do not use the Stage1GCD undocumented feature. It may have a bug. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: high factoring bug in prime95
Hi all, This is primarily directed at the 4 or 5 users dedicated to factoring exponents above 35 million. Prime95 version 19.1 has a bug that causes it to miss some factors for these large exponents. If you are one of the 4 or 5 affected users, please download version 19.2 to fix the problem. Thanks to Will Edgington for finding the test cases. The bug was discovered because values in the "expected number of Mersenne primes" column on the http://www.mersenne.org/status.htm page kept going up! Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Prime search on SMP Linux
Hi Sandy, At 11:41 AM 1/3/00 -0500, Sandy Harris wrote: I'd like to run one copy of the search code in such a way that it monopolises one CPU, in hopes it will succeed relatively quickly. Is there a way to do that? Yes. Run mprime -m and choose Advanced/Priority. Enter a value of 9 instead of the default value of 1. Now let me explain why you don't want to do that. Assume the other tasks you run every day require 1000 CPU seconds. No matter what priority you run mprime at there are only 2*86400 - 1000 CPU seconds available. Raising mprime's priority will slow down the other tasks but not improve mprime's throughput at all. I'm assuming here that there's no multi-threading in the search code, that it would not be useful to try and run one search using both CPUs. Is that accurate? You are correct. Run one mprime with no arguments and run the second mprime with the "-A1" argument. Hope that helps, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: cpu years/day vs GFlops/sec
Hi, At 06:50 PM 1/6/00 EST, [EMAIL PROTECTED] wrote: Spike Jones wrote: Processor gurus, please: using the equivalence that is suggested by the primenet status page [86.6 P90 CPU yr/day = 1042 GFlops] I calculate that a floating point operation must be about 3 CPU cycles. Indeed, I calculate ~0.4 FLOP/cycle, which at first glance seems about a factor of 2 too slow, even on the humble P90 (which should, assuming no cache misses, be able to dispatch one FADD per cycle and (I believe - x86 experts, please correct me if I'm wrong) one FMUL every other cycle, for a peak throughput of 1.5 FLOP/cycle. The humble P90 can only do one FADD *OR* FMUL per cycle. Thus, maximum throughput is 1.0 FLOP/cycle. Worse yet a floating point load takes one clock and a store takes two clocks. With only 8 registers there are a lot of loads and stores. The PPro, P-II, P-III, and Celeron have a better architecture that allows loads and stores to run in parallel with the FADDs and FMULs. This makes it easier to approach the 1.0 FLOP/cycle theoretical maximum. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: New Prime95 Setup Program
Happy new year to everyone, Thanks to Wise Solution's generous donation of their InstallMaker program, http://www.wisesolutions.com, and Geoffrey Faivre-Malloy's programming efforts, Prime95 now has a fancy setup program! There is no need to upgrade (prime95.exe did not change), but if you are curious you can download it from http://www.mersenne.org/freesoft.htm Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Why 2K?
At 03:48 PM 1/12/00 EST, Ernst wrote: From a programming perspective, my own top "why 2K" question is this this: even given that the person(s) who first used a mere 2 characters to store the year had good reason (e.g. severely limited computer memory) to do so, why didn't they use those 2 precious bytes as a 2-byte integer? I think its due to punched cards. Reading and writing 2 digit dates on the punched card makes using PIC 99 COMPUTATIONAL inappropriate. Regards George P.S. Yes I'm old enough to have used punch cards. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Best chance to make a real contribution?
Hi Gerry, At 11:35 AM 1/22/00 -0800, Gerry Snyder wrote: First of all, let me say that it is a thrill to be helping in the GIMPS. Welcome aboard! Getting more computing power for the search is the main reason my new linux system is a dual Celeron rather than a single. The second processor is a cheap way to add horsepower. It will help on many other computing tasks. An excellent decision. But finding a factor (or another factor) of a Mersenne number would seem more real. Finding new factors isn't hard. Over half of the candidates are eliminated by finding a factor rather than the expensive LL test. GIMPS by default assigns slower machines to do the factoring work. Thus, it is not uncommon for powerful machines to always get LL assignments and never find a factor. If you want the thrill of finding a factor, ask one of your CPUs to get factoring work only (the Test/Primenet dialog box). You can change this setting back at a later time. Finding new factors of small Mersennes, so called Cunningham factors, is getting more difficult. ECMNet and GIMPS have picked off most of the "easy" factors. I have two CPUs running ECM full-time. The last Cunningham factor I found was last summer. I do occasionally find new factors of medium-sized (1200 to 10) Mersenne numbers. In any event, choose the type of work you find most interesting. The goal here is to have fun while contributing to math research. Best regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Odds on finding a factor ?
Hi, At 02:28 PM 1/23/00 -, Alex Phillips wrote: I've factored five numbers, all in the 1165-1166 range, as allocated by Primenet, without finding a factor. So my question is, What are the odds on finding a factor ? Since these exponents are already factored to 2^52 and you will be factoring to 2^64, your chance of NOT finding a factor is about 52/64. Thus, your chance of finding a factor is about 1 in 5.3. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Round off error = 0.5
Hi, At 01:04 AM 1/25/00 +0100, Dieter Schmitt wrote: I'm running Prime95 on a PII-400 for 6 days (no overclocking) at exponent 9409271. It's produced several outputs concerning ROUND OFF ERRORS - the last one is ROUND OFF [0.5] 0.4 What to do now? Restart from iteration 1? The first thing to do is try and figure out if your CPU is overheating or you have some flaky memory chips. You almost certainly have a hardware problem of some type. Prime95 will go back to the last good save file after the error. So there is a chance your result is OK. The question is "did a hardware error go undetected?" I have little hard data on this, but I'd guess several errors of this type mean you have less than a 50-50 chance of producing a good result. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Results of version 20 memory questions
Hi everyone, Thanks to all that replied to my earlier email. Here I'll summarize, in no particular order, the important points in the replies It seems the majority of responders feel the prudent decision is for prime95 to use the minimum amount of memory by default. I will have prime95 default to 8MB of memory in the Options/CPU dialog box. If the user leaves this value unchanged I'll pop up a message box explaining why he might want to increase the value. I should also display this message when a user upgrades from v19 to v20. No one suggested a sure-fire method for making sure prime95 is not causing thrashing. Some did suggest Windows calls that will yield useful data - but were vague on how these statistics are to be interpreted. I imagine there isn't a single solution that will satisfy every users setup and thus it is best for prime95 to let the end-user make the decision for his machine. Stage 1 of P-1 stage 1 uses the same amount of memory as a LL test. Thus, even those users that do not give prime95 more memory to work with will do a little P-1 factoring. For example, exponent 10,000,139 P-1 will go to B1=13 with a 2.02% chance of finding a factor (cost is 1.87% of an LL test). If given 48MB of memory, prime95 uses B1=11 and B2=1815000 with a 4.15% chance of finding a factor (cost is 3.17% of an LL test). If you give prime95 48MB of memory but only from 11PM to 7AM, then if stage 2 needs to run between 7AM and 11PM prime95 will instead begin work on the next item in the worktodo.ini file or begin the LL test on the assumption you are unlikely to find a factor anyway. P-1 factoring will be a separate work assignment when Scott has the time to make the necessary changes on the PrimeNet server. The initial release of version 20 will probably not have separate assignments. Some suggested prime95 grow and shrink memory usage based on paging rates, etc. Apparently, I did not explain the stage 2 requirements very well. Before embarking on stage 2, prime95 needs to know how much memory it can use. Once stage 2 has begun, prime95 cannot grow or shrink its memory consumption. Best regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Strange result line inprime V19.2
Hi, At 05:11 PM 2/8/00 +0100, Grieken, Paul van wrote: Some days ago prime V19.2 finished an exponent, the line looks like UID: grieken/C8B74DDA1, M7563337 is not prime. Res64: CBE45D3443C7D394. WV1: 9BE40783,5609919,8000 I have two questions: 1. what is the number behind my UID, never seen in other lines The C8B74DDA1 is a randomly generated computer ID. Very handy for users with a large number of machines. 2. What means the last number, the one that begins with an 8. thanks for any reaction The 8 means that this exponent was started with a previous version of prime95. The 7 zeroes indicate that no errors were detected during the LL test. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: non-synchronized old results
Hi, At 09:20 AM 2/10/00 -0500, Stephan Grupp wrote: I missed the answer in the digest to the question regarding old results that are left in your Primenet account after a synchronization. I, too, have wondered about these accumlating old results (although I just checked my Account Report and they all have miraculously disappeared). Are those "legacy" exponents counted in your P90 years? Had they been (NOT to reopen this thread) poached or reassigned in some other way? This will take a little explaining A database merge is done using the binary database format that only the old-time GIMPSers remember. The Primenet server removes results from the cleared exponents report if the exponent is no longer in the binary database. Unfortunately this algorithm has a flaw. The exponent may still be in the binary database - only now it is marked for double-checking. So even though you properly did a first-time check, the exponent is still in the database, and your line still appears in the cleared exponents report. At present the binary database has data on all exponents below 7 million that need double-checking. In the past it had been 5 million, so not all result lines between 5 million and 7 million were saved. Furthermore, buggy v17 results hung around for quite a while because the exponent was not removed from the binary database for obvious reasons. Now, why did these old lines recently disappear? That's a completely different issue! The prime95 client sends two result messages to the server for every LL test. One is an easy to use C structure that the server uses to update its databases. The other is a text message (identical to the results.txt line) that I download once a week and update my database. Once in a great while I plow through the cleared exponents report and see if the primenet server database has results that I am missing (there were 5 since last May). I've emailed the 5 users in hopes of getting them to email the results.txt file to me. I also told Scott to purge the cleared exponents report of all results sent in prior to Feb 1, 2000. Obviously this isn't the cleanest way for Scott and I to maintain our databases. It developed this way partly for historical reasons and partly due to constraints on our free time. Best regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: p-1 and trial factoring
Hi, At 03:23 PM 2/25/00 +0100, Reto Keiser wrote: parallel use of p-1 and trial factoring --- Why can't we do first first the factorization up to n-2 bits (1/4) of the trial factoring time, then start the P-1 factoring up to 1/3 of the B1 value, after this, we can complete the trial factoring process and at the end we complete the P-1 (using the save file od intermediate file). (the parameters can be optimized) I can't see any flaws in your reasoning, although it would be a bit unwieldy to implement. no 68 bit factors - until now 210 factors are found for 10megadiginumbers and more than 280 exponents were factored up to 68 bits. Some (about 7) 67 digit factors were found but none with 68 bits. My database has: 3321966173867482830512390441 3322338783006905661336745889 33221387123317319076102495049 33235409128314644111933147703 33238463131707491089550166169 33230671139408728702078150121 33224957193425473534465274127 That's 6 67-bit factors and 1 68-bit factor. Not the expected distribution, but nothing to be concerned about yet either. organization of p-1 factoring - A lot of factors of exponents between 1 and 100 were found using the new P-1 method. Is there a database which contains which exponent were tested using which B1 and maybe a database od the save files? All exponents from 2 to 11 were done with B1=1M and B2=40M Exponents from 11 to 60 (still in progress) were done with B1=100K and B2=4M. I still have the save files for exponents below 11. I think Alex has the save files for the larger exponents. However, it must be pointed out that at some point you are better off switching to ECM rather than expanding the P-1 bounds. I'm not sure what that point is. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Chance of P-1 factor
Hi, At 02:21 PM 1/31/00 +, Alexander Kruppa wrote: I started with: The chance of a number N being B-smooth is (log(B)/log(N))^(log(N)/log(B)) . I don't think this is correct. Look up Dickman's function in Knuth vol 2 pages 382 and 383. You can also look at a July 10, 1996 post to this mailing list from Peter-Lawrence Montgomery. I've been grappling with this same problem in prime95 version 20. I'll let you independently implement it and see if out results agree! Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Version 20 memory questions
Hi all, I'm working on prime95 version 20. The important new feature is a P-1 factoring step prior to a Lucas-Lehmer test. The P-1 factoring step has a 3-5% chance of finding a factor at a cost of 2-4% of an LL test. The net effect is we speed up GIMPS' throughput by a percent or two (more if you factor in the fact that a double-check is avoided too). Stage 2 of P-1 factoring requires more memory than an LL test. The more memory you give the program the faster stage 2 executes. For example, an exponent around 10 million requires about 4MB of data. P-1 stage 2 would like to have 48MB, but can get by with as little as 24MB. The good news is that the LL test takes a month, P-1 factoring takes a day, and the memory hungry stage 2 takes only half a day. GIMPS has always had a good reputation for not interfering with your normal work. To preserve GIMPS' reputation, I'm thinking of implementing the following. In the Options/CPU dialog, prime95 will let you select the maximum amount of memory the program can use and the hours of the day it can use it. The default would be 80% of RAM (divided by the number of CPUs) during nighttime hours only. Finally, the questions: Would we be better off disabling P-1 factoring unless the user explicitly activates it (knowing that most users won't read enough to turn it on)? Are there better solutions? It would be nice if prime95 could detect that memory thrashing was happening and pause itself until more memory was available. Can Windows programs do this? Are the defaults too aggressive (especially the 80% of RAM)? You can send your comments and suggestions to me privately or to the entire mailing list. Having fun, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Fill my mailbox
Hi all, The Mersenne benchmark page is badly out of date. I'm going to create a new page and I need data (Intel-compatible CPUs only). Please send ONLY VERSION 19 TIMINGS. Please email to me, NOT THE ENTIRE MAILING LIST, the following data (if unsure of a value that's OK). Email the entire mailing list if you want to discuss which data is collected. CPU type: Pentium, PPro, P-II, P-III, Xeon, Celeron, K6, Athlon, etc. For coppermine, note the E or B designator if you know it CPU Speed: in megahertz L2 cache size: in KB L2 cache speed: as a multiplier of CPU speed (esp. for Athlons) Bus Speed: 66, 100, or 133 MHz (overclockers may have other values) Timings:Use Advanced/Time on these exponents (M = million): 3M, 3.5M, 4M, 5M, 6M, 7M, 8M, 10M, 12M, 14M, 16M, 18M Send the BEST time. Try to get these timings when the machine is otherwise idle. OS: Windows 95, 98, NT, 2000, Linux, etc. Notes: Any other special information you think I might need to know. For example: uses PC133 memory instead of RAMBUS. For example, my PII-400 benchmark machine is: CPU type: PII CPU Speed: 400 L2 cache size: 512KB (I think) L2 cache speed: 1/2 of CPU speed Bus Speed: 100 MHz Timings:3M = .083, 3.5M = .098, 4M = .119, 5M = .132, 6M = .173, 7M = .211, 8M = .252, 10M = .281, 12M = .372, 14M = .453, 16M = .536, 18M = .600 I'll construct a page that gives the typical timings for each CPU type and speed. Thanks, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Williamette
Hi, At 08:40 PM 3/1/00 -0800, John R Pierce wrote: Hmm. Microprocessor Reports has released some interesting tidbits about the new Williamette processor which will probably be the Pentium-4... This is the chip Intel recently demonstrated running at 1.5GHz. Intel has info on this processor at http://developer.intel.com/design/processor/wmtsdg.htm The chip has good potential. The new SIMD2 instructions have the potential of doubling throughput. It also looks like FPU operations can be done in parallel with SIMD2 - that's triple the throughput of a PIII. Not to mention running at 1.5GHz! Of course, time will tell as to how good this processor really is. There could be other bottlenecks, it may not be easy to recode prime95 to use the SIMD2 instructions. The latencies for FPU operations are higher than in the P-III. The FXCH instruction is no longer free. Mispredicted branch penalties are higher, etc. etc. I've not heard any rumors as to a release date, but it looks like I'll have to buy two new computers in the next 12 months. An IA-64 and a Willamette! Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: searching the biggies
Hi, At 11:42 PM 3/2/00 -0500, Nathan Russell wrote: Nathan Russell asked: How much are the people who are trying to find a 10 million digit prime contributing to the search? I agree that all machines are contributing to our knowledge of Mersenne numbers. The gaps will eventually be closed. Since you're a relative newbie, the overriding goal of GIMPS has always been "have fun". That translates into doing the type of work that most interests you (as long as we all do the work in a coordinated manner). That is precisely why I switched to GIMPS from another project whose sole purpose was to simply recover a cute little, probably political, saying that someone had hidden. There are those that view prime number hunting as equally useless. I don't view GIMPS as in competition with other distributed projects. The links at http://www.mersenne.org let you choose the project that is most appealing to you. All are worthy in their own way. Two of their other projects lost GIMPS-years of work each because of stupid bugs and I got fed up and left. Uh... we had a bug too. Ironically, it was announced on April Fools Day last year. That caused quite a stir. We lost roughly a GIMPS month of work. This may seem like flamebait, and I do not intend it that way. Welcome aboard and good luck with your LL tests - but most importantly... Have fun, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Benchmarks
Hi all, Thanks to all that have submitted timings. There are still plenty of gaps to fill in and having multiple results for each machine is desirable. My first draft of the benchmark page is at http://www.mersenne.org/bench.htm Comments are of course welcome. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: NTPRIME and it's priority...
Hi, At 07:16 PM 3/13/00 -0700, Aaron Blosser wrote: and noticed that NTPRIME.EXE shows a priority of 8 (normal), but has 2 threads. I further did a 'pslist -x ntprime' and it shows that there is one thread running at priority 9, which I would assume is the "management" thread (writing save files, etc), but there is another thread running at priority 1 which is actually the thread using all the CPU time (as indicated by the "user time" column). All the higher priority thread does is "listen" for stop service and system shutdown messages. When one of these messages arrives, it raises the priority of the other thread so that it can finish its iteration, write its save file, and stop. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: V20 beta
Hi all, If you feel up to it, please give the beta of version 20 a try. The QA group has verified that the FFT code is working, but have not spent much time verifying all the interactions with the PrimeNet server. You can download it from ftp://entropia.com/gimps/v20/p95setup.exe (the fancy installation program) or ftp://entropia.com/gimps/v20/prime95.zip (a plain old zip file) Remember to set the available memory in the Options/CPU dialog box. Please report any bugs you find directly to me. The whatsnew.txt file reads as follows: New features in Version 20.0 of prime95.exe --- 1) The program now does some P-1 factoring prior to running first time and double-checking Lucas-Lehmer tests. This will increase overall GIMPS throughput. If you install version 20 in the middle of an LL test the program will run the P-1 step if the LL test is less than 50% complete. 2) The Options/CPU dialog box now asks how much memory the program can use during the P-1 factoring. See the "Setting Available Memory" section in the readme.txt file. 3) Stage 1 of P-1 factoring is now faster. 4) The GCD used in P-1 and ECM factoring is now faster. 5) The Test/Manual Operation menu choice has been deleted. 6) The memory options in P-1 and ECM dialog boxes have been deleted. 7) The "send new completion dates" checkbox was moved from the Test/Primenet dialog box to the Advanced/Manual Communication dialog box. 8) A bug in estimating time remaining for a factoring job was fixed. 9) AdvancedFactor now writes a line to the worktodo.ini - just like all the other work types. Have fun, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: V20 beta - bug? or fuctioning as designed?
Hi all, At 09:10 PM 3/17/00 -0600, someone wrote: Is it just me, or did you forget to reset the number of seconds after you display them when doing the P-1 factoring? The time keeps incrementing (by 32 seconds) for each iteration. someone else wrote: Is the P-1 factoring supposed to display the output in a cumulative manner? I'm not sure how long it should run, but it seems that a long run could cause the time and clock cycles to get unwieldly large. This was intentional and can easily be changed. Since it is different than the way trial factoring and LL testing is done, I suppose I should change it. If you have any strong reasons why it should be left cumulative, then let me know. Otherwise, expect the final v20 release to reset the timer after each screen output. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Possible V20 issue
Hi, At 05:46 PM 3/20/00 -0500, Nathan Russell wrote: I have noticed that, when I finish the v20 P-1 of an exponent and send in the result, there is no "sending results" line but only a "sending text message" line. Does this mean I am not getting CPU time credit? Correct. However, if you do find a factor you will get credit. In fact you get credit for trial factoring up to the size of the factor. In the long run, you will end up with more time credited than you actually invested. In the short run, it is like a CPU credit lottery. Scott does not have the free time to accurately credit P-1 factoring. However, it affects every one and is less than a 1.5% impact on your totals. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Possible V20 issue
Hi, At 08:28 PM 3/20/00 -0600, Ken Kriesel wrote: If someone has an exponent partially done under version 19.x or 18.x and upgrades and it finds a factor, will they get more credit for the factor than they lost for the partial LL run? I'm sure if you send an email to [EMAIL PROTECTED] with the exponent you were testing as well as what iteration you were on or your percent complete, then they will be glad to give you the CPU credit. But someone else may later P-1 factor the number and succeed in finding the factor. Then all the time to LLtest is uncredited, This happens in the stats at http://www.mersenne.org/top.htm but not the stats maintained by the primenet server. How's that for confusing! Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: V20 beta - round 2
Hi all, Thanks to all the beta testers of v20, you found a lot of bugs!! The 2nd beta is now ready. If you downloaded the first beta you should replace it with the new beta. You can download it from ftp://entropia.com/gimps/v20/p95setup.exe (the fancy installation program) or ftp://entropia.com/gimps/v20/prime95.zip (a plain old zip file) The whatsnew.txt file reads as follows: New features in Version 20.1 of prime95.exe --- 1) A bug in the new GCD code was fixed. 2) Timings in the P-1 stage are no longer cumulative. There is a new feature in undoc.txt for those that prefer cumulative timings. 3) Messages are now output prior to beginning the lengthy GCD. 4) The FactorOverride undocumented feature (not for use with PrimeNet) now supports factoring to a deeper level than prime95 would ordinarily factor. 5) A bug where the worktodo.ini entry was not removed if P-1 found a factor was fixed. 6) If P-1 finds a factor it now deletes any Lucas-Lehmer intermediate files. 7) A crash bug when continuing from a P-1 stage 2 save files with different available memory parameters was fixed. 8) Resuming an LL test now outputs a line to the screen, 9) The Test/Status display now correctly calculates the estimated completion time for an LL test when P-1 factoring is in progress. 10) Advanced/Factor menu choice was deleted. 11) A bug in computing P-1 stage 2 percentage complete was fixed. Have fun, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
