Mersenne Digest Friday, December 29 2000 Volume 01 : Number 804 ---------------------------------------------------------------------- Date: Fri, 22 Dec 2000 17:07:12 -0500 From: [EMAIL PROTECTED] Subject: Mersenne: Automatic reply I have moved. My new address is: [EMAIL PROTECTED] Please use this address in the future. Thanks _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 22 Dec 2000 18:10:41 -0500 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: Re: PrimeNet DB Sychro Complete Happy Holidays to all, At 01:54 PM 12/22/2000 -0800, Scott Kurowski wrote: >Some of you may have noticed your Cleared Exponents lists are shorter >following Wednesday's PrimeNet resync with George's database. Thanks for >hanging in there for 10 months instead of the usual 3 between updates. Due to a quirk in the way we synchronize databases, some LL test results remain in the cleared exponents list. Exponents below 8,000,000 that still need to be double-checked are affected by this odd behavior. Good luck to all in 2001, George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 23 Dec 2000 10:31:56 +0000 From: Gareth Randall <[EMAIL PROTECTED]> Subject: Mersenne: Overclocking - bad for project? There are occasional announcements about overclocking various processors, and I know that some Mersenne contributors describe their clock speed as xxx@yyy where yyy>xxx obviously. However, surely this project is one where overclockers do more harm than good? When you're running your favourite game, it doesn't matter if a couple of incorrect calculations creep in, but the Mersenne project involves very long calculations with basically a boolean answer at the end. One wrong result during this time could ruin the answer. Now I know that the algorithms include a lot of error catching, but once the processor is run to the point of instability there could easily be errors in the error protection. (I'll try a probability analysis later... Basically we need the probability of one error occurring within a certain number of instructions of a previous error.) My opinion is that it's better to have fewer correct results than to have the central database poisoned by loads of "don't think it's prime, but the user was overclocking" results, which of course cannot be distinguished from perfect answers. I'd trade two unreliable answers for one honest result. (What ends up happening is even worse. Mismatching checksums mean that the tests must be repeated until a consensus is reached.) A high score table is brilliant, and excites all contributors, but unfortunately a few seem more interested in climbing the table than in what the project is about. If people want to run overclocked, they should work on a project which isn't so sensitive to noise, such as SETI (okay, hardly an original suggestion here). SETI takes a noisy input to begin with, and introducing the odd bit of noise won't harm the results that much. People whose machines show any sign of instability at all should really stick to factoring, although these are just the sort of people who'll be issued with primality tests because of the apparently high performance. I'm tempted to say: go and find another high score table to climb. So after all that, here's a suggestion: How about an error counting system in mprime/prime95? (Okay there might already be one but I haven't seen it mentioned anywhere.) Every time an error is detected, a counter is incremented, and the final result sent back to the server. An answer coming back with 200 errors might be considered less reliable than one with no errors at all. Yours, ======= Gareth Randall ======= _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 23 Dec 2000 11:08:47 -0500 From: Jud McCranie <[EMAIL PROTECTED]> Subject: Re: Mersenne: Overclocking - bad for project? At 10:31 AM 12/23/2000 +0000, Gareth Randall wrote: >However, surely this project is one where overclockers do more harm than >good? When you're running your favourite game, it doesn't matter if a >couple of incorrect calculations creep in, but the Mersenne project >involves very long calculations with basically a boolean answer at the end. ... I agree. I've never overclocked my computers because I think it is more important to be confident in the results. +---------------------------------------------------------+ | Jud McCranie | | | | Programming Achieved with Structure, Clarity, And Logic | +---------------------------------------------------------+ _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 23 Dec 2000 10:15:42 -0800 From: "John R Pierce" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Overclocking - bad for project? > My opinion is that it's better to have fewer correct results than to have the central database poisoned by loads of "don't think it's prime, but the user was overclocking" results, which of course cannot be distinguished from perfect answers. I'd trade two unreliable answers for one honest result. (What ends up happening is even worse. Mismatching checksums mean that the tests must be repeated until a consensus is reached.) at one time I had a number of those ILLEGAL SUMOUT errors, it turned out to be caused by an errant internet multimedia plugin (Crescendo MIDI) which was somehow interfering with the pentium-II's FPU. This problem was specific to Windows95 too, I think, and went away with a later release of the kernel (win98 or 98SE fixed it, I think... it definately is not a problem in NT or Win2000). I think we all decided it was related to this plugin doing MMX processing at a interrupt basis without properly notifying the kernel or something similar to this. Anyways, I suspect the probability of a hardware error causing erroneous results without triggering MASSIVE numbers of check errors is slim-to-none. How many mismatched checksums does primenet have to reconcile on a ongoing basis? - -jrp _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 23 Dec 2000 23:25:36 +0100 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Mersenne: Re: Overclocking - bad for project? On Sat, Dec 23, 2000 at 11:08:47AM -0500, Jud McCranie wrote: >I agree. I've never overclocked my computers because I think it is more >important to be confident in the results. As long as even George overclocks, I don't feel really guilty about my 400@448 machine (that has successfully completed a 72-hour-torture test before I put it into PrimeNet use)... /* Steinar */ - -- Homepage: http://members.xoom.com/sneeze/ _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 23 Dec 2000 23:56:53 +0100 From: Henk Stokhorst <[EMAIL PROTECTED]> Subject: Mersenne: P-1 factoring only L.S., I would enjoy it if it would be possible to have a prime95 version with a P-1 factoring assignments only option. My pc starts to crunch (literally, really, it starts to peep intermittantly like as if it needs lubricant) if I switch to LL testing. It would save time for the people prefering LL tests, just like the regular factoring only option does now. YotN, Henk _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 24 Dec 2000 07:36:03 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Overclocking - bad for project? On 23 Dec 00, at 10:31, Gareth Randall wrote: > > My opinion is that it's better to have fewer correct results than to > > have > the central database poisoned by loads of "don't think it's prime, but the > user was overclocking" results, which of course cannot be distinguished > from perfect answers. I'd trade two unreliable answers for one honest > result. (What ends up happening is even worse. Mismatching checksums mean > that the tests must be repeated until a consensus is reached.) > This is basically true. However, most systems are conservatively engineered; if care is taken (especially with regard to cooling) overclocking need not neccessarily result in unreliable systems. Systems which are not overclocked can still be unreliable for a number of reasons. IMHO undercooling (perhaps because a fan has stopped running, possibly without the knowledge of the user) represents at least as serious a problem as overclocking. Damage by static discharge to components (especially memory, and usually due to mishandling during assembly) is another possible cause of systems running less than perfectly reliably. On 23 Dec 00, at 10:15, John R Pierce wrote: > at one time I had a number of those ILLEGAL SUMOUT errors, it turned out > to be caused by an errant internet multimedia plugin (Crescendo MIDI) > which was somehow interfering with the pentium-II's FPU. This problem was > specific to Windows95 too, I think, and went away with a later release of > the kernel (win98 or 98SE fixed it, I think... it definately is not a > problem in NT or Win2000). I think we all decided it was related to this > plugin doing MMX processing at a interrupt basis without properly > notifying the kernel or something similar to this. Yes, software problems are a real possibility, especially in Win 9x, because the memory model used does not protect process memory properly. > > Anyways, I suspect the probability of a hardware error causing erroneous > results without triggering MASSIVE numbers of check errors is > slim-to-none. Unfortunately lack of errors in normal operation of Prime95 is not a good indicator of a really reliable system. Because the error check is run every iteration (instead of once every 128 iterations) and because the result is compared with a known value, the 16-hour self test, or the torture test, is better as a hardware reliability tool than running LL tests in "production" mode. A couple of years ago I had an instance of a P100 system with a blown CPU fan. It seems to have run for months with no detected errors. Eventually it did throw a couple of wobblies, but meanwhile it had submitted a couple of results which later turned out to be bad (mixed in with a pile of others which were OK). My only other known error was during a QA test involving a run on a very large exponent. It turned out that the system had glitched, probably only once - rerunning in segments revealed a discrepancy between iterations 8.3 million & 8.4 million, but the other 16 of 17 million iteration segments were clean. This was on a well-cooled Athlon 650 system running Win 2K Professional, using ECC RAM. I don't know the cause. Possibly you can just get a hardware glitch something of the order of once a year. The point is that there was nothing in the log to show that the result might be suspect. Also bear in mind that there is no certainty that there is no undetected bug in either the software or the CPU. There seems little point in excluding results from systems which may possibly be less than perfectly reliable so long as other sources of error may exist. The double-checking mechanism _does_ work! > > How many mismatched checksums does primenet have to reconcile on a ongoing > basis? > George would need to answer this one, but the incidence of "bad" results submitted is something of the order of 1%. Maybe a bit higher, and maybe tending to rise with increasing exponent size (or increasing run times?) I do have a feeling that current systems are less conservatively engineered than they used to be years ago - the market is more competitive, and there is more consumer pressure for ever higher "performance numbers" than there once was. Seasonal felicitations Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 24 Dec 2000 12:47:48 -0500 (EST) From: Jason Stratos Papadopoulos <[EMAIL PROTECTED]> Subject: Mersenne: all-integer LL test and convolution library, v1.0 Hello. For any of you out there lucky enough to have access to an Alpha 21264, I've developed a library for large integer convolutions using number theoretic transforms and optimized for this processor. The library distribution includes a sample program that performs a Lucas-Lehmer test. I designed ICL, the Integer Convolution Library, to be fast, self-tuning, and easy to use. It handles Fermat-mod and Mersenne-mod arithmetic natively; it also produces runtimes within a factor of two of the fastest floating point implementations, with improvements on the way. www.glue.umd.edu/~jasonp/icl.zip Let me know what you think, jasonp _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 29 Dec 2000 12:33:49 -0800 From: Eric Hahn <[EMAIL PROTECTED]> Subject: Mersenne: Missing Exponents ?!?!? Did anybody else notice that the exponents in the range between 33,250,000 and 33,300,000 aren't being offered up by the PrimeNet server ?!?!? That a whole 1328 exponents that doesn't even seem to be available for tssting.... The assigned exponents report shows the assignments jumping from 33,249,991 to 33,300,011... Eric _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ End of Mersenne Digest V1 #804 ******************************
