Re: Mersenne: Re: number of processors participating
As I recall, 200 was the default quantum on a vax 780 20 years ago. Even 10 years ago, interactive response could be sped up a lot by cranking quantum down to single digits. At 11:28 PM 10/30/2001 +0100, Steinar H. Gunderson wrote: >On Tue, Oct 30, 2001 at 10:00:07PM -, [EMAIL PROTECTED] wrote: >>which are much shorter than the minimum timeslice (which is >>typically of the order of 200 ms). > >200ms? Wouldn't this be an error? I can't really imagine that one would >typically have only five time slices per second :-) > >/* Steinar */ >-- >Homepage: http://www.sesse.net/ >_ >Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm >Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Thrashing (was Re: SV: Mersenne: number of processors participating)
What will really slow a workstation or server down is running short of RAM. These days the working sets are getting appreciable as the exponents increase. NT scheduling will wake up the service version of ntprime every second I think and give it at least one quantum. If some more essential service or application needs nearly all available RAM for its working set, and the working set of ntprime is big enough it gets paged out, the disk thrashes wildly and performance can suffer greatly for both the ntprime service and the other service or application, even while the ntprime service only gets a percent or two of cpu time. This is not just a characteristic of NT, but a general property of virtual memory operating systems; eventually it's just too little ram or too much demand, leading to performance decline. Ken At 05:05 PM 10/29/2001 -0800, Aaron Blosser wrote: >Still the only time I've ever seen Prime95/NTPrime slow down a system is when I was doing some Netmeeting video conferences. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Lucas Wiman Mersenne Prime FAQ
At 10:01 PM 10/25/2001 -, [EMAIL PROTECTED] wrote: >On 25 Oct 2001, at 10:31, Ken Kriesel wrote: > >> M33219278 is the smallest Mersenne Number with at least 10^7 digits, >> but M33219281 is the smallest Mersenne Prime with at least 10^7 >> digits. > >Um, I seem to remember testing that number & confirming Rick >Pali's discovery that it is _not_ prime. > >Perhaps it would be fair to say that M33219281 _was_ the smallest >_candidate_ 10 million (decimal) digit Mersenne prime (pending LL >testing). It isn't even that now. As Steinar Gunderson promptly pointed out, I should have said not "Mersenne Prime" but something like "Mersenne Prime Candidate". That would be valid until at least one LL test completes giving nonprime result, after which I would consider it a probable nonprime. After a matching double check completes, I think most would regard it a proven nonprime. Brian's double check completed April 6 on M33219281, confirming Rick Pali's results of Nov 5 2000; this exponent was tested as part of the QA effort and was for a time the largest completed double check. (M40250087 is to my knowledge the largest completed single or double-check.) How about this: M33219281 is the smallest Mersenne Number of prime exponent with at least 10^7 digits. Currently there is no Mersenne Prime known with 10^7 or more digits, so my error yesterday is rather glaring. Oops. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Lucas Wiman Mersenne Prime FAQ
At 01:01 AM 10/25/2001 -0500, you wrote: >Forgive my ignorance but; > >In reading the Lucas Wiman Mersenne Prime FAQ I became confused at the Q5.3 >instruction. (see FAQ insert below). > >I want to know how many decimal digits are in a given MP. >This part of the FAQ does not make sense to me. > >Specifically; > >First off this question seems to ask 10,000,000 exponents. It must mean >10,000,000 digits. > >The answer given below, M33219278, by my calculations, has less than >10,000,000 digits. The questions below ask "How many digits are in a given >Mp?" and "What is the smallest Mp with a given number of digits?" > >The explanation does not seem to answer that question. > >33,219,278/3.321928094887 = 9,999,999.11230167668 and > >33,219,279/3.321928094887 = 9,999,999.41333167235 and > >33,219,280/3.321928094887 = 9,999,999.71436166801 and > >33,219,281/3.321928094887 = 10,000,000.0153916636 > >This number 33,219,281 seems, from the explanation below, to be the first >Mp to have 10,000,000 decimal digits. Can I depend on this? This would seem >to make the answer 33,219,278 the third highest Mp with less than >10,000,000 digits. Mp is shorthand for Mersenne Prime, a number having value one less than two raised to the power p where p is a prime, often written in ascii, 2^p-1 meaning (2^p) -1 and not 2^(p-1) because exponentiation is an operator of higher precedence than subtraction. 2^33219278-1 is not a Mersenne Prime since 33219278 is not prime, being even. The only exponent of the four above that is prime is 33219281. (33219279 mod 3 = 0 by eye; 33 21 9 27 9) M33219278 is the smallest Mersenne Number with at least 10^7 digits, but M33219281 is the smallest Mersenne Prime with at least 10^7 digits. This distinction is economically important because >I need a formula that will definitely give the exact number of decimal >digits in a Mp or Mersenne prime Mp. At 09:30 AM 10/25/2001 -0500, Tony Pryse <[EMAIL PROTECTED]> wrote: >Dan, > >The FAQ is correct. (The version I saw has "10,000,000 exponents" corrected >to "10,000,000 digits", as you note it should.) > >The number of digits, d, in a Mersenne number, 2^n-1, is "the least integer >greater than or equal to n/log_2(10)." (The number of digits in an integer >must itself be an integer.) The rule in the FAQ answer misses a case. Consider some very small exponents: 2^0=1; log10(1)=0; # of digits =1 2^0-1=0; log10(Mn)= -infinity?; # of digits=1; rule yields 0 2^1=2; log10(2)=~.3010; 1 digit 2^2=4; log10(4)=~.6020; 1 digit 2^3=8; log10(8)=~.9030; 1 digit 2^4=16; log10(16)=~1.204; 2 digits ... 2^10=1024; log10(1024)=~3.0103; 4 digits 10^1=10; log10(10)=1; 2 digits 10^3=1000; log10(1000)=3; 4 digits The number of digits required is always at least one. The number of digits is rounded up, not down. I suggest the "or equal" is incorrect. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Spacing between mersenne primes
At 10:56 AM 5/16/2001 -, "Brian J. Beesley" <[EMAIL PROTECTED]> wrote: >Another point - we're coming up to the second anniversary of the >discovery of M38(?) - I think we're overdue to find another one! It would be nice to find another soon. But I don't think we're overdue. Long ago in Internet time I wrote: Date: Thu, 29 Jan 1998 22:57:31 -0600 "In mersenne primality testing, exponents double in magnitude are much more than double the work. For prime95 or the related versions, each iteration takes about 2.1 times as long as an iteration for half the FFT length, and there are twice as many iterations to perform, per exponent. The odds of a number being prime diminishes as the magnitude increases. Twice the FFT length is usable up to not quite twice the exponent. An interval of n to 2n contains nearly twice as many exponents as the interval 1/2 n to n. In either of these intervals we expect based on experience, to find about the same number of mersenne primes on the average. (The actual rate of occurrence seems to be a little bit in our favor for finding more primes in higher intervals, but it's slight.) That makes about 3 factors of 2. I think to maintain a constant rate of discovery of new primes, we would need to maintain about an 8 or 9-fold increase of computing resources per period of exponent doubling. Since exponent doubling has occurred in about the past year, most of this must come in rapid growth in the cpu pool, both by upgrades and by new membership. Otherwise we can expect to droop back to a lower discovery rate. On average there are less than 2 mersenne primes per exponent doubling: 36 / [ln(2976221)/ln(2)] = 1.67 mersenne primes per doubling of exponent, or about 37 / [ln(~300)/ln(2)] = 1.72 Mp's per doubling of p (though we may have yet to find one in p < 2976221, or slightly above!) In the long run the present discovery rate is unsustainable. Even if we do drop back to a discovery rate of one per two years, from the recent ~2 per year, we will have moved this area ahead by years from its old curve. (The discovery rate was about 1 per 2 years over the past 20 year interval and for the past 40 year interval.)" Our experience described on http://www.mersenne.org/history.htm bears this out. And there is no particular reason to expect the time interval, or the spacing between mersenne primes on a log or linear scale to be uniform. It should vary about the expected curve. Ken Kriesel _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: QA (was re: Mersenne: Purpose of the self-test; also, aren't P4s fast!)
At 10:56 AM 5/16/2001 -, Brian Beesley wrote: >On 16 May 2001, at 0:24, Ken Kriesel wrote: > >> For the time being I would like to continue focussing our QA efforts on the >> general case, rather than P4's specific limits, since > >Agreed. I was talking about the "short" test suite, where the runs >stop after 400 iterations. We can generate the required data for a >large number of exponents without diverting significant effort. In >fact it's much easier to do this than it was a couple of years ago, >as we have at least two reasonably efficient programs other than >Prime95 which can be used to generate & cross-check the data. >> >> If I recall correctly, this does not require "ridiculously" small exponents, >> since the convolution error falls off quickly away from our usual upper >> limit on exponent for a runlength. > >Quite correct. IMO it is "ridiculous" to run a whole LL test using a >FFT run length of 2R when a run length of R would suffice; but >running at least some 400-iteration short tests with a "half size" >exponent during a self-test does make sense in two ways: it saves >having to generate quite as much short run data (since we can recycle >some of the smaller exponents into larger self-test run lengths), and >- providing there is a temporary reduction in the rounding error >limit whilst these short runs are in progress - we would be making >the self-test more stringent. Yes. Even the next-longer runlength provides a very large drop in the expected convolution error for those exponents near the limit of a runlength.(orders of magnitude.) Two to one on runlength is not needed. The ratio 5:4 gives substantial reductions. >There is no point in optimizing the self-test for speed, since we are >going to run the self-test for a fixed period of time. There is some point in having the self-test resemble closely, actual running conditions, to be as valid a test as possible, with respect to everything from bit patterns to power loadings. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: 26 exponents
I believe that is set at the server. Ken At 08:25 AM 5/16/2001 +0100, "Daran" <[EMAIL PROTECTED]> wrote: >Does the client 'know' the threshold performance level for double-checks and >factorisations? If so, is it hard-coded, or does it get this information from >the server? If hard-coded, then you have a problem with people continuing to >use older clients which tell them that it still makes 'most sense' to do >first-time checks, long after it has become more sensible to do double-checks >or factorisations. > > >Daran G. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
QA (was re: Mersenne: Purpose of the self-test; also, aren't P4s fast!)
At 10:23 PM 5/15/2001 -, "Brian J. Beesley" <[EMAIL PROTECTED]> wrote: >On 14 May 2001, at 20:52, George Woltman wrote: >> >> >Is the self-test in fact just to check >> >that there's not something in the CPU which goes glitchy when running >> >flat-out SSE2 code for hours on end? >> >> Yes. The QA suite that Ken Kriesel and Brian Beesley worked on does a >> better job at testing edge conditions. Of course, they'll need to update that >> suite using the new limits. For the time being I would like to continue focussing our QA efforts on the general case, rather than P4's specific limits, since 1) there are relatively few P4's 2) we haven't finished QA testing in all run lengths with V19 / V20 (sign up now for a limited number of large exponents still available!) 3) the V19/20 QA now ongoing establishes "gold" residues over a huge range of exponents, against which other programs on other architectures can also be tested. >Actually most of the exponents in the test suite were chosen to >exercise code in a manner which is particularly hard on the "magic >numbers" involved in the collapsed DWT. Above is one of the methods of exponent selection. As George Woltman stated it: "Exponents that are close to a multiple of the FFT length." Other selection methods used to select full-LLtest exponents for QA were: 1) Already double-checked good numbers (or triple- or higher checked). Rerun to verify we can reproduce known-good results of previous versions or other code. 2) Duplicate the primality result for all known mersenne primes. (A special case of the above.) 3) The uppermost and lowest prime exponents within the determined limits for a given runlength. Always test limit cases. A little more than George suggested: "Those near the end of each range should be checked for excessive convolution error." 4) The prime exponent on either side of each integer power of two within the range supported by the program 5) Randomly selected prime exponents within the determined limits for a given runlength; typically one per higher runlength. The purpose of this set is to perhaps smoke out some case which we did not imagine. 6) We also tested a few composite exponents, just in case they behaved differently. 7) LLtests were except for #6, mostly done on exponents that had already run the gauntlet of trial factoring, p-1, and sometimes ecm. >Perhaps it would help us if George could indicate the approximate >limits for each run length when the SSE2 code is in use. Definitely. >But could I just point out that there is a _potential_ benefit in >running selftests using ridiculously small exponents for the run >length being tested. Normally the maximum permitted roundoff error is >0.4; this means that a roundoff error will only be detected as such >on one in every five occasions on which it occurs. If we use a small >exponent then we could reduce the roundoff error limit to 0.1 (or >maybe even less) and therefore detect a much larger proportion of any >roundoff errors which might occur. The fact that the residual checked >at the end of each self-test may still be correct does not prove that >a hardware glitch has not occurred, though gross errors will of >course cause the selftest to fail for this reason. If I recall correctly, this does not require "ridiculously" small exponents, since the convolution error falls off quickly away from our usual upper limit on exponent for a runlength. Convolution error varies with run length, exponent, and shift count. Running a case where we know the expected answer with high certainty: exponent, runlength, # of iterations, shiftcount? entered as qadata.txt 1279,40,1277,0, 1279,48,1277,0, 1279,56,1277,0, 1279,64,1277,0, output respectively Exp/iters: 1279/1277, res: 7653615CCA7AB4C0, maxerr: 4.00, maxdiff: 131072.0/529374.103214235 Exp/iters: 1279/1277, res: 5C21BA6CB463E665, maxerr: 0.50, maxdiff: 128.0/393.066381654 Exp/iters: 1279/1277, res: , maxerr: 0.157410, maxdiff: 1.00000/2.342300785 Exp/iters: 1279/1277, res: , maxerr: 0.001817, maxdiff: 0.007812500/0.051145460 >Date: Fri, 07 May 1999 01:48:12 -0500 >To: George Woltman <[EMAIL PROTECTED]> >From: Ken Kriesel <[EMAIL PROTECTED]> >Subject: Re: more shift count variation qa results of 4423 > >At 09:07 AM 1999/05/06 -0400, you wrote: >>Hi Ken, >> >>At 12:29 AM 5/6/99 -0500, you wrote: >>>The cutoff at 4365 seems a little conservative; 4423 seems quite happy with >>>shift counts >>>that push it to maxerr 0.48. >> >>To me that indicates you could well run into a shift count that crea
Re: Mersenne: GIMPS accelerator?
Among others, I raised the question with George Woltman some time ago. I trust his judgment that his time is better spent elsewhere. However, I wonder if there might be some possibilities in trial factoring there. That would present the possibility of a factoring screensaver, and an FPU LLtest, running together on what is nominally a uniprocessor. Just speculation, Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: [slightly OT] Web discussion about distributed computing
Brian is likely to break his own record in about 5 months, with an LLtest of 2^40250087 -1 proceeding rapidly, with Stephan Grupp's simultaneous test of the same number trailing by 11 days at the moment, both as part of the continuing mersenne QA effort. This candidate was P-1 tested by Brian, B1=36, B2=180 after being trial factored by Nathan Russell last summer. There are still some QA exponents available in the upper stratosphere ranges for various forms of factoring, or LLtest. (These mostly require cpu speeds above 500Mhz to complete LLtest in less than 5 years. Each.) Ken At 06:25 PM 4/23/2001 -, Brian J. Beesley wrote: > >If you allow a construction like that then, whatever number you >suggest, I'll nominate a bigger one. > >AFAIK the largest number currently known to be composite but with no >known factors is 2^33219281-1, the only 10 million digit Mersenne >number which has been LL tested twice with matching final residual. >(Rick Pali, 2000 & Brian Beesley, 2001) This number has been trial >factored up to 2^68 and subjected to P-1 with B1=495000. > >Naturally I am happy to give up this claim to "fame" should a factor >of this number be discovered, or when a larger number is eventually >subjected to a definitive test for compositeness and cross-checked >against the possibility of error. > > >Regards >Brian Beesley _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: More than 10000 athlons!.
Well, you can add at least 20 P3 cpus to the total, that I run on without the involvement of primenet. Also about 20 Celerons. Prime95 makes a great hardware reliability tester, and has ferreted out numerous mildly flaky RAM modules and a couple bad motherboards. Ken At 01:16 PM 3/26/2001 +0100, Siegmar Szlavik wrote: >On Mon, 05 Mar 2001 18:42:42 +0100, Guillermo Ballester Valor wrote: > >>Last weekend the number of AMD-athlons registered in Primenet has >>reached 1. In few weeks they will be the most popular among GIMPSers >>if the actual trend continues. >> >Since a few days there is a head-to-head race between the p3 and athlon. >At the moment it's almost even: > >Status Summary Report 26 Mar 2001 11:00 (26 Mar 2001 03:00 Pacific) >[...] > Intel Pentium III : 10710 > AMD Athlon: 10711 > >btw: what about p4-systems? are they counted as p3-systems? > >Siegmar > > > >_ >Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm >Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Processor short family histories
At 09:44 AM 2/13/2001 -0500, Jud McCranie wrote: >At 12:54 AM 2/13/2001 -0600, Ken Kriesel wrote: > >>Intel offered the 286 with 6, 8, 10, and 12.5 Mhz on one data sheet. >>AMD got to 16 on this one, but an early data sheet lists 4, 6, and 8 >>(and says reprinted by permission of Intel). FPU was separate. >>I don't recall a 286-20. > >Dell had one. At the time I got my Dell 20 MHz 386 (fall 1987) they had a >20 MHz 286. > > > The 386 debuted at 12.5 and 16 Mhz. > >I thought it debuted at 16. I never heard of a 12.5 MHz 386. 12.5 and 16 is what the preliminary data sheet said when Intel first printed & distributed them in 1985. I believe Zenith made 12Mhz machines. The manufacturers who could get 16Mhz chips used the higher speed, naturally. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Processor short family histories
The 8088 debuted at 5 (& 8) Mhz; IBM derated it a bit for the PC because 4.77Mhz*3 = 14.318 = 4 * 3.57Mhz (TV color burst frequency). An IBM (pre-XT) motherboard could be pushed to about 7.5 Mhz by splitting the clock signal paths. FPU was separate. Ten Mhz chips were offered. This chip had competition from the 8086, 80186, and NEC V20. Intel offered the 286 with 6, 8, 10, and 12.5 Mhz on one data sheet. AMD got to 16 on this one, but an early data sheet lists 4, 6, and 8 (and says reprinted by permission of Intel). FPU was separate. I don't recall a 286-20. The original IBM AT was designed with CPU clocked at 6Mhz, FPU at 4Mhz. The 386 debuted at 12.5 and 16 Mhz. These had no cache on-chip. On-motherboard cache was common for 25Mhz and above. Intel's offerings topped out at 33Mhz, AMD offered 40 eventually. The 386 core was also throttled down to 16-bit bus width in the 386SX, which had speeds as low as 10Mhz and up to 20 or higher. FPU was separate. Cyrix offered a faster FPU. TI eventually offered a clock-doubled near 486 with cache in a 386 pinout. The 486 was the first to offer an on-chip FPU, came out at 20 and 25 Mhz and went to 100 Mhz (core=3x memory bus) in the Intel line, 133 (4x) elsewhere (AMD?). The 486 socket's performance could be stretched a little further by using a Pentium Overdrive chip from Intel; at 83 Mhz (2.5x) giving 1.7x the performance of a 486-66 in real world finite element analysis (ANSYS). The 486SX was a no-fpu 486, with full memory bus width. The Pentium I's in various subflavors went from 60 & 66 at announcement, to 200 (nonMMX) and 233 in the MMX type. I think the Pentium Pro's went 166, 180, and 200. Pentium II's included the 266 Mhz speed. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: screen savers
At 05:56 PM 2/9/2001 EST, [EMAIL PROTECTED] wrote: >Just my 2 cents' worth with respect to the screen saver >proposals: how about the following? > >2) For the folks who like something that looks more >scientific, we could have a vertical box that looks >like a control panel. Every iteration, the bottom Y >bits of the LL residue get printed to the bottom line >of the panel, and the others move up. We could colorize >the individual digits of the hex residues, or pick a >new color for each new Residue, so things look a bit >more dynamic. The faster the user's machine, the more >dynamic the output. I had been thinking that it would be interesting to map the entire savefile, one byte per pixel, into a rectangular area centered on the screen, updating every time a new intermediate savefile is saved. I think default is every 30 minutes, but that can be adjusted. Below the graphic could be displayed the iteration number and exponent. A historical bar graph of iterations throughput per minute, scaled relative to the maximum ever achieved on that machine, for the current runlength, is another. It has the advantageous property that some end users might be encouraged to maximize their throughput via the easy feedback. Make a change, wait, check the graph. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: idea for a new prime95 version, QA, primenet etc
At 09:23 AM 2/3/2001 -, "Brian J. Beesley" <[EMAIL PROTECTED]> wrote: >George has announced the development of new FFT code optimised for >Pentium 4. The FFT code is the true heart of the program: it's really >hard for me to put into words just how much we all owe to George for >his unstinting efforts to make the program as efficient as it is. >Suffice it to say that, without George's input, we would probably be >two or three Mersenne primes short of where we actually are. Possibly 4 primes. I've been lobbying a bit for a dual-processor optimized version for Intel. I have little technical basis on which to judge the potential gains, but speculate that memory bus contention and caching efficiency would be improved if both processors were working on the same large exponent. Well before learning of GIMPS and George's program in 1996, I had coded a program to do limited trial division followed by a Lucas-Lehmer test. Having done that, and then seeing the efficiency of George's program, gave me a better appreciation for how much work and skill went into prime95. It's highly optimized, using the counters built into the cpus for the purpose, and using virtually everything known about properties of potential factors and the best algorithms to speed things up both in the factoring attempts and the Lucas Lehmer test. Our best hopes for future speed improvements are 1) the steady march to faster computers in greater numbers (& more multi-cpu systems running multiple instances of the program 1 per cpu) 2) possible future discoveries of better algorithms by mathematicians. Last I heard, there was still some space between the upper and lower bounds to the limit on number of operations required to perform a long multiplication or squaring. 3) modest increments due to optimizations to specific architectures, additional factoring methods, implementation of additional FFT runlengths etc. The easy large gains were implemented long ago, and medium difficulty & moderate gains also, leaving diminishing returns requiring significant effort. >Nothing built by human hands is perfect, so, sure, the program could >be improved! Personally I'd like to see an optimization for Athlon; >at the expense of having to load different versions for different >processor types, I'd like to see seperate "streamlined" versions of >the code optimized for different processor types rather than one >monolithic program with everything embedded in it; and I'd like to >see the client/server security code somehow "opened", to facilitate >the integration of non-Intel clients into PrimeNet, but without >sacrificing the trust we have that results have really been computed. Let's keep it simple; disk space is cheap (including space for paging out unused code). I think the current situation where the program detects cpu model and reacts accordingly is a good one; you can still take control by editing the ini file if need be. It keeps it simple for both the novice end user wanting to download a program and get going, and for the program developers. If cpu-specific programs were made instead, the number of distinct programs gets large because the combinations of cpu type and OS is large. Prime95 supports or supported something like 11 cpu type codes. Regarding OS, there are at least 6 types (currently maintained at V20): Win95/NT interactive NT service linux statically linked linux freebsd statically linked bsd Setting CPU type in prime95 V20.4.1 and then examining local.ini, CPUType=3 is a Cyrix 6x86 CPUType=4 is a 486 CPUType=5 is a Pentium CPUType=6 is a Pentium Pro CPUType=7 is an AMD K6 CPUType=8 is a Celeron CPUType=9 is a PentiumII CPUType=10 is a PentiumIII CPUType=11 is an AMD Athlon P-4 code adds another type. (Is there another AMD type?) Presumably cputype 386 and below have been retired (yes 386's were supported, in v13.2 or so) Perhaps some GIMPS participants could offer George & Scott nonprivileged account access on some other architectures, so they could do the required development. >With increasing exponent size (and therefore run time), I'd like to >see PrimeNet evolve to track intermediate residues & also to be able >to coordinate parallel LL testing & double-checking, so that runs >which are going wrong can be stopped for investigation without having >to be run through to the end. In the QA effort, we've seen a few instances already of errors caught midway by doing a manual/email version of this. Brian Beesley had an error detected this way in his run of a double-check of a 10-megadigit exponent. This exponent takes a PII-400 428 days (yes 14 months) to complete, so detecting the one error and restarting early saves about 10.5 PII-400 months. (Thanks to Rick Pali for providing interim residues to make this savings possible.) Another exponent, 20295631 showed similar results; both Paul Victor Novarese's run and mine produced errors while Brian Beesley's run matched Gordon Spence's. I assume that B
Re: Mersenne: Soft modem
Personally, I always go with an external modem. It's much less hassle if you need to cycle the power on the modem, or it's taken out by a lightning hit or other surge in the phone line, or from some other failure. It's way easier to swap modems when diagnosing "is it the modem that's broken, or the phone line?". It's also been a requirement if you want to run the modem with NT. Check the compatibility lists for whatever operating systems you plan to use. I think you can get a USRobotics/3com Sportster 56k modem for about $100 now. That includes the built-in DSP, that does the processing your CPU has been burdened with.. Ken At 08:27 PM 10/4/2000 -0400, Nathan Russell wrote: >Hi all, > >I have noticed significantly better Prime95 times here at school than I >did at home. On a hunch, I checked the hardware lists on the web, and I >have what by all accounts is a software modem. > >Both to get the Prime95 times at home back up, and since I plan to put >on a dual boot, I would like to get a hardware modem. My questions for >the list: > >Are hard PCI modems available? > >If so, is there a sure way to recognize them? > >If not, are any hard internal modems? > >Thanks! > >Nathan _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt
Re: Mersenne: Why do I get only double-checks
Setting CPU type in prime95 V20.4.1 and then examining local.ini, CPUType=3 is a Cyrix 6x86 CPUType=4 is a 486 CPUType=5 is a Pentium CPUType=6 is a Pentium Pro CPUType=7 is an AMD K6 CPUType=8 is a Celeron CPUType=9 is a PentiumII CPUType=10 is a PentiumIII CPUType=11 is an AMD Athlon So CPUType=1 must be what, an Intel 80286? (More likely an unsupported value.) If I enter CPUType=1 or 2 or 3, while editing local.ini, prime95 displays it as a Cyrix 6x86. RollingAverage=1000 means the system runs iterations at 1000/1000 the expected speed (indexed relative to George Woltman's PII-400 on a per-Megahertz basis) Lower RollingAverage numbers mean lower performance. Higher numbers, higher performance. Your P3-500 is performing much better than the lowly cpu type the program thinks it is. But it is given only double checks because the program thinks it's a much slower cpu type than it actually is, and so does the primenet server. Make the CPUType in local.ini match the actual processor type, and you can get first-time tests, and use code that's more efficient for your cpu because it's what George tuned for it. Options, CPU, click on Pentium III. Ken At 06:38 PM 9/14/2000 +0100, you wrote: >I'm using a P3-500E box at college to run mprime. > >The relevant lines of the local.ini look like > >LastEndDatesSent=967023734 >RollingStartTime=968950008 >RollingAverage=4000 >CPUType=1 >CPUSpeed=500 >CPUHours=24 > >How come I get given only double-checks to do? I don't mind too much -- the >machine kills off a double-check in ten days -- but I'd be slightly >surprised if the frontier of 'obsolete; use for double-checks only' had >reached this one-year-old box yet. That Rolling Average figure looks kind of >high, too. > >Tom > >_ >Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm >Mersenne Prime FAQ -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt > _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt
Re: Mersenne: Re: Prime95 shutdown mystery.
At 03:48 PM 7/27/2000 +0200, Steinar H. Gunderson wrote: >There is a tracert.exe included with Win95 and Win98, at least. And in Windows NT 3.x, 4.0, ... Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt
Re: Mersenne: Error
I saw something similar once, out of hundreds of ECM curves that I've run. It happened on the curve being run while I adjusted memory limits on the program (Version 20.4.1, April 25 file date), if I recall correctly. Ken At 03:42 PM 5/25/2000 EDT, you wrote: >I just got this in an ECM run on M(10079). What does it mean? Is something >wrong with my machine? > >[Thu May 25 15:00:24 2000] >ECM found a factor in curve #263, stage #2 >Sigma=1155032128984, B1=25, B2=2500. >ERROR: Factor doesn't divide N! > >Nathan _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Version ID Buglet
I've forwarded Nathan's message to Scott Kurowski. (He usually reads the digest version, IIRC, so this may speed a solution.) Please do not send duplicate messages to him regarding the possible primenet bug that Nathan described. Thanks, Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Just curious
Monitors, on the other hand, seem to like to be shut off regularly. At work, we bought 9 Nanao F750's & &60's in 1993. Only two survive, and one sits on my desk and is turned on and off daily. Those that were left on 24/7 did not survive the last cycle of cpu upgrades. Ken At 01:42 AM 4/19/2000 -0500, Ryan McGarry wrote: >All this talk about PC's running 24/7 has convinced me of the >reliability of processors. It's been my thoughts that if your computer >is on, it's always running at full speed, whether or not you're running >Prime95. >I've always left my computers on all the time, and never had a problem. >This reliability got me thinking about any other appliances that have >the same level of reliability. > >For example, I remember reading an article about light bulbs which said >that if you leave a light bulb on continuously, it will last much longer >due to the fact that the the filament doesn't contract when it gets >cold. > >I suppose my question is whether or not it's more of a risk to your >processor in allowing it to cool off regularly than leaving it on 24/7? > >Thanks, >Ryan McGarry > >John R Pierce wrote: >> >> > When pentium pro 200's were the hot new processor >> > (in speed, more so than in wattage), >> > I began running some dual-ppro-200 systems with two prime95 instances >> each. >> > Those processors are still running it. >> > I've never had to replace a cpu or motherboard >> > (though occasionally a motherboard power connector >> > had to be replaced because it burned up). >> > I'm not sure but I think that's three years. >> ... >> >> Until last August, my *original* Prime95 participant, a Pentium-100 running >> first Win95, later Win98, faithfully chugged along 24/7. I started this >> CPU back when the very first Mersenne article came out in the San Jose >> Mecury News. This was long before GIMPS had found a prime.Since this >> win95 box's only other duty was print-server for a old inkjet, and the very >> occasional fax, it went a month or more between reboots regularly. Said >> machine is still alive and well, only now its a 133MHz 64MB ram linux based >> internet server for my DSL connection. http://hogranch.com :) The P100 >> was new when the first 133Mhz pentiums were becoming available and the 90s >> and 100s got a lot cheaper. Off the top of my head, I think it might be 5+ >> years old. And, yes, I have a dual PPro-200 which has been running prime95 >> 24/7 since it was built 3 years ago. >> >> -jrp >> >> _ >> Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm >> Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers >_ >Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm >Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Just curious
When pentium pro 200's were the hot new processor (in speed, more so than in wattage), I began running some dual-ppro-200 systems with two prime95 instances each. Those processors are still running it. I've never had to replace a cpu or motherboard (though occasionally a motherboard power connector had to be replaced because it burned up). I'm not sure but I think that's three years. Uptimes for these NT systems were averaging 6 months between reboots, though that has dropped some since the UPSes that power them are aging and so power is less reliable now. I've had a dual-pentium-200-mmx running NT4, and dual prime95 instances, 2 years solid also; the last boot of that system was August 12. I'm sure you'll hear from others, that these durations are not remarkable. Some may advocate other OS's. (I've also run Vaxes for 6-9 months uptime, and power and hardware reliability & application of OS updates was similarly controlling there. Even network switches will occasionally get in funny modes after some months.) The error detection built into prime95 has been useful in identifying some systems where memory simms or motherboards were going flaky, months before the end user noticed it. Ken At 08:24 AM 4/18/2000 +0100, you wrote: >I'm just curious really, but how durable are Intel >processors to continuous number crunching, in other words >has anyone been able to keep the same processor running for >2, 3 or even more years, on a 24/7 basis. I do realise that >Windows itself needs to be rebooted from time to time, but >what about other O/S? Anyone care to throw a few stats in? > >Tony Gott >Shetland > >_ >Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm >Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: $1 Million For Proof Of Goldbach's Conjecture?
>On 20 Mar 00, at 19:01, Stefan Struiker wrote: > >>LONDON , March 17 Two publishers are offering a >>million dollars to anyone who can prove that all >>even numbers are the sum of two prime >>numbers. No one has cracked the problem in the >>more than 250 years since it was first posed, and >>Fridays announcement indicated the publishers >>arent too worried about having to pay up. I'm guessing the actual conjecture is worded something like, Each even number can be expressed as the sum of exactly two unequal primes. Otherwise the question would already be answered, as all evens can be expressed either as a summation of the value two, or as n= n/2 + n/2, in which n/2 may be prime or not, but if not, could themselves be expressed as the sums of primes. I wonder if this could fall to the approach used in the 4-color map problem. (If I recall correctly, a combination of subdivision into many subcases, followed by a lot of computing time.) Could someone post the actual wording of the conjecture? Ken _ 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
At 08:14 PM 3/20/2000 EST, you ("Nathan Russell"
<[EMAIL PROTECTED]>)wrote:
>
>Another potential issue that just occured to me:
>
>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? This is something that might be a
>significant issue for those who are running P-100's and comperable machines,
>where it would be a loss of months rather than weeks. If this has already
>been thought through, I still feel that it would be good for the list to be
>aware of that fact.
>
>Best regards,
>Nathan
George has previously indicated that P-1 factoring is attempted, before
continuing on, if the LLtest in progress is less than 50% done, and
otherwise not. This is done as a total throughput optimization of GIMPS.
If the LLtest is more than 50% done, the LLtest continues.
But someone else may later P-1 factor the number and succeed in finding
the factor. Then all the time to LLtest is uncredited, as happens for all
LLtests,
whether prime95 V20, V14.1 or earlier, or some other program. (Watch
David Slowinski's cpu credit and number of exponents credited slowly
shrink, as
factoring gradually erodes his totals. Credit for dozens of my early tests
has
also been factored away.)
If the person with the LLtest in progress finds the factor, he gets the
factoring credit.
Ken
_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: M 10133741
M 10133741 is not an assigned QA exponent
(at least by me.)
Scott tells me that the IPS will accept results whether assigned by IPS or
not.
However, the IPS is not involved in issuing QA work; I do that manually,
independently of IPS.
A computer search for the exponent on qa assignments, qa results, and
email correspondence comes up empty except for your question.
Ken
At 06:38 PM 3/17/2000 EST, you ("Nathan Russell" <[EMAIL PROTECTED]>)
wrote:
>In a scan of the PrimeNet status page
>(http://www.entropia.com/primenet/status.txt)
>I noticed that this exponent was due to expire sometime around last
>Halloween.
>
>Is there a bug in the server? Is the owner a QA person who is being given
>some leniency? If so, why is the server being used?
>
>Nathan
>__
>Get Your Private, Free Email at http://www.hotmail.com
>
>_
>Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
>Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
>
_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Large-Exponent QA
At 07:54 PM 3/7/2000 -, Brian J. Beesley wrote: (many detail comments deleted, wherein Brian sets the record straight) >I've just put the file back up. Sorry, it got removed accidentally >when I upgraded the server hardware about three months ago. Thanks, that's useful. >[ Ernst Mayer comments ] >> >So, it doesn't look like testing exponents above ~40M is going to >> >be practicable any time soon, where I mean doable in a year or less. But >> >since the vast majority of GIMPS first-time LL tests won't even be >> >approaching 20M for some years yet, having one or two double-checked >> >exponents in each subrange below 39M would seem sufficient for the next >> >couple of years. > >I agree. Of course, anyone who thinks it's _fun_ to tie up a system >for several years running a LL test on a larger exponent is quite >welcome to do so, so far as I'm concerned! Well, I'm one of those folks who regards it as much more fun to have cpus fully occupied than idle, and believes the scouts should be well ahead of the army. Ken said, in regard to partially completed runs: >> I'd like to see them get cpu credit, but I am not in a position to >> guarantee it. > >George seems to add the CPU credit from QA tests to his records. So >far as PrimeNet is concerned, we (deliberately) don't use PrimeNet to >communicate results; in any case PrimeNet doesn't recognize that we >own the QA assignments (some of them are actually triple-checks & the >rest are outside currently active ranges), which is why they "don't >count". This doesn't bother me, but it should be easy enough to fix. So far as I know, George treats full LL tests from the QA group like any other manually reported results; credit is given. >> Most of the effort would fall on someone else, and I'd rather see George >> and Scott doing other things than the bookkeeping of apportioning credit >> by iteration count and exponent size and checks of usable save files. To >> keep the minimum contribution sizable, I ask the volunteers to commit to >> at least a half-PII-400-year; large contributions are more likely to >> justify crediting the work or a partial large exponent. >> >I'd strongly reccomend anyone running PrimeNet 10 million digit >assignments to place the following line in their prime.ini file: > >InterimFiles=100 > >This will cause the interim residual to be written to results.txt >every 100 iterations. At the same time, an extra save file will >be written. The idea is that, when double-checking is scheduled on >this exponent, any error can be found without neccessarily having to >complete the whole run to find it, thus saving time. Also, in the >event that a prime is found, with a set of interim save files we will >be able to verify the result much more quickly by running 100 >iterations on thirty odd systems in parallel. Personally, I'd prefer 200 for the bigger exponents, but that's personal taste. Ideally, in a future version of prime95 and primenet, the interim residues will be handled over IPS and include some tiebreaker strategy. The observed trend is for LL tests to be less reliable with increasing exponent, due to increasing runtime, so an automated way of detecting and handling mismatches in interim residue becomes increasingly important as the average available exponent increases. >If you're worried about disk space, delete the extra save files; the >interim residual has considerable value in itself. > >Also could anyone dropping out of a large exponent run (including >PrimeNet 10 million digit range assignments) please send in a copy of >their last savefile, so that work completed isn't lost. My server has >lots of space available for this task. I've made the standing offer before, of anyone with large exponents & wanting to quit, that the QA group will take them on for completion. Brian's ftp server is an ideal drop point. Ken > >Regards >Brian Beesley > _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Large-Exponent QA
At 06:07 PM 3/6/2000 EST, you <[EMAIL PROTECTED]> wrote: >Ken Kriesel writes: > >>Participants in this phase of the QA should be willing to coordinate by >email with >>a partner, running LLtests and double-checks of the same exponent in >parallel, >>and cc George Woltman and myself, interim residues at suitable intervals. > >Since you say you also want some non-Intel CPUs to participate here, >I have a couple of comments. An easier way to maintain a running check >of residues is to have the program write a simple Res64 (lower 64 bits >of the residue, in hex form) to a file every few thousand iterations. >Pair up users according to their hardware speed, i.e. so both members >of a QA duo are dispatching iterations for their exponents at roughly >the same speed. Save copies of full-length residue files only every >million iterations or so. If the Res64s for given iteration >match (which needs only a quick exchange of e-mail, once a week or so), >then the full-length files for iterations up to that point don't need to >be compared. What I meant was interim 64-bit residues (not full intermediate savefiles or full-length residues) every 1 or 2 million iterations, since they will be compared visually. QAtest volunteers are typically being partnered, and exchanging just the 64-bit residues by email & cc myself &/or George. (Keeps the email size much smaller than passing save files, and removes the temptation of cheating.) There's no point in the larger traffic of a 64-bit residue every few thousand iterations, which corresponds to an hour or two of runtime at most. The QA volunteers are encouraged to keep the full-length intermediate files of every million or two million iterations intervals, and do backups, and if quitting, transfer the last good save file so someone else can take up where they leave off. ... >Also note that Mlucas starts its iteration counter at 1 rather than 0, >so when Mlucas writes (say) a 2000th-iteration Res64 to the .stat file >for a given exponent, it corresponds to the 1999th-iteration residue >of Prime95. Unfortunately that unit-offset dumbness on my part won't >be fixed until Mlucas 3.0 comes out, because I don't want to deal >with the logistics of figuring out whether a v2.7 savefile was written >by a unit or zer-offset version of the code and figuring out whether >an extra iteration needs to be tacked on before writing the next save- >file. (Mlucas 3.0 savefiles will have a different format, so that won't >be a problem.) > >I can easily create a modified QA-only version of the 2.7 code to >use a zero-offset iteration counter, but want to make sure that this >will be part of an agreed-on QA scheme before doing so. George, can >you modify your code to create a QA version that writes periodic >Res64s to a file? That modification is already present in prime95. Output looks like this: [Sun Feb 13 16:51:26 2000] M4948673 interim residue 06B0A8372B7C3239 at iteration 200 [Thu Feb 24 23:45:20 2000] M4948673 interim residue 7D4B80BF1E9DF827 at iteration 400 Lots of results (verified by 2 independent runs on separate processor generations in V19 prime95) were available at iteration counts of 100 and 400 if I recall correctly, partly for validating future programs, at ftp://lettuce.edsc.ulst.ac.uk/gimps/PrimeQA/QADATA.TXT thanks to Brian Beesley for generating the list of exponents to run on, running most or all of one pass, and hosting the data. I see that file's no longer there. The intent of this part of the QA effort was to provide validation of iteration code on many exponents quickly, both for QA of prime 95 V19, and future versions of various programs, including the less fast ones, in all ranges of exponents and runlengths prime95 currently supports. >So, it doesn't look like testing exponents above ~40M is going to >be practicable any time soon, where I mean doable in a year or less. >But since the vast majority of GIMPS first-time LL tests won't even >be approaching 20M for some years yet, having one or two double-checked >exponents in each subrange below 39M would seem sufficient for the next >couple of years. Remember the 10-mega-digit hunters; there will be exponents above p=33,000,000 tested before long. Some already have 10M or 12M iterations done. QAtesters may play the same hardware-upgrade game as the rank & file, and upgrading hardware more than once before completing the truly large exponents is likely. (Last year's fast system was a PII-400; it would take 6.5 years to do p=79,299,xxx; who wants to keep the same workstation for 6 years?) >As a lure to prospective QA testers, I say they should be GUARANTEED >p90-CPU-years credit for whatever work they do, assuming they provide >a savefile useable by someone else with compatible hardware if
Mersenne: QA testing
At 05:42 PM 3/3/2000 +0800, "Dave Mullen" <[EMAIL PROTECTED]> wrote: >For interest, has anyone calculated benchmarks, or run LL tests in those ranges; >I guess not many, 8 months is a long time to wait for a result !! A select group of volunteers have been running factoring and LLtests as part of the QA effort, with the long range goal of producing multiple tested and double checked exponents in every fft length that prime95 currently supports. We've had occasional setbacks, including the necessity to repeat in v19.2, trial factoring for exponents above 2^32/120=~35.79 million after the discovery of a carry error in the factoring code present in v19.0 and v19.1. Some volunteers have dropped out, due to various reasons including lack of time & job changes. The folks who are signing out 10M-digit candidate exponents from the primenet server are also contributing to the QA effort, intentionally or not. Due to the dropout of some of the volunteers, we have some open exponents, so I'm now looking for some more volunteers. Here's a repost, with minor edits, of the call for volunteers from September 1999: I am looking for about 10 additional ambitious & very patient QA testers with extremely fast hardware, and some significant free storage space, to participate in runs on selected exponents in the larger fft runlengths. The selected exponents will frequently be fully trial factored, or nearly so. Though many may be prime95 or mprime users, this is not a requirement, and participation of users on nonIntel cpus is encouraged. Participants in this phase of the QA should be willing to coordinate by email with a partner, running LLtests and double-checks of the same exponent in parallel, and cc George Woltman and myself, interim residues at suitable intervals. Interim files (which can each be sizable) should be preserved until interim residues of a later interim check are known to match. (Ideally all interim files would be kept, at intervals of 1-2 million iterations, until an exponent is completed & double checks ok.) Participants should agree to sign on for at least 6 months, preferably much longer, and to transmit the last valid intermediate file or interim file to an ftp server if quitting, or when necessary for debugging. (Note, the upper end, 79,300,000, takes an estimated 6.5 years on a PentiumII-400, 24x7x365, nonstop on an idle system. A good backup strategy is highly recommended for the higher exponents.) Participants should agree to install version upgrades that may be required from time to time, waiting a day or more to ensure it's a stable version, and migrate the tests in progress to their fastest available hardware as hardware upgrades are made. (It may be possible to get partial cpu-time credit for partially LLtesting an exponent that is then completed by someone else but this is not guaranteed. This could be an extra administrative headache for George Woltman and myself.) In exchange for all this time and trouble, testers will have a reduced chance of finding a prime and a delay in receiving cpu credit (due to the long runtimes), but get a shot at completing primality tests of exponents unlikely to be surpassed for some time, and the satisfaction of making a contribution to the reliability of and confidence in the program. The purposes of this endeavor are: 1) Add to the list of known, checked residues, some entries in currently very sparse or completely empty runlengths (ahead of checkout & result return by typical GIMPS & Primenet users) for qualification of v19 prime95 & its variants, future versions, & other software. 2) Verify the long term operation accuracy of prime95 v19 and its relatives (and later versions) in the new longer runlengths. 3) Gain experience with the tandem-running approach. 4) Have fun. Volunteers, please respond by email to me with the following information: Your full name your email address your preferred runlength(s) how many exponents you'd like to take on in each runlength Description of cpus available for QA testing, as in the hypothetical example below, to judge suitability of cpus for various exponents: Name CPU OS RAMavailable (hr/day)/(day/wk) xyzPII-500 WinNT (build 1381 SP5) 128MB 24/7 aAlpha21264-600 TruUnix Vxxx 512MB 15/5 +24/2 5; various Celeron500 Win95 128MB 24/7 omega 4xPIII-600 WinNT 4sp5+hotfixes 256MB 24/7 (CPU descriptions will not be shared among participants or with the mail list.) Ken (Tester of the currently 2nd, 3rd, 4th, & 5th highest single-LL-tested exponents; Cotester of the highest doublechecked exponent:M15,500,057.) _ 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
At 02:55 AM 2/27/2000 -0800, Paul Leyland <[EMAIL PROTECTED]> wrote: >BJB wrote: > >> Yes - I think we need this database - with or without savefiles, >> it's a waste of effort to inadvertently duplicate work done before. >> Since P-1 is deterministic (like trial factoring, but unlike >> Pollard's rho or ECM) you should get the same result every if you use >> the same limits on the same exponent. > ... > > >The degree of freedom in choosing an elliptic curve for ECM is probably what >you're hinting at. I'd suggest that a database of number of curves at run >each B1/B2 limit is still useful. George keeps such a database for small >exponents. > > >Paul It's my understanding that the choice of curve is randomized intentionally, and that the space of possible curves for each exponent is so large that it is more efficient to check random curves than to attempt to eliminate the very small chance of calculating the same curve more than once. This approach is used not only in GIMPS, but in George's implementation of Richard Crandall's program for searching for factors of Fermat primes. It is not necessary or advisable to run all possible curves. In fact, for F16, my runs produced in sequence, the following seed numbers, many of which found the factor 825753601: Attacking 2^65536 + 1 Selecting elliptic curve seed s = 1561883045: Selecting elliptic curve seed s = 630999867: Selecting elliptic curve seed s = 1921480920: Selecting elliptic curve seed s = 1664751173: Selecting elliptic curve seed s = 671100398: Selecting elliptic curve seed s = 2008555722: Selecting elliptic curve seed s = 112071784: Selecting elliptic curve seed s = 1157242418: Selecting elliptic curve seed s = 690847237: Selecting elliptic curve seed s = 823396944: Selecting elliptic curve seed s = 1372799571: Selecting elliptic curve seed s = 244007149: Selecting elliptic curve seed s = 2013596788: Selecting elliptic curve seed s = 1958155050: Selecting elliptic curve seed s = 441279715: Selecting elliptic curve seed s = 248788694: Selecting elliptic curve seed s = 831355685: Note that they go to at least 2 x 10^9. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re:
At 10:24 PM 2/16/2000 +0900, "Kotera Hiroshi"<[EMAIL PROTECTED]> wrote: >Hi all >Is a decimal 23-digit numbers 111 prime ? >Could you tell me the answer with proof? > >24-digit numbers = 101*1100110011001100110011 > >regards For the smaller numbers get ubasic and run aprt-cle.ub. It shows it is prime. Also included with ubasic is ecm.ub and many other programs. The numbers above are repunits. Repunits with nonprime number of digits are provably nonprime. (This is why the mersenne search only considers prime exponents. If a number has n identical digits r in some number base b, it's a repunit, and if n is factorable into i and j, the number has at least factors f and g: f=sum from k=0 to i-1 of r b^k and similarly g=sum from k=0 to j-1 of r b^k) since the nonprime number above has 24 digits, it's divisible by more factors than you show. By inspection, we can see it's divisible by 3; its digit count is divisible by 2, 3, 4, 6, and 12, predicting divisors of 11, 111, , 11, and . Note not all of these are prime either. Prime Factorization by ECM Input an integer =? 3 * 7 * 11 * 13 * 37 * 73 * 101 * 137 * 9901 * 0001 aprt-cle.ub Finds first factor or indicates primality. Accepts numbers of form 2^727-1 but apparently not x / y "APRT-CLE" is the extended version of "APRT-CL" Cohen-Lenstra version of Adleman-Pomerance-Rumely Test programmed by Koichiro Akiyama 1988 2 12 modified for UBASIC version 7 by Yuji KIDA 1989 1 31 & 1989 3 30 amended by Frank O'Hara 1990 1 28 extended to 844 digits using extra memories by Yuji KIDA 1991 9 30 extended to 844 digits WITHOUT using extra memories by Frank O'Hara 1991 12 13 rearranged by Yuji KIDA 1992 1 24 Hmm. These numbers are in a sense the decimal analog of mersenne numbers. I get primes for # of digits n=2,19, 23 and no others below 72, and first factors for the nonprimes (of prime length) as follows: n f 3 3 5 41 7 239 11 21649 13 53 17 2071723 29 3191 31 2791 37 2028119 41 83 43 173 47 35121409 53 107 59 2559647034361 61 733 67 493121 71 ? Other than the special case 3, the factors above are all of form f=2kn+1, like for mersenne numbers. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Double-Checking
At 04:46 PM 2/10/2000 -0800, you wrote: >Do ALL exponents get Double-Checked? ...or are only selected exponents >done because the original LL run was suspect? > >Just curious, >Russ Suspect exponents get done earlier. All are to get double checked eventually. A mersenne prime is not said to be proven the Nth mersenne prime until after all prime exponents below it have matching double or triple or higher checks. (Single checks showing compositeness could be in error, hiding another prime.) For QA test purposes, due to poaching, or because of errors in multiple runs, quite a few get triple checked and a few get quadruple checked. Assume that a set of 400,000 exponents get single checked, and double checked, and the error rate per check is 0.5%. If the error occurrence is independent, that means about 4000 will not match. Of these 4000 then the triple checks would have errors in about 20, and require a quadruple check which most likely would match one of the previous results. Already double or triple checked exponents make the best check values for a new program. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: pi
At 08:35 PM 2/9/2000 -0500, <[EMAIL PROTECTED]> wrote: >It would take infinite area of an infinitesimally thin layer of paint, which >would have no volume due to its thinness. Since paint can't be infinitely >thin, >this also means you can't actually fill the object with paint, because there >will be volume in areas into which paint molecules can't fit. > >Mike Filling the horn with paint has a couple additional problems: since it is an infinitely long capillary, filling time would be infinity^4 or so (laminar flow conductance being proportional to diameter^4 and inversely proportional to length) A realizable section of Gabriel's horn would necessarily be lumpy when constructed of real material. Think of a tube constructed of soccer balls glued together. If the horn inner diameter is a kilometer, great, it looks pretty smooth. (Say for the sake of argument the diameter of these soccer balls is 3 decimeters.) But further along, where the inner diameter has fallen off to one meter, it's beginning to look pretty lumpy already, and when inner diameter drops to 1 decimeter, the tube roughness is very significant. Now move out to where the inner diameter is 1 Angstrom, and the atoms of which the wall is constructed are 3 Angstroms diameter, and it looks the same. I'm surprised noone responded about continued fractions to Ian Halliday: At 10:42 PM 2/9/2000 +1300, [EMAIL PROTECTED] wrote: >Over history, there have been numerous other approximations to the value >of pi. Our current culture seems to favour 22/7 as an approximation, and >the Biblical approximation above suggests 333/106. However, this is not >the best available in three digits, which is, so far as I know, 355/113, >which is correct to an astonishing one part in ten million. I understand >that in certain quarters, 3 1/7 was not in vogue, with 3 1/8 favoured. >What, argued these particular mystics, could be a better number than >five squared shared by two cubed? N P Smith asked whether we should be >more concerned by those who serious propose answers which are clearly >wrong or by those who spend time in repeatedly refuting these spurious >claims. PI~=3.1415926535897932384626433832795 subtract the integer part, take the reciprocal of the rest, and iterate, to produce the continued fraction's coefficients. Reassemble successively increasing numbers of terms, until the rational number obtained is sufficiently accurate. This is an effective method of determining gear ratios approximating arbitrary reals. 3+ 1 / (7 + 1/(15+1/(1+1/(292+1/(1+1/(1+1/(1+1/(2+1/(1+1/(3+1/(1+1/(14+1/(2+1/(1+... ))) 3= 3 4= 3 +1 3.14 2857142857... =3+1/7 = 22/7 3.1 25 = 3+1/(7+1) = 25/8 3.1415 09433962264150943396226415... =3+1/(7+1/15) = 3 + 15/106 = 333/106 3+1/(7+1/(15+1/)) =355/113, see below 3.141592 9203539823008849557522124... =3+1/(7+1/(15+1/1)) = 3 + 1/(7+1/16)= 3+1/(113/16) = 3+ 16/113 = 355/113 3+1/(7+1/(15+1/(1+1)))= 3.1415 525114155251141552511415525 3+1/(7+1/(15+1/(1+1/292))) = 103993/33102 = 3.141592653 0119026040722614947737 3+1/(7+1/(15+1/(1+1/293)))= 3.141592653 9214210447087159415927 3+1/(7+1/(15+1/(1+1/(292+1/(1+1/1) = 3.141592653 4674367055204547853492 3+1/(7+1/(15+1/(1+1/(292+1/(1+1/(1+1)) = 3.141592653 6189366233975003014106 3+1/(7+1/(15+1/(1+1/(292+1/(1+1/(1+1/(1+1))) = 3.1415926535 583573009183052053374 3+1/(7+1/(15+1/(1+1/(292+1/(1+1/(1+1/(1+1/2))) = 3.14159265358 1012044193065819 3+1/(7+1/(15+1/(1+1/(292+1/(1+1/(1+1/(1+1/(2+1 = 3.1415926535 914039784825424142193 3+1/(7+1/(15+1/(1+1/(292+1/(1+1/(1+1/(1+1/(2+1/(1+1)= 3.14159265358 70561991705458087813 3+1/(7+1/(15+1/(1+1/(292+1/(1+1/(1+1/(1+1/(2+1/(1+1/3)=3.14159265358 9 3891715436873217069 3+1/(7+1/(15+1/(1+1/(292+1/(1+1/(1+1/(1+1/(2+1/(1+1/(3+1))=3.1415926 53589 8153832419437773074 3+1/(7+1/(15+1/(1+1/(292+1/(1+1/(1+1/(1+1/(2+1/(1+1/(3+1/2))=3.14159 2653589 6274836288508219852 3+1/(7+1/(15+1/(1+1/(292+1/(1+1/(1+1/(1+1/(2+1/(1+1/(3+1/(1+1/14)))= 80143857/25510582=3.14159265358979 26593756269457122 Ken Ken Kriesel, PE <[EMAIL PROTECTED]> _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Why 2K?
Punched cards didn't have to be readable Hollerith; the maximum storage per card was 80 12-bit columns, or 960 bits when binary punched. The average card is about .006" or so thick by 3 by 8". (About 6700 bits per cubic inch of card; compare that to a CD in its case at 440,000,000 bits/cubic inch.) We still use the cards in our machine shop; they're quite handy for temporary shims, keeping metal parts from marring each other, etc. Ken At 08:41 PM 2000/01/12 -0500, George Woltman <[EMAIL PROTECTED]> wrote: >>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 > _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Strange Prime95 behavior. Can anyone explain ???
At 05:15 PM 1999/12/04 +, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: >On Sat, Dec 04, 1999 at 08:55:02AM -0500, Olivier Langlois wrote: >>Yesterday, my Prime95 client have contacted the Primenet server to get more >>work to do and since then, my client stopped to do the LL test on the >>unfinished prime M7943231. > >From what I can see, your computer has started factoring another number. >This is completely normal (see the README file). Once the factoring is done, >Prime95 should continue your LL-test. > >The reason for this behaviour is, that if it was to complete the LL test, >and then quickly find a factor for the next number, you would suddenly be >left with no work left :-) > >>33233791 * 32 0.5 1437 64.5 04-Dec-99 >>01:55 358BeaubienE > >This seems to be the number. Note that it's only factored to 32 bits, and >probably will be factored to 67 bits (just a guess, there are tables for >this) before the LL test continues. > >/* Steinar */ The table below is from a posting by George Woltman some time ago: Numbers above are factored to - --- 71002^72 57022^71 44152^70 35102^69 28132^68 21592^67 17852^66 13382^65 825 2^64 Trial factoring runtime can be very significant. For example, M33233791 will take a few weeks on a Pentium-200. (But, if it finds a factor, that could shrink to mere seconds.) Ken Kriesel _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: splitting up 10m digit primes
At 07:49 AM 1999/10/19 +0100, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: >On Tue, Oct 19, 1999 at 12:28:52AM -0500, Ken Kriesel wrote: >> How would you extend this concept to P-1, ECM, and factoring save files? > >As far as I'm aware prime95 is the only program to do P-1, ECM or >factoring so I wasn't intending that the save files should include >these. Maybe they should? Surely there are other programs. There must be various factoring efforts running on non-Intel processors under non-Microsoft operating systems. >> Would revisions to the standard format be handled within the 8-byte >> Ascii file identifier, or in a separate field? > >There was a 4 byte number for revisions at the start of the header. I took the 4-byte number present in your first recent post to be the version information of the program that generated the file, not the file standard version. After rereading Brian's comments and your reply to him, I think I get it; Brian's modification adds the program version levels, and the original had the standard's version. (Feeling fuzzy from the flu, please pardon the increased noise level.) Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Smallest unfactored composite (was types of work to request...)
At 02:22 AM 1999/10/16 -0700, Greg Hewgill <[EMAIL PROTECTED]> wrote: >Suppose you were keeping such a list. With one bit (prime vs not-prime) to >represent each number up to 10^15, you would need approximately 10^14 bytes of >storage, which is on the order of 100 terabytes. That would be your first >problem. The second problem would be if you were to present me with the >smallest number that was not factored, I could almost immediately present you >with a factorization (or show that it's prime). The data becomes pretty sparse in bitmap format. With a little work we could do quite a bit better than that. First, the evens greater than two are known composite, so they need not have bits representing them. Second, the primes rapidly get sparse enough that it is more effective to record in several bits, the gaps between primes, or a multilevel lookup, than a simple yes-no table one bit per odd number. Third, if the usual data compression methods are more effective than such a table construct, we could use those compression methods. To answer Gordon Bower's question, very partially, Hans Riesel wrote (in Prime Numbers and Computer Methods for Factorization, 1985, Birkhauser) that in 1909 D N Lehmer published a factor table and prime table covering up to 10,017,000, and in 1959 C L Baker and F J Gruenberger published a table containing the first 6 million primes (all those below 104,395,289). And there have been a few posts if I recall correctly of how little time it takes on a modest speed computer to sieve up to 2^32 (~4,000,000,000+) http://www.utm.edu/research/primes/ contains a link to the Nth prime page at http://www.math.Princeton.EDU/~arbooker/nthprime.html "Enter 1 for the first prime (2), 2 for the second (3), on up to 1 for the trillionth prime (29,996,224,275,833)." So presumably the region that has been exhaustively searched for general primes is well above 3x10^13. Can someone else out there answer more precisely? On Fri, Oct 15, 1999 at 01:03:57AM -0800, Gordon Bower wrote: > PS - On an unrelated note --- what is the smallest natural number that is > not known whether it is prime or composite? Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: splitting up 10m digit primes
How would you extend this concept to P-1, ECM, and factoring save files? Would revisions to the standard format be handled within the 8-byte Ascii file identifier, or in a separate field? Ken At 08:22 AM 1999/10/17 +0100, Nick Craig-Wood <[EMAIL PROTECTED]> wrote: >Some time ago I proposed a standard format for save files. It also >had the advantage that it only saved the actual bits used so would >make the save files 1MByte rather than 1.8 MByte for an 8,000,000 >exponent in prime95. (much omitted, see Nick's original post) _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Mprime in dual cpu setup?
At 06:14 PM 1999/10/14 -0400, "St. Dee" <[EMAIL PROTECTED] wrote: >If I run a single instance of mprime, I get LL iteration times on exponents >near 8,200,000 of about .220. If I run two instances of mprime, each gets >iteration times of around .245. I expected some hit, but I have no idea if >that is too big of a hit or not. Curiously, I did notice that when the box >was doing some factoring to 64 bits, it didn't seem to make any difference >in the factoring times whether I had one or two processors crunching. Sounds like a typical hit. With Prime95 & Prime95 or NTPrime LLtesting, hits are typically Pentium-MMX 18% Pentium Pro 20% Pentium II 10-12% Individual motherboard/cpu combinations can be affected up to 25% by choice of RAM type (at least on pentium, FPM vs EDO) % performance hit is expected to vary with FFT size due to varying cache effectiveness. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: # of digits in 2^p-1
Look it up in the FAQ listed at the bottom of every mailing list message, is best in my opinion. Ken At 09:15 PM 1999/10/14 -0400, Darxus wrote: > >What's the best way of finding the number of decimal digits for the number >2^p-1 ? > >__ >PGP fingerprint = 03 5B 9B A0 16 33 91 2F A5 77 BC EE 43 71 98 D4 >[EMAIL PROTECTED] / http://www.op.net/~darxus > Join the Great Internet Mersenne Prime Search >http://www.mersenne.org/prime.htm > > >_ >Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm >Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Vaxen & Intel
At 12:03 PM 1999/10/12 -0400, Jud McCranie <[EMAIL PROTECTED]> wrote: >At 12:54 PM 10/12/99 +1000, Simon Burge wrote: >>"John R Pierce" wrote: >> >> > a year on one of these [a vax] wouldn't equal one day on a pentium-II. >> >>Probably a bit generous there even, given that older vaxen wouldn't >>have pipelined FPU's so you might get one result every 10 (or perhaps >>even 100) clocks, as opposed to one result almost every clock on modern >>hardware. > >In his book "Programming Pearls", Jon Bentley gives the figure of 570 >seconds for sorting 10,000 integers on a VAX-11/750. My PII-300 does it >1160 times faster and my C-400 is 1780 times faster. But that is comparing >working with integers instead of FP. Hmm, a vax3900 is definitely not slower than a 780. The original Vax was the 780, followed by the slightly slower 750, both designed in the 1970's. A VS2000 was a tiny, almost shoebox size vax, and those were about 780 speed. A VS3100-38 (circa 1990) was about 4 x a 780; a VS4000-60 was about 12 times; I think a 4000-90 was about 30 times. My recollection was that for multiple precision programs in integer in C, a VS3100-38 was about half the speed of an Intel 386-33 with cache, and a VS4000-60 was about the equal of a 486-33. What sort algorithm are those figures for? In what programming language? Which compiler? There are lies, damned lies, and statistics. Then there are benchmarks... Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: splitting up 10m digit primes
As I posted some days back; Anyone who wants to quit an exponent after investing a PII-400-month or more, please contact me, and we'll try to carry it on, using it for the QA effort. It could take some major bandwidth-minutes if more than a few exponents are quit, however. Ken At 04:15 PM 1999/10/12 EDT, [EMAIL PROTECTED] wrote: >Well, as completion time gets longer and longer, it becomes more likely that a user will give up in disgust. This could be after several months of work is already complete. > >How about an option when you hit "QUIT GIMPS" to upload your P and Q files to Primenet, so someone can at least finish the job? _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Stopping and starting NT services from a command line or batch file?
At 10:52 AM 1999/10/11 -0600, "Alan Vidmar" <[EMAIL PROTECTED]> wrote: >Anyone know how to start or stop NT services from a command line or >batch file? > >Thanks, >Alan Yes. (And, in anticipation of the followon question "How?";) net start "servicename" net stop "servicename" where servicename is the case-sensitive name displayed by Control Panel's Services menu (eg, net stop "Prime Service") or that displayed by typing net start with no parameters (which gives a list of the currently running services). For more info try net help start net help stop The service must be not disabled, and the process running the command must have adequate permissions. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: If quitting big exponents (was Re: Decamega Tests)
At 11:42 AM 1999/09/23 +0200, Philippe Trottier <[EMAIL PROTECTED]> wrote: >HI! > >Anyone thought of sending these P and Q once a month to the server.. in the >case where someone would abandon a quest, it could be continued by someone >else ... That capability doesn't exist in the Internet Primenet Server at this time. Anyone contemplating quitting an exponent after more than a PII-400-month, please save the files and contact me. We'll try to make use of them in QA. Ken Ken Kriesel, PE <[EMAIL PROTECTED]> _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: New roundoff record?
Not quite the same thing, but my personal high, in 4001 exponents tested, is FATAL ERROR: SUM(INPUTS) != SUM(OUTPUTS), 4.637189956e+013 != 1.744531645e+022 Roundoff is normally bounded by 0.5 even when the calculation of residue goes hugely awry. Ken At 04:47 PM 1999/09/30 +0200, Steinar Gunderson wrote: >After overclocking my poor 400 MHz PII to 496 MHz (and upping >the voltage from 2.00V to 2.30V), I figured out I should perhaps >do a torture test for a few days, before throwing it at my real >exponents :-) After 10 seconds, I got: > >Test 1 of 15, 400 Lucas-Lehmer iterations of M19922945 using 1024K FFT length. >ERROR: ROUND OFF (5.283699122e+13) > 0.40 >Possible hardware failure, consult the readme file. > >Has anybody experienced any _bigger_ roundoff errors than this? _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factors Everywhere
At 11:46 AM 1999/09/26 +0100, you wrote: >6) PrimeNet trial factoring has moved well into the 10 millions, >however George's factor.zip file contains data only up to 10 million. >I know there is a problem with uploading the large files concerned; >hopefully, the suggestions above will help to reduce the size of the >file, sufficiently to make it feasible to expand the exponent range >to cover (at least) the active Primenet assignments for long enough >for cheap, high-speed Internet connectivity to become widespread. > >7) I have several hundred megabytes of disk space available on my ftp >server, which has reasonable Internet access - at least 8 Mbps >connectivity to the Internet core - and would be happy to provide >means for anyone interested to upload factoring data (or anything >else, strictly relevant to Mersenne or closely-related numbers) for >the purpose of making it publicly available. I encourage you to implement this central repository. Something that would have accelerated parts of the QA process is the ability to query such an online resource for information such as the following: What is the smallest exponent larger than n that has no factor found when factored to 2^m (possibly but not necessarily gimps default depth)? What is the largest exponent smaller than n that has no factor found when factored to 2^m? What are the exponents with double checked residues between a and b? What are the exponents with double checked residues between a and b whose residues are from separate chip architectures and software (Eg, Intel & prime95 for one, Alpha & MacLucasUnix for the other)? What are the exponents with singly checked residues between a and b? (I suppose one could consider doing very short factoring tests to fill gaps when queries ask for an exponent's factor status; something like up to 2^40, and add it to the database at that time; not a requirement.) Something that might aid development of new prime search software would be: What are all the known factors larger than 2^m? What are all the known factors between 2^m and 2^n for exponents between a and b? It is not the raw data, so much as the query response, that needs human-readability. Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: QA testers call
At 09:36 AM 1999/09/23 -0700, Paul Leyland wrote: >Hi Ken, that's a challenging project you're proposing. > >I'm very nearly tempted by this one, but the 6-year run time is a bit >daunting. In the past I've devoted months to a single factorization but >I've no real idea what I'll be doing in six years time or what hardware I'll >have access to. To clarify, it is not a requirement that individual volunteers stay with the project the full run-time of the exponents they're working on. If/when quitting before completion, pass the intermediate file & interim files on to those carrying on from there. I've been hunting mersennes since 1985, so the odds are I'll stick with it a while, barring major unexpected events. >It's also not clear what the payback will be. The payback is that known-results exponents in completely new territory will be available against which any mersenne codes developed can be tested. The odds are low, but it's a nonzero probability that a prime could be found in the process. >However, I've not yet completely ruled out volunteering, but need a bit more >incentive and a bit more information. For instance, how big are the files >I'd need to keep around, and how many for how long? (Note: file sizes appear to be the runlength size (ie: 112K = 114,688) x 4 plus 18 bytes for v18 and 22 bytes for v19) For v19: Exponent FFT,K Size of 1 save Limit file, bytes 199 96 393238 2323000 112 458774 2655500 128 524310 329 160 655382 3935000 192 786454 4598000 224 917526 525 256 1048598 6515000 320 1310742 773 384 1572886 902 448 1835030 1032512 2097174 1283640 2621462 1527768 3145750 1785896 3670038 2040 1024 4194326 2533 1280 5242902 3010 1536 6291478 3510 1792 7340054 4025 2048 8388630 4990 256010485782 5940 307212582934 6900 358414680086 7930 409616777238 >Space, per se, is not a >real problem (as long as it's not more than, say, 10Gb) but having to keep >them safe for years means ensuring they are backed up and so forth. When we >did RSA-155 my contribution to the relations (about 1/6 of the total) took >800Mb when compressed but needed to be preserved only for a couple of months >and the copies at CWI acted as my backup, and vice versa. To work a worst case example, 79,300,000 run at InterimFiles=100 would leave 80 copies (79 interims & the final) x 16MB or 1.3GB. It isn't necessary that any one person among the testing volunteers store more than a few exponents interim file sets, unless they are running many exponents in parallel. >Another question: how hard are you planning to try to factor Mersenne >numbers? With an effort you are planning, it would make sense to me to >spend a cpu year or so trying to factor. Right; we are factoring to the default v19 depth, enough exponents to get at least 3 LL-testable candidates in each runlength. >This *can* be trivially >parallelized and I would be happy to contribute to this phase. With the >resources I have, I can spend a PII-400 year factoring every week or two. I >don't mind slipping in that much between my regular jobs. Paul, I'll be sending you some candidate exponents to continue factoring to the full depth. Ken Ken Kriesel, PE <[EMAIL PROTECTED]> _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: QA testers call
I am looking for about 20-50 additional ambitious & very patient QA testers with extremely fast hardware, and some significant free storage space, to participate in runs on selected exponents in the larger fft runlengths. The selected exponents will frequently be fully trial factored, or nearly so. Though many may be prime95 or mprime users, this is not a requirement, and participation of users on nonIntel cpus is encouraged. Participants in this phase of the QA should be willing to coordinate with a partner, running LLtests and double-checks of the same exponent in parallel, and cc George Woltman and myself, interim residues at suitable intervals. Interim files (which can each be sizable) should be preserved until interim residues of a later interim check are known to match. (Ideally all interim files would be kept, at intervals of 1-2 million iterations, until an exponent is completed & double checks ok.) Participants should agree to sign on for at least 6 months, preferably much longer, and to transmit the last valid intermediate file or interim file to an ftp server if quitting, or when necessary for debugging. (Note, the upper end, 79,300,000, takes an estimated 6.5 years on a PentiumII-400, nonstop.) Participants should agree to install version upgrades that may be required from time to time, waiting a day or more to ensure it's a stable version, and migrate the tests in progress to their fastest available hardware as hardware upgrades are made. (It may be possible to get partial cpu-time credit for partially LLtesting an exponent that is then completed by someone else but this is not guaranteed. This could be an extra administrative headache for George Woltman and myself.) In exchange for all this time and trouble, testers will have a reduced chance of finding a prime and a delay in receiving cpu credit (due to the long runtimes), but get a shot at completing primality tests of exponents unlikely to be surpassed for some time. The purposes of this endeavor are: 1) Add to the list of known, checked residues, some entries in currently very sparse or completely empty runlengths (ahead of checkout & result return by typical GIMPS & Primenet users) for qualification of v19 prime95 & its variants, future versions, & other software. 2) Verify the long term operation accuracy of prime95 v19 and its relatives (and later versions) in the new longer runlengths. 3) Gain experience with the tandem-running approach. 4) Have fun. Volunteers, please respond by email to me with the following information: Your full name your email address your preferred runlength(s) how many exponents you'd like to take on in each runlength Description of cpus available for QA testing, as in the hypothetical example below, to judge suitability of cpus for various exponents: Name CPU OS RAMavailable (hr/day)/(day/wk) xyzPII-500 WinNT (build 1381 SP5) 128MB 24/7 aAlpha21264-600 TruUnix Vxxx 512MB 15/5 +24/2 5; various Celeron500 Win95 128MB 24/7 omega 4xPIII-600 WinNT 4sp5+hotfixes 256MB 24/7 (CPU descriptions will not be shared among participants or with the mail list.) Ken _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: FDIV Pentium error
Poke's post sounds like a troll, but what the heck, I'll respond. At 08:43 PM 1999/09/21 -0700, poke wrote: > >All programs are affected by the FDIV bug. No. Not all programs use the FPU. Some that do, do not use instructions affected by the bug. >It is a bug in the design of >the microprocessor. Yes. But there was a recall program of about a year's duration, back when the P5-100 was the fastest rated speed that Intel sold. >Linus has a way around it. >The brain dead morons at Microsoft have to make everyone else wait >for a solution >(That has yet to come AFIK). Microsoft announced patches years ago, for FDIV error workarounds in their operating systems of the time, as well as the calculator applet and the Excel spreadsheet. >Linux on the other hand usually has problems solved in a >matter of hours. Microsoft does regression testing of patches before releasing. They don't always get it right on the first release of their patches, but the variety of combinations that face them is mind-numbing. It's hard to imagine that a thorough regression testing could be performed in a few hours. This is not meant to be flamebait; just stating the facts as I recall them. I know and respect coworkers who regularly use Linux, and occasionally use it myself. >-Chuck > > > >On Tue, 21 Sep 1999, Floris Looyesteyn wrote: > >> I was wondering if Prime95 is affected by the Pentium >> FDIV bug. (or some name like that). My recollection is Prime95 is unaffected. Will Edgington had not at that time detected any factors missed due to the pentium FDIV bug. George and I had a conversation about workarounds for the pentium FDIV bug 3 June 1996. Here are some old URL's I included then. See http://pentium.intel.com/procs/support/pentium/fdiv/swpatch/patch.txt This includes the personal names of the discoveror and other early investigators. See also a couple levels up from that page for more info. Also: http://www.free.net/ftp/systems/pentium/division.letter for someone else's approach to the calculate both ways and check method. http://almond.srv.cs.cmu.edu/afs/cs.cmu.edu/project/verify/www/srt-bdd.html search April issues of Dr Dobb's journal for an article by Time Coe. http://enigma.db.erau.edu/~flynnt/pentium.html for a FAQ. Also has Nicely matl. Nicely discovered the flaw. http://www.mathworks.com/README.html "The Pentium Papers", many links. coe.txt and pratt.txt are worth reading. also moler_6 and moler_7. http://www.mathworks.com/Moler_7.txt If you detect a buggy pentium, you must shift your operands out of the situation where the known-bad bit pattern occurs in one of the divide attempts. The gist of it is, scale operands by 3 to ensure differing bit patterns, and there's a sizable performance hit. >> I ask this because now i'm also using it on my laptop >> (great work george!) and when i installed linux some time >> ago it said the processor had this bug. >> >> Floris Looyesteyn Ken Ken Kriesel, PE <[EMAIL PROTECTED]> _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Iters between screen outputs
At 10:29 PM 1999/09/15 +0200, "Shot" <[EMAIL PROTECTED]> wrote: >Hi all, > >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. > >So I boldly went where no man has gone before ;) and changed it to 1 >i/o... and the times still stayed between 0.429 and 0.431 s/i. > >The question is, how much of the CPU's power is consumed by screen >outputs? Hardly anything these days, with fast pentiums and smart video cards. But on 486's & 386's it was significant. I have systems where it's set to 5 iterations, and systems where it's set at 1000 iterations. It all depends on system speed, exponent size, and desired update frequency. Ken Ken Kriesel, PE <[EMAIL PROTECTED]> _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Prime95 version 19 - better late than never
At 07:57 PM 1999/09/09 -0400, George Woltman <[EMAIL PROTECTED]> wrote: >Hi all, ... >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. I count 24 bugs found (excluding items I'd categorize as wishlist items, misunderstandings about the expected behavior or the program, and those errors that were not reproducible). Omitted from the above list of QA team members was Arthur M. Coucouvitis. To all the QA team members: Thanks for all the time and thought contributed. The task is large, with numerous new features, and 67 FFT lengths by my count. I plan to continue the qa process after v19 moves from prerelease status through beta to general release, until every FFT length has at least one successfully double-checked exponent, or a later prime95 version is released. I hope you will continue with us. Ken Ken Kriesel, PE <[EMAIL PROTECTED]> _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: the QAtesters list is closed
To keep the group a manageable size, I'm closing it for now. Ken Ken Kriesel, PE <[EMAIL PROTECTED]> _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Prime95 V19 QA testers
Did I miss anyone who wishes to participate in the Quality Assurance testing of Prime95 V19? To reach the QAtesters group for prime95 v19, use this list (in alphabetical order by last name): Brian Beesley <[EMAIL PROTECTED]>, "Jean-Yves Canart" <[EMAIL PROTECTED]>, Marc Getty <[EMAIL PROTECTED]>, Alex Healy <[EMAIL PROTECTED]>, Ken Kriesel <[EMAIL PROTECTED]>, Shane Sanford <[EMAIL PROTECTED]>, Gordon Spence <[EMAIL PROTECTED]>, "Joth Tupper" <[EMAIL PROTECTED]>, Guillermo Ballester Valor <[EMAIL PROTECTED]>, "Willmore, David" <[EMAIL PROTECTED]>, George Woltman <[EMAIL PROTECTED]> Ken Ken Kriesel, PE <[EMAIL PROTECTED]> _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: Multiple residues - enhancing double-checking
At 03:01 PM 1999/08/04 -0600, "Aaron Blosser" <[EMAIL PROTECTED]> wrote: >I think we could keep it simple by just saving every x% iteration's residue >(in truncated form). Using a WAG of saving it every 10% along the way, >you'd only have 9 partial and 1 full residue when all is said and done. > >So for an exponent like 8027219, you'd save the partial residue at the 10%, >or 802722th iteration (rounding up or down as normal). Of course, the >number of iterations varies just slightly from the exponent, but >whatever...you get the idea. > >These partial residues could be sent (for the first LL test) during the >check-ins, or saved up and all sent at once when the test is done. The 2^n least significant bits of the residue make a good check value, since once the modulo operation begins to have an effect, the lsb's quickly change. It is essential to have agreement among different programs, on exactly which iterations' residue LSB's are to be saved. This encompasses both the save interval in iterations, and agreeing on whether the starting value of 4 is iteration 0, 1, 2, etc., as well as agreeing on the starting value, which can be other values besides 4 according to the math. It is more efficient but not necessary to have agreement on how many bits to save. Even n=4, 2 bytes, gives a fairly good error detection rate, but n=6, 8 bytes is much better! I suggest that the number of iterations between residue saves be made a function of the FFT length, since those scale with the runtime for a given cpu. As we move to exponents that require months even on fast machines, we will see an increase in the rate of erroneous results per exponent on the same hardware and same small error rate per execution hour. We will eventually reach exponents with runtimes long enough that the system hardware reliability drops significantly before an exponent completes, due to hardware aging! My feeling is that a P-90-month is about the right interval at which to kick out intermediate residues of 64-bits or so. In a case where two runs are taken to completion, for a large exponent, such that dozens of interim residues are recorded for the first LLtest and for the second, the third tie-breaker need only be run to the point where the first two diverge and the third agrees with one but not the other. On average this will save about half the third-test, which now we need about 1% of the time, but in a few years we may need much more often. By shortening the third-test duration before we can make a comparison, it halves the probability of the third-test being in error and so lessens the amount of time spent on fourth-tests. This saving will also become more significant at higher exponents. Total runtimes are going up drastically. When I joined GIMPS in mid 1996, runtimes per exponent were 12 hours (572k on a P-120). Soon we will have the capability to run exponents requiring more than 12 months on PIII-500's. >> Might the v.17 problem have been trapped with something like >> this? I do not >> recall enough of the discussion to know and the ensuing belly-aching >> overshadowed the real content of finding/fixing/reworking. (I know I am >> never going to rise high on the list, so I do not worry a whole lot about >> how much my report shows.) There is another trick for dealing with the v17 shift bug, which I've suggested to George Woltman. Before the modulo kicks in, the rightmost 2n+2 bits should follow a set pattern that is calculatable for n< log(2)p or so. Math wizards, please be kind re errors in what follows. In hexadecimal, the first several iterations for any value P of current interest follows a predictable pattern. The pattern persists until the result of an iteration grows larger than Mp, and so is independent of P for a time. L(n+1)=Ln^2-2; (using the convention here that we iterate from 2 to n) n hex Ln binary Ln 2 4 3 E 4 C2 1100 0010 5 93021001 0011 0010 6 5468 4C020101 0100 0110 1000 0100 1100 0010 7 1BD6 96D9 F03D 3002 ... 1101 0011 0010 least significant 64-bits only below: 8 8cc8 8407 a9f4 c002 9 5559 9f9d 37d3 0002 10 f460 d65d df4c 0002 11 e180 d807 7d30 0002 12 9bdb 491d f4c0 0002 13 4ceb b477 d300 0002 etc for all n I found to check, where Mp> Ln, & Ln<=2^(2^(n-1)); Mp>2^(2^(n-1)) 2^p>2^(2^(n-1))+1 p>2^(n-1) log(2)p+1>n log(2)33,219,281=24.985>n log(2)5,000,000=22.25>n (In practice I've found the limits at low n occur at slightly lower p than expected.) That is, the rightmost 2(n+1) bits begin with binary 0011, then in the middle there are 2(n-2) zero bits, then a 1 and another 0. For exponents 16,777,215http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Frequency of residue error (was Mersenne: Down With The Evil Thread)
At 12:29 AM 1999/07/27 EDT, [EMAIL PROTECTED] wrote: >Hello, again. As before, I'm replying to a bunch of different people. And I >have trouble thinking up decent subject lines as well. :-] ... >fact that (barring bugs), the likelyhood that the numbers produce the same >64-bit residue is very, very low. Probably somewhere between 2^-64 and >2^-128.>> > >Ah, a product of my own brain drain. You're right, I stand corrected. So, >does the rate of needed triple-checks conform with what a 1% error rate per >test would indicate? (i.e. 1% * 1%, I think.) Something close to that, although the %-per-check is believed to be an increasing function with p. One would expect that of forty thousand LLtests and double checks, a few occurrences of both being wrong for the same p would occur, and that is what we've found; there were some months back, questions raised about a short list of exponents which had 3 tests done and no matches found, requiring (at least) a 4th test. George Woltman's estimates of about 1 in 100 were posted March 5, 1999, and made a distinction between V17 error rates and earlier versions. I wonder if the V17 statistics were affected by the shift count bug discovered later. Prior to this there was a thread October 13-15, 1998 about when triple-checking fails to produce matching residues. (Two residues wrong by random error would produce separate residues not matching a hopefully correct third residue, necessitating a _fourth_ test to hopefully obtain a match.) At that time, for exponents below 2,000,000, there were about 40,000 double checked exponents which appeared to fit a 1 in 100 independent error rate. A plausible distribution for that would be: about 99%, 39600 where first and second were both right about .99%, 396 where a third test produced a match about .01%, a few where triple-testing produced no match of those last few, likely all would be matched after a fourth LLtest. One might need a fifth or higher test, but at low odds (~4%) All those figures are sensitive to the actual error rate, of which 1% is only an approximation. ><<1) What is the approximate P-90 computing time to test for primality >for a 1, 10, 100 million (& 1 trillion!) digit Mersenne Primes?>> .589 seconds/iteration for a 1-million decimal digit mersenne prime, or about 23 days, assuming the use of prime95. For the other sizes of exponents, no released version of prime95 supports running such high exponents. Runtimes can be estimated as roughly p~=#digits/log10(2) t/t0= p^2 log(p) / (p0^2 log (p0) ) Then: digits P90yrp90sec/iter 10^6.062 .589 10^7 7.23 6.87 Hardware failure before completing 1 test is a risk 10^8 826. 78.5 Someone will surely poach the exponent before completion 10^9 93000. 883.5 (The EFF's big money appears to be safe!) Ken [EMAIL PROTECTED] _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: Mp and E-Cash
An additional relevant point: I think Duncan Booth's name at least ought to be considered when discussing the $ split. He wrote the first version of primenet server and client; Scott Kurowski continued from the starting point that Duncan provided. I suspect that Scott has considerably more total effort invested, but part of that is as a business venture. At 11:46 AM 1999/07/25 +0100, you wrote: >[Not in reply to any specific message - no names, no pack drill] > >Hey, guys, surely we don't want a war over this? > >Here are a few relevant points: > ... >If anyone really wants to start testing 10 million digit Mersenne >numbers now, I would at least urge them to obtain exponents from >George, in order to prevent unneccessary duplication of effort. [If >George can't be bothered, I'll volunteer to do this task!] Hear, hear. The above point also applies to exponents below the 10-million-digit mark. ALL exponents should be checked out. Ken ([EMAIL PROTECTED]) _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: The sound of number searching
Magnetostriction is about a bulk material changing dimensionally with varying magnetic field; this is probably not occurring or not the prime mechanism. More likely, it's simply that the magnetic fields generate forces acting on the currents in the coils, and the coils and neighboring structures are not infinitely stiff, instead acting as a low efficiency speaker. Another mechanism is piezoelectricity: the ability of materials to undergo dimensional change as a result of static electrical fields. I've seen high voltage capacitors piezoelectric enough to damage their own leads over time. Thermal effects in thin board traces can be fast enough also to be audible. If you really want to find out what area of your PC is producing the sound, use the auto mechanics trick of putting one end of a flexible hose to your ear and the other end near a suspected sound source, taking the usual precautions for your safety and your PC's. This is a FAQ item though lesser priority. Checking the archives at January 28, 1999 gives some discussion of hardware-specific symptoms, and suggestions. Earlier mentions are at August 15, 1996; December 9 1996; January 25 1997; April 14, 1998. At 03:24 PM 1999/07/22 -0500, "Willmore, David" <[EMAIL PROTECTED]> wrote: >All, > >There are several things in a computer which will have their operational >parameters vary with CPU activity. The most likely ones are: audio >subsystem receiving noise coupled either directly (magnetically) into its >signal lines or via its power feed; or the load on the power regulation unit >itself. Yes, coils do can make a buzzing sound. The name of the phenomina >is 'magnetorestrictance' (who wants to be I spelled that one wrong?) which >is the property of a material to change its physical dimensions under >varying magnetic fields--it's the reason large power transformers 'hum' and >how most high power sonar units generate their signals. > >If I remember correctly, this is an IFAQ, but could go in the FAQ so that >the-word-which-will-go-unmentioned can get spelled correctly once and for >all. > >Cheers, >David >_ >Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm >Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers > _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Squaring algorithm...
Assuming you're talking about doing it on a conventional computer
(1 or few processors, fixed word length, etc.), the method you propose
is at least O(2^p * p ) per squaring. This is dominated by
the first exponential term, which must be avoided at all costs.
Huge constant factors can be accepted to get down from exponential time
to polynomial time; brute-force ("schoolboy") multiplication is "only"
O(p^2). (There squaring has about a 2:1 advantage over multiplication.)
The minimum possible for fixed word length is bounded by the
FFT approach at O(p * log(p) * log(log(p) ) from above, and
O(P * log(p) / (log(log(p)))^2 ) from below under certain severe restrictions.
These two limits are not far apart since log(log(p)) hardly moves at all;
p ln(p)ln(ln(p))
15 2.708050201102 0.9962288929514
1,000,00013.81551055796 2.625791914476
5,260,00015.47564158471 2.739267277143
33,000,000 17.31201811943 2.851400949303
800,000,000 20.50012228563 3.020430851279
The average length of the numbers to be added is p-1/2 bits;
for a word length w, each addition takes O(log(n)/w) operations.
And there are O(2^p) such operations.
Each term must be generated, and the amount of memory that must be allocated
for the counter is large.
Take p around 33,000,000; the counter requires 33,000,000 bits storage.
This will not fit in second level cache; 4MB cache PCs are rare.
Storing the sum will take at least that, if you apply the modulo along
the way; otherwise, twice that.
The count n will take O(2^33,000,000) clocks.
Compare that count, to the number of picoseconds since native Americans
put the early pictographs on the rocks of Sedona Arizona:
7000 years *365.24 days/year *24 hours/day *(3600 * 10^12) picoseconds/hour
=2.2*10^23 picoseconds =~ 2^77.55 picoseconds. A picosecond is the time
it takes light to travel in vacuum the diameter of a 300 micron dot.
At 10:47 AM 1999/07/22 -0600, <[EMAIL PROTECTED]> wrote:
>Just was thinking the other day about this... Forgive me if its been
>discussed before etc.
>
>Aren't there other "better" algorithms for finding the square of a number
>besides using an FFT? Sure an FFT is great for multiplying two different
>numbers, but for squaring a number isn't the case a little different. Plus,
>going off what I've read on FFT's, it runs in O(n log n) time.
>
>So wouldn't a summation algorithm work better.
>
>For example, to find the square of a number k take the sum of n=1 to n=k of
>2n-1.
>
>So 3**2 is 1+3+5 = 9
>4**2 is 1+3+5+7 = 16
>etc...
>
>So the sqaure performs in O(n) time. Plus, you could already throw in the
>sub 2 by starting at -1 instead of 1. And figuring out the mod is just as
>easy.
>
>k is the sum of n=2**p-1 to n=k of 2n-1 (This would give k**2 - 2**p-1).
>
>The only hassle is adding *big* numbers up, but I'm not sure how the
>ramifications of doing carries across boundaries and such would factor into
>the equation etc.
>
>Just a thought.
>
>-Jeremy
>_
>Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
>Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
>
_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Squaring algorithm...
Assuming you're talking about doing it on a conventional computer
(1 or few processors, fixed word length, etc.), the method you propose
is at least O(2^p * p ) per squaring. This is dominated by
the first exponential term, which must be avoided at all costs.
Huge constant factors can be accepted to get down from exponential time
to polynomial time; brute-force ("schoolboy") multiplication is "only"
O(p^2). (There squaring has about a 2:1 advantage over multiplication.)
The minimum possible for fixed word length is bounded by the
FFT approach at O(p * log(p) * log(log(p) ) from above, and
O(P * log(p) / (log(log(p)))^2 ) from below under certain severe restrictions.
These two limits are not far apart since log(log(p)) hardly moves at all;
p ln(p)ln(ln(p))
15 2.708050201102 0.9962288929514
1,000,00013.81551055796 2.625791914476
5,260,00015.47564158471 2.739267277143
33,000,000 17.31201811943 2.851400949303
800,000,000 20.50012228563 3.020430851279
The average length of the numbers to be added is p-1/2 bits;
for a word length w, each addition takes O(log(n)/w) operations.
And there are O(2^p) such operations.
Each term must be generated, and the amount of memory that must be allocated
for the counter is large.
Take p around 33,000,000; the counter requires 33,000,000 bits storage.
This will not fit in second level cache; 4MB cache PCs are rare.
Storing the sum will take at least that, if you apply the modulo along
the way; otherwise, twice that.
The count n will take O(2^33,000,000) clocks.
Compare that count, to the number of picoseconds since native Americans
put the early pictographs on the rocks of Sedona Arizona:
7000 years *365.24 days/year *24 hours/day *(3600 * 10^12) picoseconds/hour
=2.2*10^23 picoseconds =~ 2^77.55 picoseconds. A picosecond is the time
it takes light to travel in vacuum the diameter of a 300 micron dot.
At 10:47 AM 1999/07/22 -0600, <[EMAIL PROTECTED]> wrote:
>Just was thinking the other day about this... Forgive me if its been
>discussed before etc.
>
>Aren't there other "better" algorithms for finding the square of a number
>besides using an FFT? Sure an FFT is great for multiplying two different
>numbers, but for squaring a number isn't the case a little different. Plus,
>going off what I've read on FFT's, it runs in O(n log n) time.
>
>So wouldn't a summation algorithm work better.
>
>For example, to find the square of a number k take the sum of n=1 to n=k of
>2n-1.
>
>So 3**2 is 1+3+5 = 9
>4**2 is 1+3+5+7 = 16
>etc...
>
>So the sqaure performs in O(n) time. Plus, you could already throw in the
>sub 2 by starting at -1 instead of 1. And figuring out the mod is just as
>easy.
>
>k is the sum of n=2**p-1 to n=k of 2n-1 (This would give k**2 - 2**p-1).
>
>The only hassle is adding *big* numbers up, but I'm not sure how the
>ramifications of doing carries across boundaries and such would factor into
>the equation etc.
>
>Just a thought.
>
>-Jeremy
>_
>Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
>Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
>
_
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
At 08:13 PM 1999/07/20 -0700, you ("Daniel Swanson" <[EMAIL PROTECTED]>)wrote:
I got the following set of messages today: [Tue Jul 20 16:15:19 1999]
Iteration: 6128000/7812379, ERROR: ROUND OFF (0.4026489258) > 0.40
Possible hardware failure, consult the readme file.
Continuing from last save file.
[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? Thanks, Dan Swanson
The calculations are done in the fft using an irrational base, then converted
back to integer form by rounding. The amount of rounding is monitored. Well
away from the size breakpoints, the roundoff may only be thousandths, or less.
The FFT size breakpoints are determined by estimates of how high an exponent
can safely (without roundoff error) be run on the shorter faster size.
When roundoff exceeds 0.4, it is possible that a memory error or cpu error
caused it. It's also possible that the roundoff was actually greater than 0.5
and rounding to an incorrect integer has occurred. Exponents near fft size
breakpoints, or any that generate both the roundoff error and the reproducible
message are therefore somewhat more likely to fail a double check, and so are
candidates for earlier double checking.
Nonreproducible roundoff errors mean hardware may be unreliable;
reproducible roundoff errors mean fft size breakpoints (& LLtests) may be
unreliable.
Ken
_ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: re: Mersenne prime exponent binary representations and 1's frequency (incl M38)
I said: >The incidence of 1's in the second place from the right (excluding >p=2) is 16/(16+21)=43.2%; This indicates the degree to which Mp for p=1 mod 4 is more probably prime than is p=3 mod 4. Of Mp for p=3 and up, p mod 4 # % 1 21 56.8 3 16 43.2 >the incidence in the remaining interior bits is 172/358=48.0% This last line was wrong. For p=3, the second bit from the right is what I've been calling an exterior bit (most significant or least significant). So the one bit for p=3 should not be subtracted from either the one bit's count or the total bit positions counts for interior bits. So the correct incidence in remaining interior bits is 173/359~=48.2%. Credit for spotting this error goes to, who else, but George Woltman! George asks, what about the bit second from the left? In total, 26 0 bits vs only 12 1 bits. (0 26 of 38 times or ~68.4%; 26/12=2.1...) Excluding p=2 and p= 3, to look only at interior bits, 25 0 bits vs only 11 1 bits; 0 25 of 36 times, ~69.4%; 25/11=2.2727...) Now why would that be, that a 0 bit is more than twice as likely as a 1 bit? (Note that Mp#38, M6972593, has the less likely 1 bit in the second most significant position; searching biased for these probabilities would have delayed finding it. But the 4 previous Mersenne primes all had a 0 bit in that position.) Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Mersenne prime exponent binary representations and 1's frequency (incl M38)
The latest mersenne exponent is added below. positionp in p# ofbitp in hex p mod 4 in list base 10 in base 2 1's places 1 2 10 1 2 2 2 2 3 11 2 2 3 3 3 5 101 2 3 5 1 4 7 111 3 3 7 3 5 131101 3 4 D 3 6 17 10001 2 511 1 7 19 10011 3 513 3 8 31 1 5 51F 3 9 61 01 5 63D 1 10 89 1011001 4 759 1 11 107 1101011 5 76B 3 12 127 111 7 77F 3 13 521 101001 3 10 209 1 14 607 100101 7 10 25F 3 151279 100 9 11 4FF 3 162203100010011011 6 12 89B 3 172281100011101001 6 12 8E9 1 183217110010010001 5 12 C91 1 194253 110011101 6 13 109D1 204423 1000101000111 6 13 11473 219689 10010111011001 8 14 25D91 229941 10011011010101 8 14 26D51 23 11213 1010001101 9 14 2BCD1 24 19937 1001101 8 15 4DE11 25 21701 101010011000101 7 15 54C51 26 23209 101101010101001 8 15 5AA91 27 444971010110111010001 9 16 ADD11 28 86243 1010111100011 8 17 150E3 3 29 110503 1101010100111 12 17 1AFA7 3 30 132049 1000010001 7 18 203D1 1 31 216091 11010011011011 9 18 34C1B 3 32 75683910111000110001100111 11 20 B8C67 3 33 85943311010001110100101001 10 20 D1D29 1 34 1257787 100110011000100111011 11 21 13313B 3 35 1398269 10101010101011101 14 21 1555FD 1 36?2976221 1011010110100111011101 14 22 2D69DD 1 37?3021377 10111110100101 9 22 2E1A41 1 38?6972593 11010100110010010110001 11 23 6A64B1 1 total 263 471# 1's=21 # 3's=16 We'd expect the leading and trailing bits to be 1's except for the sole even, accounting for 75 1 bits and 76 places. The remaining "interior" bits are 1's 188 times out of 395, or 47.6%. Up through 3021377 it was 47.9%. With 2976221 it was 48.6% of the time. Without M2976221 it was 47.9%. The incidence of 1's in the second place from the right (excluding p=2) is 16/(16+21)=43.2%; the incidence in the remaining interior bits is 172/358=48.0% Largest run of 1's: 8 (p=1279) Largest run of 0's: 7 (p=132049) Highest percentage of 1's: 100% (p=3,7,31,127) Lowest percentage of 1's: 30% (p=521; just one more bit than the minimum) Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Re: digits vs exponents FAQ
At 09:09 AM 1999/06/29 -0400, Jud McCranie <[EMAIL PROTECTED]> wrote: >At 04:16 AM 6/29/99 -0400, Lucas Wiman wrote: >>All, >>Here is version 1.1 of the FAQ. > >Here's a question that needs to be addressed: how to go from digits to >exponents, and exponent to digits. By all means include it in the faq; there's been too much repetition, including wrong responses, now and in past months. Here's a draft: Sometimes it is useful to know the relationship between the exponent of a mersenne number and the number of digits it has in some number base. How do we calculate in either direction? (q) How many digits are there in the binary representation of 2^n-1 (or any number 2^(n-1) <= x <= 2^n - 1) ? (a) n Examples: n=1, 2^(1-1)=2^0=1= 1(2); 2^1-1= 1 =1(2). n=2, 2^(2-1)=2^1=2= 10(2); 2^2-1= 3 = 11(2). n=3, 2^(3-1)=2^2=4= 100(2); 2^3-1= 7 = 111(2). n=4, 2^(4-1)=2^3=8=1000(2); 2^4-1= 15 = (2). Hey, a pattern's emerging here. (q) How many digits are there in the hexadecimal representation of 2^n-1? (a1) int((n+3)/4) (a2) take the number of binary digits, divide by 4, then round up. (q) How many digits are there in the decimal representation of 2^n-1 ? (a) D = int(n * log_10_(2) + 1); log_10_(2) ~= 0.301029995664 = log (base 10) of 2 Examples: n=1, int(1* .3010... + 1) = 1; n=2, int(2* .3010... + 1) = 1; n=3, int(3* .3010... + 1) = 1; n=4, int(4* .3010... + 1) = 2; ... n=10, 2^n-1=1023; int(10*.3010...+1) ~= int(4.01029995664) = 4; n= 3321925, int(3321925* .3010...+1) ~= int(100.068346) = 10^6 n= 33219281, int(33219278* .3010...+1)~= int(1000.1123) = 10^7 n= 332192807,int(332192807*.3010...+1)~=int( 1.2508)= 10^8 n= 3321928095,int(3321928092*.3010..+1)~=int(10.131)= 10^9 (q) What about in some arbitrary number base? (a) For base a as in arbitrary, 2^n -1 will have r digits where r=int(n*log_a_(2) + 1-epsilon), or rather r=ceil(n*log_a_(2)) (allowing for the base a to possibly be a prime number), Example: a=7, n=3, log_2_(7)~= 2.807354922058; log_7_(2)~= 0.356207187108 2^3-1= 7 = 10(base 7) Derivation: 2^n-1 <= a^r-1 or it won't fit in r digits in base a 2^n <= a^r n * log_a_(2) <= r (q) What is the minimum exponent n for 2^n - 1 to have at least D decimal digits? (a) 2^n-1 > 10^(D-1) -1 2^n > 10^(D-1) n > log_2_( 10^(D-1) ) n > log_2_(10) * (D-1); log_2_(10) ~= 3.321928094887 Examples: D=1, n> log_2_(1); n> 0 D=2, n> log_2_(10); n> 3.321...;2^4-1=15; 2^3-1-7 D=3, n> log_2_(100); n> 6.642...; 2^7-1=127; 2^6-1=63 D=10, n> log_2_(10)*9; n> 29.897... 2^30=1,073,741,824 D=100, n> log_2_(10)*99; n>328.87.. 2^329= 1.093625362392e+99 D=1000, n>3318.6 D=1, n>33215.95 D=100,000, n>332189.48 D=1,000,000, n> 3321924.772959 D=10,000,000, n> 33219277.62694 D=100,000,000, n> 332192806.1668 D=1,000,000,000, n> 3321928091.565 Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: M38 guess
Make my guess for M38, p~=6,740,000 Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: status of exponents
At 09:01 PM 1999/06/10 -0400, you wrote: >The status page shows that for exponents in the range 3,310,000-3,960,000, >there are 225 exponents for which 2 L-L tests have been done, yet there are >40 exponents for which no factor is known, and no LL test has been done. I >have 2 questions: > >1. Why have 2nd LL tests been done in many cases when there are still >exponents whose status is unknown? > >2. Exponents over 6,000,000 have been assigned for a couple of months or >so. Why are large exponents being assigned when there are still smaller >ones in need of a LL test? The Internet Primenet Server is not the only pool of exponents. Some people are getting exponents manually assigned via the webpage; I get mine by email from George. I request exponents below 5,260,000 because that's what I'm mostly set up to run, with a separate primenet V2.x server and numerous v14.4 clients. One of the blocks I've been assigned by George includes 3,960,000, which is currently issuing rapidly. When an exponent gets put on a slow machine and nears the bottom of the untested-once list, I move its intermediate result files to a fast box to accelerate achievement of the next GIMPS milestone. Several other Intel cpus I run which are 200Mhz and up are busy running 1 or 2 full LLtests in each run length, also reserved by email from George. After all, the IPS won't issue in the upper ranges yet, so testing ahead of the pack for QA purposes requires other means. Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: [Re: Mersenne: Serious problems with v.18]
At 08:23 AM 1999/06/05 MDT, Paul Derbyshire <[EMAIL PROTECTED]> wrote: >Peter Doherty <[EMAIL PROTECTED]> wrote: > >> This is normal. Because of the bug in v17, all the math it was doing >> was wrong, so using that 77% would have been a waste since it was >> incorrect data. There is no need to try and retrieve that data. It's >> useless. > >Are you sure of that? What if the bug didn't happen to strike my run, or the >errors could be corrected? > >If what you say is true, then whoever designed version 17 acted in a >completely unconscionably rash manner by releasing it without thoroughly >testing it for problems as serious as that. And has therefore shot the whole >GIMPS effort in the foot by setting it back many weeks. > As I recall, there were times when new versions of primenet or prime95 were needed by a certain date to prevent exhaustion of all exponents below the usable limit. Remember that all code development is by volunteers, primarily George Woltman for prime95, and Scott Kurowski for primenet. I do not have you on my list of QA testers or code reviewers. Would you like to participate in helping V19 meet the code quality you desire in this free software? Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: New Mersenne Prime found!! Not yet verified
At 06:49 PM 1999/06/03 -0700, Paul Burnett <[EMAIL PROTECTED]> wrote: >At 08:47 PM 6/2/99 Ken Kriesel wrote: > >>The EFF requires that they approve the specific publication and referee >>process > >...otherwise the newly discovered Mersenne Prime isn't "officially" a >Mersenne Prime? Fascinating! (Or is this just for the prize?) Just for the prize award. As someone said, "It's their money, so they get to make the rules." That's pretty standard. Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: New Mersenne Prime found!! Not yet verified
At 07:13 PM 1999/06/02 +0100, [EMAIL PROTECTED] wrote: >Presumably a statement of fact in a news column in, e.g., "Nature" >is sufficient, rather than a full-blown paper. For that, all that would >appear to be needed is the number, the names of the discovery >and verification teams, dates and possibly some brief details of the >hardware & software used. The EFF requires that they approve the specific publication and referee process; see section 4F of http://www.eff.org/coop-awards/award-prime-rules.html (and may perform verification themselves also). "We strongly recommend that you submit your paper to the Mathematics of Computation." EFF also requires publication prior to submission for the prize. The AMS site says they are backlogged 3 issues as of May 31. And it's a quarterly even in electronic form, according to http://www.ams.org/cgi-bin/bookstore/bookpromo.pl?fn=20&arg1=mcom&item=99MCOME >George - is DS doing the verification run again - or is this also >"restricted information" at the moment? >Regards >Brian Beesley Presumably the practice of simultaneously notifying all past discoverers of mersenne primes, and then multiply double-checking the result has been used. It would be no big deal to double-check p~6,000,000 since p~7,300,000 is under 3 weeks on a PII-400, and PIII-550's are on the market. Of course you know that already, Brian, having Alpha's that could do it easily. Ken Here's what George said some time back. Also, verification is done on a program and typically a processor architecture different than the discovery. >Return-Path: [EMAIL PROTECTED] >X-Authentication-Warning: acid.base.com: majordomo set sender to owner-mersenne using -f >X-Sender: [EMAIL PROTECTED] >Date: Thu, 29 Jan 1998 14:08:55 -0500 >To: [EMAIL PROTECTED] >From: George Woltman <[EMAIL PROTECTED]> >Subject: Mersenne: Re: Announcement Policy >Cc: Scott Kurowski <[EMAIL PROTECTED]> >Sender: [EMAIL PROTECTED] > >Hi, > >The results of my informal, non-scientific survey are as such: > >5 voted for keeping a new prime secret until verified. >3 voted for full disclosure. >15 voted to announce as unverfied, but keep the actual exponent secret. > >It looks like the middle-of-the-roaders win. > >So here is my proposed future announcement plans: > >1) When a new prime is reported, the primnet server will email all >previous Mersenne Prime discoverers as well as Chris Caldwell and >Richard Crandall. This essentially stakes GIMPS claim. > >2) I will download the server log files and see if the verification >code from the results file is correct. Someone will need to crack the >server's security codes and prime95's security code to falsely get our >hopes up. Hopefully hackers have better things to do with their time. > >3) I will email this mailing list with the news and a rough idea of where >the exponent is. The server's statistics page will show one unverified prime >reported. I will keep the actual discoverer's name secret until >the prime is verified. > >4) We all wait together for the verification. > >Best regards, >George Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Screen saver killers?
At 09:10 PM 1999/05/14 +0200, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: >OK, second message in a row, I just thought it would be nice to separate them. > >Has anybody got experience in turning off/disabling screensavers under Win95? >We run Prime95 at 40 machines (most of them 486'es, though) at school, and >screen savers are CPU hoggers (I suppose... at least everybody tells me so). >Two solutions I could think of (both ideally incorporated under Win95): > >1. Have Prime95 reset the screen saver every 5 minutes or so (possibly when > it's outputting) to `Blank Screen'. Would need fiddling with the Registry. >2. Do a call to mouse_event() or keyboard_event() (possibly hitting Ctrl, or > any not-so-important key, or moving the mouse one pixel), preventing the > screen saver from being run at all. Prime95 already has priority levels that are settable. The default is lower than screensaver, but you don't have to run at default setting. Have a look at the readme.txt for Prime95 V18.1 (or any version at least since V14.4 which had command line argument -P settable 0 thru 5, where 3 is equal to screensaver priority and 0 is near the level of the idle loop). Especially avoid the use of OpenGL screensavers; these are very cpu-intensive, and run at higher priority than remote (network) file access, for network- based backup, for example. Putting both intermediate files and the prime95 executable file on a file server is a nice way to ensure work is backed up, updating executables is straightforward, and space used is efficient. It does have the disadvantages of requiring someone logged in unless the security configuration is unusually lax, and presents a single point of failure. (When the server reboots, all 40 instances of prime95 stop but may appear to still be running until a mouse cursor crosses the prime95 icon.) An alternative is to write a script which normally copies the pq* files from local disk to server space, at whatever interval you prefer. They get backed up with the server, so if ghost wipes the workstation clean, you can easily restore an exponent that's 90% complete. As we move upward in exponents, this will be of increasing interest. The script runs when there's a logged in user. In general, if you'd like to automate a task in Win95/NT, take a look at Winbatch from Wilson Windoware; it's very handy for some things. Another possibility is Active State perl. Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Any statistics majors out there?
Aren't gaussians symmetric about the mean value? What George plotted is not. At 12:00 PM 1999/05/08 -0400, you wrote: > >> though. So outside about 14 sigmas you should be able to say the >> probability is below 10e-40. The problem is that if there are small >> deviations from "Gaussian-ness" way out on the wings of your distribution, >> the REAL probability of a certain result is not well approximated by the >> Error Function result. > >This is a real good point - if we are assuming a Gaussian distribution, then >we are assuming the best case. The worst case is given by Tchebycheff's >theorem, which states that, given a probability distribution where only the >mean and standard deviation is known, then the probability that an >observation will fall more than x standard deviations from the mean is >bounded above *only* by 1/x^2. (It's a tight bound for one value of x, but >with a very unlikely distribution). In other words, if you have no >guarantees about the distribution, "counting sigmas" is going to give you a >false sense of security, and if the distribution is even slightly deviant >from Gaussian, then the result can be very wrong indeed. > >However we do have a little comfort. George's function - maximum convolution >error from a single iteration - does have some distribution. It "appears" >bell-shaped, and looks like a normal distribution, the samples George has >made are also reasonably-sized. Not only that, each observation is actually >the maximum of the deviations from integer over many channels in the FFT - >in other words, the observations are already coming from a "smoothed" >distribution. I'm sure the distribution of a maximum of several observations >is something which there is a statistical test for. (The resulting >distribution may not be normal, but may have an analogous test). > >Thanks too Todd for backing up the heuristic calculation of "14 sigmas" that >I got the hard way :) > >Chris > > > >Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: volunteers & nominees for the QA effort
Here is the list to date of volunteers. If I missed anyone, or understated or overstated your areas of involvement, please reply offline to me, and I'll update the other participants in a single summary message. George Woltman <[EMAIL PROTECTED]> is in it by default, as a code developer and tester (presumably on Win95 and NT) Any additions George? George nominated (drafted?) the next two: Richard McDonald <[EMAIL PROTECTED]> PPC-based MAC client software (MacGIMPS) developer "Ernst W. Mayer" <[EMAIL PROTECTED]> DEC Alpha & SGI client software (lucas_mayer) developer In somewhat random order are those who volunteered themselves: Guillermo Ballester Valor <[EMAIL PROTECTED]> linux win95 pentium166mmx QAtest Basic, Fortran, assembler (for I86X), C and C++ "Brian J Beesley" <[EMAIL PROTECTED]> Run QA tests - on Intel Pentium II under Windows 95 & NT WS 4.0 - on Alpha 21164 under Red Hat Linux 5.1 - maybe on Intel Pentium II under Linux, later Help design QA tests Help keep testing databases & provide statistics. Can provide filestore to assist with this. Will assist in any coding which may be necessary I'm less happy about reviewing code, but I'll give it a bash if necessary Shane Sanford <[EMAIL PROTECTED]> QAtest & C/C++ code MS Visual C/C++ 4.0,5.0, & 6.0; P2 450 196 meg ram access to Win95a/Win95b/Win98/NT 4.0 Ken Kriesel <[EMAIL PROTECTED]> NT4 and win95 now, linux eventually assorted systems including 486-66, pentium, dual-pentium, dual-pentiumpro, pentiumII-400 QAtest generating full LLtests under prime95 v14.4, v16.3, v18.1, and others. Nick Craig-Wood <[EMAIL PROTECTED]> http://www.axis.demon.co.uk/ suggests his ARMprime program as another means of independent-architecture and program test results "Jean-Yves Canart" <[EMAIL PROTECTED]> QAtest PentiumII-266 with unspecified OS So to reach the QAtesters, use this list: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> And for the code reviewers or developers: <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>,,<[EMAIL PROTECTED]> Ken Ken Kriesel (resident of Madison WI, last year's #1 city and this year's #7) Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Whoa on the preventive measures thread
I agree with George, this discussion should go offline. My original message on the V17 bug and preventive measures was intended as a call for volunteers in two categories (skilled code reviewers, and QA testers with cpu time to burn) There have been a number of ok, good, and very good points made. But I think many on this list could do without the large volume of posts (about ways to do auto updates, for example). I've contributed to the bloat myself. Mea culpa. I see what features to include or not include in Prime95 and its relatives, and primenet, as in the hands of their respective creators, and beyond the scope of the QA project. All these items might be better handled with direct email correspondence rather than broadcast through the mailing list. I request that people who want to review GIMPS C code or assembly code, run QA tests, help design QA tests, do statistics on test results, or work in more than one area, say so in private email to me but not to the mailing list. QA testers are encouraged to list what operating systems and hardware they are willing to test on. In several days I will summarize it in a single message to the list. If someone wishes to participate, but not be publicly listed in the summary for whatever reason, say so in your email to me. Ken Kriesel [EMAIL PROTECTED] Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
RE: Mersenne: preventive measures
At 12:45 PM 1999/04/11 -0600, Aaron Blosser wrote: ... >IE4 and IE5 have that (probably Netscape too?), and I think the web site >that checks and sends emails is www.mindit.com. mindit.com is not the one I was thinking of; there's one based in a US university (Dartmouth?). >> This combined with being able to remotely stop an NT service and deposit >> updated files from a batch procedure on one workstation makes managing >> large numbers of workstations practical and quick. > >Remember, you're talking to a guy who installed thousands of instances of >NTPrime remotely, across 3 different states, in a matter of days (using >nothing more than 4NT batch files and RCMD/NETSVC programs from the resource >kit). But we won't go there. :-) I'm not saying it can't be done, but it'd >be so much easier with some sort of built-in method for self-updates. I remember. It can be done with less (just what's built in to NTWS). >> I would find a popup box a terrible nuisance, so I'd like an option >> to turn it off or on, with default off. > >If it were an option, there should be a way for REALLY important alerts to >get through, so that anyone running v17 would have been alerted about the >bug even if normal alerting were turned off. Wouldn't you rather have some >exceptions get through, with the decision about what qualifies as >"exceptional" being made by George and/or Scott? No. I would not want it popping up on each of my computers, requiring a mouse click on each; too tedious. Email is sufficient. A popup for each instance on each multiple-cpu system is really a nuisance. Imagine if USWest had seen 2500 of those popups on the same day. VIRUS!!! Lynch whoever's responsible!! >> The feature I'd like to see at some point is the LLtest code made dual-cpu >> aware ... >Amen. In fact, if it were possible to code it to split the work among >multiple CPU's in any way, then it *is* technically possible to have even >seperate machines work on the same number, though you'd be limited by the >network link speed. I think even gigabit ethernet would be insufficient. Networking means driver overhead. The point of doing it is to regain efficiency and reduce total runtime of one exponent so it's small compared to the machine's working lifetime, even for 8-digit exponents. >Consider. If you had a chip with multiple FPU engines, couldn't you code >the program to take advantage of that? From there, it's only a small step >to using the FPU processors on *seperate* CPU's, and from there, given a >fast enough link, seperate CPU's on entirely different machines. Several big if's. Factoring could easily be parallelized, since it consists of 16 passes. And the total amount of data being transported is very small. Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
RE: Mersenne: preventive measures
At 08:41 AM 1999/04/10 -0600, "Aaron Blosser" <[EMAIL PROTECTED]> wrote: >George...is it too late to request features for the new version? > >I had done some thinking on it, and wouldn't it be great if there were some >sort of "live update" feature, where it could upgrade itself when new >versions come out. That's pie in the sky and I remember discussing >previously how that wouldn't work for everyone - security issues, bandwidth >issues, etc. but perhaps if it were an option. This feature would have meant that V17 shift count bug would have cost the project more cpu years than it did. In my case, its impact is a little under 1 cpu year (one exponent in the 10.5M area) because most processors I'm running were at older versions. There is a publicly available service which checks for changes in web pages, and sends email when a checked page changes. I think Internet Explorer V5 supports some sort of favorite-page-change detection too. This combined with being able to remotely stop an NT service and deposit updated files from a batch procedure on one workstation makes managing large numbers of workstations practical and quick. >At the very least, I think that there should be an "alert" or other >notification of some sort when a new version comes out, rather than relying >on emails being sent. The problems with version 17 should give a good >example of how that would help. A problem is found with a version, or >simply a new faster version is out, so the next time Prime contacts >Primenet, it sees some flag set and pops up a box on the screen telling the >user about the new version. And a seperate option for how often to check >for "messages" besides the number of days between checking in at primenet to >update expected completion dates. I would find a popup box a terrible nuisance, so I'd like an option to turn it off or on, with default off. The feature I'd like to see at some point is the LLtest code made dual-cpu aware, splitting the load so one cpu does one half of the run-length and the other cpu does the other half, so that the onboard and on-chip caches would be more efficiently used, and total working set smaller, and exponents completed more quickly. I have a dual-pentium 200 MMX that isn't terribly fast when running two prime95 instances on exponents above 10^7. The performance on the dual-pentium or dual-ppro systems I have access to is, when running two instances, about 1.6 times that of running 1 instance. So there is some room for improvement. On this setup, there are 2 L1 caches, but one L2 cache being shared by two prime95 instances. Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: V17 bug discovery and preventive measures
Since George Woltman found and announced the bug in V17 prime95 and its relatives, which invalidates Lucas-Lehmer tests started by V17 for p>2^22 (=4194304) with a nonzero shift count, I've been thinking about some possibilities for making such bugs less likely to reach the general GIMPS user and to have less impact if it does. First, let me say that I think George, as well as Scott Kurowski, have done an extraordinary job with both code development and project coordination. The Lucas-Lehmer test is absolutely unforgiving of error. Writing a program that produces a correct residue after hundreds or thousands of hours on a fast Pentiumxx is a remarkable achievement. Doing it efficiently is another. Coordinating thousands of people running it somewhat independently and on numerous operating systems is another. Once the problem was known, the action to minimize future cpu-time loss was apparently prompt and vigorous. Program versions of Prime95 and primenet were previously developed quickly when GIMPS as a whole was running out of exponents to test (when the limit of the code was 5,260,000 rather than 20,500,000) or when the primenet server was experiencing growing pains. 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. 2. George and such other people as are qualified, determine which exponents make good test cases, based on a review of the code. 3. Volunteers with some cpu-power run LLtests and double-checks on the test cases selected. 4. Volunteers run randomly selected exponents LLtests and others run double- checks of the same exponents simultaneously. Random selection may hit a test case that's useful but was not identified as a separate case. Sequencing of this where possible would focus first on the exponent ranges already issued and next to issue from Entropia and the other primenet servers. 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. Ken Ken Kriesel (resident of Madison WI, last year's #1 city and this year's #7) Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Double-checking (was Chronons)
At 11:59 AM 1999/03/05 GMT, "Brian J Beesley" <[EMAIL PROTECTED]> wrote: >> (Ken wrote) >> Right. The odds heavily favor both mismatched residues being nonzero. >> A zero residue at the last iteration is what indicates primality. > >Depends on what you mean. If a Mersenne number that has been >tested once really is prime, but the test "went wrong", then we >have a wrong result i.e. calling the number composite when it isn't. I mean that nearly all mersenne numbers are nonprime even if the exponents are prime, so of the numbers we bother to LLtest, when an error occurs, the odds are 99%+ that it does not conceal an actual Mersenne prime. And in the unusal case of a nonprime Mersenne number being erroneously identified as prime, it would be multiply-checked and so the error caught, rather than being announced as a prime. >This is why double-checking is so important, if we want to find *all* >the Mersenne primes for exponents up to a given limit. I agree that double checking is important in an exhaustive search, and that exhaustive search (rather than haphazard or opportunistic search) is valuable. >There *might* be one or two lurking somewhere in the mass of >exponents which have only been tested once. >> >> >Also what causes the errors, bugs in the code? >> >> What I've seen most often is that prime95 and its relatives provide >> early warning of unreliable hardware, whether cpu, RAM module, or motherboard. > >Usually caused by overheating - failed CPU fan, poor ventilation or >excessively hot environment, overclocking, poor thermal contact >between processor substrate and heatsink ... The sorts of things I've seen include, in systems with good cpu heat sinking, multiple case fans, cpu fans properly installed and no overclocking: mechanically ill-fitting case causing a system to be unreliable unreliable single SIMM out of a set of 4 unreliable CPU chip unreliable motherboard whether these component-level problems were due to electrical stress (power outages, spikes, brownouts, static), thermal stress (overheating or too-frequent power on/off), or latent defects in manufacture is unknown. Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: mersennes for exocivilizations
At 07:42 PM 1999/03/06 -0600, "Robert G. Wilson v, PhD ATP" <[EMAIL PROTECTED]> wrote: > > >Ken Kriesel wrote: > >> >> Stating the exponents rather than the base10 representation seems to >> me to be almost the ultimate in data compression. (2^521-1 has 157 digits; >> the advantage increases along with the exponent, uh, exponentially.) >> > >2^p -1 is prime for the following ps: 2, 3, 5, 7, 13, 17, 19, 31, 61, 89, 107, >127, 521, 607, 1279, 2203, ..., 1257787, 2976221, 3021377, ... . But all of >these are primes. Two is the first prime, denoted as p(1), three is p(2), five >is p(3), etc. So therefore the best data compression is represent the Mersenne >primes is to denote the n, such that 2^p(n) -1 is prime for the following ns: >1, 2, 3, 4, 6, 7, 8, 11, 18, 24, 28, 31, 98, 111, 207, 328, 339, 455, 583, 602, >1196, 1226, 1357, 2254, 2435, 2591, 4624, 8384, 10489, 12331, 19292, 60745, >68301, 97017, 106991, 215208, 218239, ... , . The above is a steadily increasing sequence, which could be used to advantage. One could represent delta n for additional compression. 1,1,1,1,2,1,1,3,7,6,4,3,67,12,... has fewer bits. Then put the message through something standard like Huffman or LZH. The difficulty is that with each step the message becomes more obscure. And the essence of a message is to communicate something. Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Double-checking (was Chronons)
At 10:01 AM 1999/03/02 -0500, Paul Derbyshire <[EMAIL PROTECTED]> wrote: >At 02:01 PM 2/28/99 -0500, you wrote: >>Finding an error in the first LL test is not rare. I've said about 1 in >>200 are incorrect. > >Yeah, but most of those are "silent mutations" in nonzero residues, not >errors in the purported primality result, right? Right. The odds heavily favor both mismatched residues being nonzero. A zero residue at the last iteration is what indicates primality. >Also what causes the errors, bugs in the code? What I've seen most often is that prime95 and its relatives provide early warning of unreliable hardware, whether cpu, RAM module, or motherboard. >Is work being done on >finding subtle errors in the software? Yes, in the sense that for the first two+ years, double checking was done only on a different program on a different processor architecture than the original check, and currently some double checks do so still. Either programming errors or chip design errors would surface in that scenario. I've volunteered to run on Intel, one or two exponents in each run length to try out the code before the bulk of the GIMPS effort is routinely being assigned exponents in the higher run lengths. Perhaps someone running a different architecture would be willing to double check them. George has made provisions both to detect some errors and to prevent those from causing the loss of all work up to that point on the exponent. For example: Iteration: 3743629/5070277, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 5.26887446743531e+016 != 1.990777258736701e+016 Possible hardware failure, consult the readme file. Continuing from last save file. means an error has occurred and been detected, and to save the last few weeks' work, the last half hours' is discarded and tried again. >Are some of them, in the case of >Prime95, caused by Winblows? Iteration: 1407235/5070277, ERROR: ILLEGAL SUMOUT Possible hardware failure, consult the readme file. Continuing from last save file. Possibly these are software, according to George's readme.txt, under the section Possible Hardware Failure If it is software, it is not necessarily the fault of Windows or Microsoft. Could be a bum driver not doing things it should. >(IOW, are there more errors per P90 CPU hour >among Winblows boxes than among mprime boxes?) > >I figure only a small percentage of participants have actual faulty >hardware, and that spurious cosmic ray bit flips are caught by checksumming >of some kind. (Is that what ILLEGAL SUMOUT is, a checksum mismatch?) Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Re: Mhz
At 08:55 AM 1999/03/03 -0600, Ryan McGarry <[EMAIL PROTECTED]> wrote: >Actually, the 8088 ran at slightly over 8 MHz. The 8086, an earlier >version, ran at 4.77. An 8088 was my first computer... Ah. Memories. > >Ryan McGarry Actually, the IBM PC ran at 1/3 of 14.31818 Mhz, approximately 4.773Mhz. That crystal frequency was selected because it could be divided by 4 on the Color Graphics Adapter (CGA) to provide the TV color burst frequency 3.58Mhz and by 3 to be under 5Mhz, because IBM used 5Mhz-rated 8088 chips. The clock was further divided for several other functions, including serial port rates, system timers, etc. I owned an original IBM PC (64KB motherboard) for 15 years, and studied the clock circuitry well enough early on to split the clocks and hop the cpu up to 7.6 Mhz while leaving the 14.31818Mhz bus line & serial ports etc unaffected, after selectively desoldering a few 74xxx chips from the motherboard and replacing them with socketed 74ALSxxx equivalents and getting an 8Mhz NEC V20, while still using the 250ns soldered-in DRAM. There were multiple speed grades for each processor. The 8086 reached 10Mhz. The 80286 had grades from 4 to 16Mhz or higher; the 386 from 12.5 to 40Mhz; the 486 from 25 to 133, and the Pentium from 60 to 233. (Not all from Intel, and perhaps I have missed a speed grade here and there.) >1977: 1Mhz 6502 or 4Mhz Z80 (also the Vax 11/780; Mhz?) >1981: 4.77Mhz 8088 in the IBM PC >1984: 6Mhz in the IBM AT (and later, IBM released other models of the AT including an 8Mhz clock) Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
RE: MHZ (was re Mersenne: Fabs.)
At 07:36 AM 1999/03/02 -0800, Paul Leyland <[EMAIL PROTECTED]> wrote: >> >When I was working with some of the first digital designs in the >> >100-600 MHz range over 25 years ago... I suspect the original comment above relates to working with the simpler digital logic components of the day, not whole processors' clock rate. As a reference point, a 1985 Fairchild F100K ECL Data book mentions counters, registers, and flip-flops useful in the 400-500Mhz range. Schottky TTL of the same period was capable of about 100-125Mhz in flipflops. Special purpose devices such as frequency counter prescalers were available in the gigahertz range. (In July 1981 a 1250. Mhz prescaler chip could be had for $35.00.) The 1972 Radio Amateur's Handbook mentions both analog IC's (differential amplifiers) operating up to 100Mhz, and a prescaler operating up to 320Mhz. (A prescaler is a circuit that divides a clock pulse train down to a slower frequency by a fixed factor, such as by 10.) >> Oops. I don't know if this is an extra-zeroes issue or a "M" >> instead of a >> "K" or what, but just 10 years ago 1 MHz was good and 7 MHz >> was high end. >> 25 years ago, I very much doubt they were bandying about >> 600MHz anything, >> since we're only just reaching the 600MHz level now at the >> end of the 1990s! >> >> [Excessive quoted material snipped] > >[Excessive signature snipped 8-] > >Eh? My first job after finishing my DPhil was microcoding a AMD-2900 series >bit slice machine which had a 25ns (40MHz) clock. That was in 1983 and it >was far from rocket science then. Actually, I started (unpaid) work on it a >couple of years earlier, so we're actually talking about 18 years ago. > >The good old 1970's Cray-1 had a 9ns (110MHz) clock if I remember correctly. > >*Twenty* years ago, a 4MHz Z80A was a commodity chip. I still have a 1979 >model 380Z from Research Machines with that very cpu. (Incidentally, RM is >one of the few companies of that era still making PCs.) > >I can't remember when I bought my 25MHz 386, but it must be approaching 10 >years ago. > > >Paul 1977: 1Mhz 6502 or 4Mhz Z80 (also the Vax 11/780; Mhz?) 1981: 4.77Mhz 8088 in the IBM PC 1984: 6Mhz 80286 in the IBM AT 1986: 16Mhz 80386 in a Compaq 1990: 33Mhz 80386 (mine just turned 9 & still runs, with its third hard drive; the first drive cost about $10/MB) Mhz alone is not a direct measure of performance, even with equal word size. In 1983 I programmed a single-board PDP-11 clocked around 21Mhz in assembler, and since it had no multiply or divide instruction, it took about 480 microseconds to do a 16x16 unsigned integer multiply, which is far longer than the 30 microseconds or so that a 4.77Mhz 8088 would take. Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: mersennes for exocivilizations
At 10:30 AM 1999/03/02 -0500, Paul Derbyshire <[EMAIL PROTECTED]> wrote: >At 12:07 AM 3/1/99 -0800, you wrote: >>At 11:17 PM 2/28/99 -0800, Spike Jones wrote: >>>It would not surprise me at all if instead of a list of primes, they >>>send us the series 2,3,5,7,13,19,31,61,89,107,127,521... >> >>or 2, 3, 5, 7, 13, 17, 19, 31, 67, 127, 257 perhaps? > >This one doesn't even ring a bell. The same Mersenne primes in it though, >and also some Fermat primes. (3, 5, 17, 257). The first list, p=2,3,5,7,13,19,31,61,89,107,127,521,... is the list of exponents which generate Mersenne primes, as in Mp= 2^p - 1 The second list, p=2,3,5,7,13,17,19,31,67,127,257 is the list of exponents Marin Mersenne thought generated Mersenne primes. He was mostly right, but both included exponents that generate composites, and excluded exponents that generate primes. Stating the exponents rather than the base10 representation seems to me to be almost the ultimate in data compression. (2^521-1 has 157 digits; the advantage increases along with the exponent, uh, exponentially.) Ken Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Mersenne exponential range
At 06:19 PM 1998/10/21 EDT, [EMAIL PROTECTED] wrote: > Hi: >10/22/1998 > > I was looking at the available ranges to test Mersenne primes and I noticed > the range included exponents which by definition cannot yield primes. > > I looked at some Mersenne htmls and didn't see any mention of even > number exponents excluded from the search. > > if the exponent, n, is an even number integer then 2^n is a square and >2^n-1 > is factorable by: > ((2^n)1/2 -1) ((2^n)1/2 +1) = 2^n-1 > > Example ... > > 2^10 = 1024 > (2^10)1/2 = 32 > > so: > (2^10) - 1 = 1023 > ((2^10)1/2) -1 = 31 > ((2^10)1/2) +1 = 33 > 31(33) = 1023 Only exponents which are primes are represented in the database which either primenet or your own manually administered prime95 draw exponents to factor or Lucas-lehmer test. Furthermore, the exponents in the database have already been tested for prime factors up to 2 to some power between 48 and 60 or so. They are tested up to about an optimal level where the odds of finding a factor by going higher are outweighed by the amount of time it would take, versus getting (an almost conclusive) yes-or-no answer on primality by doing the more time consuming Lucas- Lehmer test. The factoring makes use of knowledge of the special form of possible factors of mersenne numbers (which are q=2kp+1 where p is the prime exponent and k= a positive integer; they are also q=8n+1 or 8n-1 where n is a positive integer). > My computer is a pentium 133, 64mb ram , 2gig hd, MS95, math coprocessor. > Could I contribute to the prime search? Sure. Download the software and read the readme file to get started. You'll want the prime95 software. > Regards, > > Jim Broadhurst > aiseki@aol,com
Re: Mersenne: When triple checking fails
At 12:04 PM 1998/10/14 GMT, "Brian J Beesley" <[EMAIL PROTECTED]> wrote: |I thought the primary purpose of the security code was to ensure that |the transmission between client & PrimeNet server was secure from |accidental error. | |Perhaps we should think of replacing the existing system by something |incorporating PGP-style signatures? George created the security code so he'd have a way to check whether a residue was actually from prime95, or a fabrication. At least that's my understanding of it. The prime95 security code predates the existence of primenet entirely. This is a result of mine from mid June 1996: 572023 no factor to 2^52, VC: CB29ACEE 572023 is not prime. Res64: 374379CF,907F8DC7. VC: 263FA834 (again, random characters changed) George's network enabled prime95 version wasn't announced until 21 Aug 1996. The earliest email I have from Duncan Booth is September 30, 1996, announcing he'd created the first primenet server software: >From: Duncan Booth <[EMAIL PROTECTED]> >Organization: RCP Consultants >To: [EMAIL PROTECTED] >Subject: Mersenne: Prime95 and NT >References: <[EMAIL PROTECTED]> >Sender: [EMAIL PROTECTED] > >Has anyone out there tried running PRIME95 as an NT service (using >SRVANY)? If so does it work, or are there any pitfalls to be wary of? > >By the way, I have put together a PRIMENET.DLL using RPC to communicate >with a server. It seems to be working though I want to do a bit more >testing before letting it out the door. The requirements for running >this will be an NT box to run the server software, and a collection of >NT workstations (or Win95, although I havent tested any of them) to do >the real work. Any of the normal RPC protocols are supported so in >theory at least it may be possible to put a server on the internet. > >-- >Duncan Booth >[EMAIL PROTECTED] (This is what Scott Kurowski started from. Scott began with it on March 28 '97 and by April 6 he had a primenet server on the internet.) I think switching to PGP-like is not necessary or advisable. The current code does the job, and is quite concise.
Re: Mersenne: When triple checking fails
I had asked in part, >>What were the residues produced by these? They are not listed in >>ftp://gimps:[EMAIL PROTECTED]/home/gimps/lucas_v.txt (the double-check file) (since that is what my web browser listed as a URL) At 05:53 PM 1998/10/13 -, <[EMAIL PROTECTED]> wrote: >I think lucas_v.txt is the list of exponents considered "finished" i.e. double- >checked using 2 different progs, or 2 different offsets if both using Prime95 etc. >1419967 is *not* finished if we do not have agreement between reported results. > >The file hrf3.txt deliberately does *not* contain residuals since these could be >used to rig double-check results i.e. just return what's expected instead of >computing it. George's prime95 and its close relatives output like the following, which includes a security string making false claims of having done an LLtest hard to fake or at least inconvenient, as in the following example: M4190237 is not prime. Res64: 14FC0406840D6CF3. WQ1: 2DB378F5 (exponent) (result) (residue) (SW version) (security code) (I've changed some characters in the example, so don't bother to send it to George!) George's source on the web does not include the routines for the security string generation. Do other programs (MacLucas, mersenne1, etc.) have a security code, or are those results on the honor system? Ken
Re: Mersenne: When triple checking fails
ftp://gimps:[EMAIL PROTECTED]/home/gimps/programs.txt identifies the program codes as follows: J3,64,John Sweeney. Mac version 1.4 - Bug fix. prev versions can give bad data WP1,64,Woltman - PFA version - Win 95 X,64,Richard Crandall program and its successors - UNIX There is a J4. Also: WQ1,64,Woltman - Better error checking - Win 95 What were the residues produced by these? They are not listed in ftp://gimps:[EMAIL PROTECTED]/home/gimps/lucas_v.txt (the double-check file) I recall George Woltman giving a figure that about 0.5% of LLtests are wrong. If 1 in 200 or so residues are incorrect, and double checks are completely independent, then it makes sense that 1 in 40,000 double checked exponents could have both checks wrong; then a triple check would match neither of the previous results. (It is a reflection of awesome reliability of code and hardware, given the number of hours or days that go into a single residue.) Coincidentally we have about 40,200 double-checks completed. Given a 3-way tie, the 4th test should (usually) tell which residue is correct, if the programs used are consistent enough in design that the residues should match. (See the thread about differing start values causing residues to vary.) The most significant point though would be that if all 3 are producing nonzero residues, we're pretty sure it's composite. How many cases of disagreeing triple checks are there to this point? Ken At 11:04 AM 1998/10/13 +0200, [EMAIL PROTECTED] (Marc-Etienne Vargenau) wrote: >The status page tells us that all exponents below 1 318 200 have been >double checked. >We will soon hit cases like >1419967,wayney,WP1 >1419967,SB,X >1419967,MV1,J3 >(in file hrf3) >where three different programs (Woltman, mersenne1 and MacLucas) give >three different results. How will this be resolved? Has one of the >programs a known bug in this area? > >Regards, > >Marc-Etienne >
Re: Mersenne: A short gdunken on Aaron B's situation
But according to Aaron, the results he has been credited with on the Mersenne top producers page and at primenet did not come from US West processors, since the activity was terminated before the first exponents at USWest completed. Is it right to delete credit for legitimately obtained results, just because you don't like the man or something he did elsewhere, like create a controversy? Even deleting credit for results he obtained using equipment he owns himself? If not, how do you determine which or how many results are from which environment? I think the right course is to wait and see how his case turns out, and leave the credits alone. Ken Kriesel At 08:28 AM 1998/09/18 -0500, you wrote: >In article <[EMAIL PROTECTED]>, >"Vincent J. Mooney Jr." <[EMAIL PROTECTED]> wrote: >> >> Well, we could argue this for a long time. I vote for discarding the >> results and asking GIMPS to warn its participants to never do this again. >> GIMPS should not credit Aaron for the work. > >I second this proposal. > >Let me explain my reasoning: GIMPS should have a _policy_ of what >are appropriate CPU-cycles, and what are *inappropriate* CPU-cycles. >Then GIMPS should enforce that policy by NOT ACCEPTING the results >of *inappropriate* CPU-cycles. >
Re: Mersenne: factor found but factorization continues? why?
For the factor to be about 630, the exponent could be at most about 315, since the factors of mersenne numbers are of the form q=2kp+1. (if q=630, for k=1, p=~315, and for larger k, p is smaller) But nearly all numbers below 331 have already been not only tested for factors to at least 2^50 (with most exponents factored up to 2^55 or more), but Lucas-Lehmer tested also already (except for 72). I think it is much more likely that the exponent tested is p=~630, and the factor found for it is somewhere between 2^55 and 2^62 or so. Ken At 09:03 AM 1998/09/17 -0400, you wrote: >> >Computer running prime95 ver 16.4 intel 486 today found a >> >factor of the number it was processing, contacted primenet, >> >sent the result, obtained a new number to factor, and then >> >continued to factor the same number it had just found a factor >> >for. I do not have the files immediately to hand but the >> >number was in the 630 range and the factorization had >> >reached the 6th or 7th iteration of 16. Can someone tell me, >> >> The factoring test will continue on the chance that a smaller factor >> may be found. I believe this is in the interest of doing some kind >> of analysis on the smallest factors of composite Mersenne numbers. > >Well, is it aware enough not to try any factors larger than those >already found? In the case above, iterations 7-16 should go _very_ >fast if the iteration 6 factor found was only 630. > >-- Tim >
RE: Mersenne: Yikes!
I can confirm from my own experiences that the working set and thrashing
that may result is an issue both for WindowsNT and for Windows95.
NT Services get woken up for about a 1% cpu duty cycle even when set to
lowest priority, on a system that is thoroughly saturated with other things
to do. This means the working set on a resource-hungry system must be
swapped back in frequently. I don't think there's anything that can be
done about that. ("It's a feature.")
Each thread gets a priority boost occasionally. Page 459 of the NTWS4
Resource Kit says it's "random". Priority can be kicked up from 1
(idle, the base priority of prime95) to 5 or higher for prime95 even
when there are several competing higher priority cpu-bound tasks, giving
each ready thread a base level of throughput that is typically 1% of the
cpu.
I suppose George could have prime95 begin in an idle state,
check how much free memory is available, launch an iteration only if the
amount is 5MB more than the estimated working set of Prime95, then check
every x iterations whether there's still 5MB free, and if not, write
results to disk, free memory, and revert to idle state. (But this would
reduce efficiency and increase code size a little more...)
My impression is that the problem at USWest was more related to the large
number of machines launched together and the resultant primenet server bugs
discovered, exhaustion of available exponents, & resultant repeated retry
by the USWest primenet client systems. It's easy to imagine their internet
connection not being ready to handle a few thousand cpus adding more
traffic atop the normal load.
Ken
At 07:21 PM 1998/09/16 +0100, "Phil Brett" <[EMAIL PROTECTED]>, wrote:
>Only one small point. I'm running NTPrime on a few machines ( with peoples,
>networks, my mum's permission ) and i've noticed a performance problem that
>users do notice. If the machine in question has, say, 32MB of RAM the
>percentage working set that NTPrime uses is quite high. My machine LL
>testing in the 5,700,000+ range is using 3,700K ish.
>
>I've ( and the users ) have noticed that this can cause mad swapping battles
>that slow the machine to a crawl. The affected machines now factor which has
>a much smaller working set.
>
>This can only get much worse as the FFT sizes rise.
>
>Some ( humble ) sudgestions :-
>
>1) The prime server takes into account the RAM available ( setable in
>Prime95 ? ) when dishing out work.
>
>2) Prime95 somehow backs off for a few minutes if memory gets low to let the
>swapping sort itself out.
>
>3) George finds a way to reduce the memory requirements ( not likely with
>the same speed I admit )
3) above is a possibility for those willing to run the double-checking with
alternate code that George has been considering implementing in the future.
Ken
Mersenne: To delete credit or not for unauthorized computer use?
Let's wait and see whether any charges are filed, whether they are summarily dismissed, or tried, and if tried what the verdict is. The question of what to do with real GIMPS results obtained illegally may be academic. woensdag 16 september 1998 15:54 "Dean-Christian Strik" <[EMAIL PROTECTED]> said: |Aaron got his results illegally, This is under contention currently. It's a charge or an allegation, not an established legal fact or conclusion. Aaron is supposed to be presumed innocent unless/until proven guilty. The residues and/or factors are correct or incorrect, and can be proven so with a double check when someone gets around to it. In the meantime there is plenty of work to go around on other exponents. I vote the results are kept rather than discarded. It might even be a bad idea to delete them, from a legal point of view. Perhaps George will include a caution in his web site about obtaining _all the necessary permissions_ before installing his software. Caveat: I am not a lawyer, just a participant in GIMPS. Ken
