Mersenne Digest Sunday, 17 January 1999 Volume 01 : Number 497 ---------------------------------------------------------------------- From: "Ernst W. Mayer" <[EMAIL PROTECTED]> Date: Thu, 14 Jan 1999 16:26:13 -0500 Subject: Mersenne: Free 128-bit encryption software Check out http://cnn.com/TECH/computing/9901/14/gercrypt.idg/index.html ------------------------------ From: [EMAIL PROTECTED] Date: Thu, 14 Jan 1999 13:25:44 -0800 (PST) Subject: Re: Mersenne: mprime for QA or performance? > Some things are known to happen; and I have observed them myself. First, > the amount of voltage required to work at a given speed decreases. > Secondly, the odds of the chip working at a higher speed increases. To me at least, the first part is obvious. As temperature goes up, so does resistance. The higher resistance requires a greater potential difference to send an adequeate(sp?) amount of current throught the processor. Without cooling, I would imagine the chip would eventually melt down. With cooling, I would imagine the voltage peaks out in some sort of gaussian curve. Which beings to mind, would the potential difference delta be a good measure of the quality of your cooling? (For the non electrical people, I am using voltage and "potential difference" interchangeably, they are the same thing but potential difference says it better IMHO) Which brings to mind a theory about the second part, "speed increase". Too much heat will damage a processor. However I wonder if there is a relationship between some sort of particle drift (electron???) and resistance that "breaks in" or "burns in" a new processor? Much like the performance on a new engine after it has been carefully broken in after the first 1,000 miles... > This much is common knowledge. No one has satisfactorily explained > these results, though many theories abound. Case in point... > There are also rumors that the higher-quality chip cores, which get put > into the C333A/366/400 and Pentium II's are measureably faster. These > rumors have not been confirmed to my knowledge. Tighter packed transistors = less ability to dissipate heat = more resistance... > It would be difficult to classify unexplored territory as "common knowledge". > Perhaps it's common knowledge to some; it's just not mentioned in the > more popular websites or forums. Almost everything that I have learned beyond 1st grade was by assuming that it was common knowledge. "If someone else understands it, I should be capable of understanding it too!"... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : WWW: http://www.silverlink.net/poke : Boycott Microsot : : E-Mail: [EMAIL PROTECTED] : http://www.vcnet.com/bms : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------ From: "Leslie Burrow" <[EMAIL PROTECTED]> Date: Thu, 14 Jan 1999 22:40:56 -0000 Subject: Re: Mersenne: More Xeon results - -----Original Message----- From: Aaron Blosser <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 12 January 1999 22:49 Subject: Mersenne: More Xeon results >This time, a single processor Compaq Proliant 5500 with a 400MHz Xeon and >512MB RAM. > >I tested M11213 per Brian Beesley's suggestion. > >Prime95 showed it at .028 seconds per iteration, and I did a pretty decent >job timing it. > >It finished and found it prime in approx. 446 seconds (00:07:26). > Just tried this on my Celeron (300)450A :- 0.039sec/iteration 7min 23secs total time. slightly better price/performance ratio :-) Les Burrow ------------------------------ From: Leu Enterprises Unlimited <[EMAIL PROTECTED]> Date: Thu, 14 Jan 1999 16:49:15 -0800 (PST) Subject: Re: Mersenne: mprime for QA or performance? > From [EMAIL PROTECTED] Thu Jan 14 13:25:19 1999 > To: Leu Enterprises Unlimited <[EMAIL PROTECTED]> > cc: [EMAIL PROTECTED] > Subject: Re: Mersenne: mprime for QA or performance? > > > > > Some things are known to happen; and I have observed them myself. First, > > the amount of voltage required to work at a given speed decreases. > > Secondly, the odds of the chip working at a higher speed increases. > > To me at least, the first part is obvious. As temperature goes up, so does > resistance. The higher resistance requires a greater potential difference > to send an adequeate(sp?) amount of current throught the processor. > Without cooling, I would imagine the chip would eventually melt down. With > cooling, I would imagine the voltage peaks out in some sort of gaussian > curve. Which beings to mind, would the potential difference delta be a > good measure of the quality of your cooling? That's not been my experience. You can put on superb cooling, and crank the voltage up all you want. It won't help a bad chip. You will only fry the chip. Don't forget that the CPU parts are spec'd at 2.5V; with a typical tolerance of +/- 20 %. Running a C300A at 3.0+ V for long is likely to cause great disappointment. Furthermore, you are not guaranteed to run reliably at 504 MHz, if your CPU handles 450 MHz @ 2.0 V. I have several such CPU's. And, FWIW, the point of failure appears to be the FPU (no - not the L2 cache, like most people assume). > ... > > > It would be difficult to classify unexplored territory as "common knowledge". > > Perhaps it's common knowledge to some; it's just not mentioned in the > > more popular websites or forums. > > Almost everything that I have learned beyond 1st grade was by assuming > that it was common knowledge. "If someone else understands it, I should be > capable of understanding it too!"... Ok - please explain to me members of the opposite sex. They certainly seem to understand each other. :) Seriously, I wouldn't classify the original subject as common knowledge among overclockers at all. Or the latter subject, but let's not digress... Back to my orginal point - is there truely no one on this list who can knowledgeably state that the precision of mprime is suitable, or not suitable, for these timing purposes? One area of concern is round-off error. But there may be others as well. TIA! -dwight- ==================================================================== To learn how to build your own supercomputer, for under $10,000, go to: www.supercomputer.org ==================================================================== ------------------------------ From: "Roger Vives Miret" <[EMAIL PROTECTED]> Date: Fri, 15 Jan 1999 10:12:10 +0100 Subject: Mersenne: Small doubt Hi list, Running prime95 following message is shown: "Factored M8496239 through 1577822272*2^32 (pass 5 of 16). Clocks 22113124 = 0.221 sec." ^^^^^^^^ ^^^^^ May anyone tell me what is the number following 'clocks' word (in the example 22113124) and the time (?) (in the example 0.221)? Thanks! Roger Vives ------------------------------ From: "Brian J Beesley" <[EMAIL PROTECTED]> Date: Fri, 15 Jan 1999 10:19:33 GMT Subject: Re: Mersenne: mprime for QA or performance? > To me at least, the first part is obvious. As temperature goes up, so does > resistance. The higher resistance requires a greater potential difference > to send an adequeate(sp?) amount of current throught the processor. > Without cooling, I would imagine the chip would eventually melt down. With > cooling, I would imagine the voltage peaks out in some sort of gaussian > curve. For small temperature ranges then R = kT + c, the trouble is, for semiconductors, k can be negative. This is why semiconductors can (& do) burn out if overrun or undercooled - current can "run away" to very large values (essentially whatever the supply rails will stand before *they* step in & act as fuse wire) When running digital chips very fast, what you need is a sharp rise/fall. Now you just *never* see nice square waves like those drawn in the text books, real signals tend to look like a sine wave. Obviously, in these circumstances, the higher the voltage, the steeper the rise & fall of the signal when it's changing from a 0 state to a 1 state, or vice versa. It's also why small die sizes can be run faster than large die sizes, the current is much smaller, so it takes less power to change from 0 to 1 in a given time. > Which brings to mind a theory about the second part, "speed increase". Too > much heat will damage a processor. However I wonder if there is a > relationship between some sort of particle drift (electron???) and > resistance that "breaks in" or "burns in" a new processor? Much like the > performance on a new engine after it has been carefully broken in after > the first 1,000 miles... I get the impression that failure rates on (non-overclocked) semiconductor device falls rapidly with time, at least over the first few hours. This is why quality systems suppliers "burn in" or "soak test" systems for 24-48 hours before shipping. It may be the case that minor flaws can act as "pinch points" which eventually cause burn out & failure, even though the chip actually measures within spec to begin with. Also atoms within crystals can "creep" causing minute changes to the circuit characteristics, I would have thought that the most significant effect would be the first time the circuit gets to its "normal" operating temperature. Regards Brian Beesley ------------------------------ From: "Ernst W. Mayer" <[EMAIL PROTECTED]> Date: Fri, 15 Jan 1999 13:15:24 -0500 Subject: Mersenne: Let's recruit her for GIMPS The following article, titled "Irish teen's e-mail code could transform Internet commerce" should be of interest: http://www.cnn.com/TECH/computing/9901/14/email.genius/ Pretty impressive work for a person of any age, much less a 16-year-old. We should see if we can recruit her for the GIMPS effort. - -Ernst ------------------------------ From: "Foghorn Leghorn" <[EMAIL PROTECTED]> Date: Fri, 15 Jan 1999 21:05:00 EST Subject: Mersenne: Basic question: Working modulo 2^n-1 Chris Caldwell's web page on Mersenne numbers descirbes the Lucas-Lehmer test briefly and mentions that it is quick on binary computers because they can quickly perform division by 2^n-1. I know how to find integer quotients and remainders modulo 2^n with shifting and masking, but I don't understand how it is done quickly modulo 2^n-1. Would anyone care to explain? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com ------------------------------ From: George Woltman <[EMAIL PROTECTED]> Date: Fri, 15 Jan 1999 21:48:05 -0500 Subject: Re: Mersenne: mprime for QA or performance? Hi, At 12:24 AM 1/13/99 -0800, Leu Enterprises Unlimited wrote: >On one CPU, after two days worth of burn-in, the time required to >complete 100 iterations on the stock number went down, as I would expect. > >On a second CPU, the time actually *increased*. From 1 day, 18 hours, >and 55 minutes, to 1d 19h 13m! I'd be surprised if burning in had an effect on iteration times. More likely, 100 iterations is not enough to get a truly accurate timing. I don't know about Linux, but it has been noted before prime95 iteration times can vary a few percent from day to day. >If anyone knowledgeable would care to comment about mprime's suitability >for Q.A. mprime is great for QA. It generates heat (by FPU use) and tons of memory accesses. If there are any hardware problems there, they are likely to show up in an extended torture test. >and/or performance measurements, I'd guess its as good as but no better than any of hundreds of publicly available benchmarks. Best regards, George ------------------------------ From: Chris Caldwell <[EMAIL PROTECTED]> Date: Sat, 16 Jan 1999 08:17:24 -0600 (CST) Subject: Re: Mersenne: Basic question: Working modulo 2^n-1 On Fri, 15 Jan 1999, Foghorn Leghorn wrote: > Chris Caldwell's web page on Mersenne numbers descirbes the Lucas-Lehmer > test briefly and mentions that it is quick on binary computers because > they can quickly perform division by 2^n-1. I know how to find integer > quotients and remainders modulo 2^n with shifting and masking, but I > don't understand how it is done quickly modulo 2^n-1. Would anyone care > to explain? The remark was indended to refer to the classical algorithms (with the right choice of FFT algorithm this step is automatic): the key is that 2^n = 1 (mod 2^n-1), so if we write the number as A*2^n + B (that is, let B be the last n bits and A the rest, then A*2^n+B = A+B (mod 2^n-1). So we can reduce with just an addition. For exampe, take the number 23 modulo 7, 23 is (mod 7) 10111 = 10 + 111 = 1001 = 1 + 001 = 10 (mod 111) Chris. ------------------------------ From: [EMAIL PROTECTED] (Mikus Grinbergs) Date: Sat, 16 Jan 1999 08:01:07 -0600 Subject: Mersenne: Verifying that ECM works ? The mprime program includes a self-test to verify that the Lucas-Lehmer code is running properly. Can someone suggest some non-trivial worktodo.ini entries to verify that the ECM factoring code is running properly ? mikus ------------------------------ From: Henrik Olsen <[EMAIL PROTECTED]> Date: Sat, 16 Jan 1999 18:15:06 +0000 ( ) Subject: Re: Mersenne: Let's recruit her for GIMPS On Fri, 15 Jan 1999, Ernst W. Mayer wrote: > The following article, titled "Irish teen's e-mail code could > transform Internet commerce" should be of interest: > > http://www.cnn.com/TECH/computing/9901/14/email.genius/ > > Pretty impressive work for a person of any age, much less a 16-year-old. > We should see if we can recruit her for the GIMPS effort. > > -Ernst I checked that article, it has no mention of her algorithm, no mention of the strength of the algorithm, no mention of whether the judges where competent to evaluate the strength of the algorithm and a very scary quote foretelling the future of her work. <quote> She said that she would prefer to publish her discovery rather than patent it, because making money from it would go against the spirit of science. </quote> With the way the US patent law works, that will put it up for grabs to whoever gets the application done first, thus enabling them to prevent any unlicenced use by others, including the discoverer. She's showing her age with that comment:( - -- Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/ Get the rest there. ------------------------------ From: Henrik Olsen <[EMAIL PROTECTED]> Date: Sat, 16 Jan 1999 18:24:00 +0000 ( ) Subject: Re: Mersenne: mprime for QA or performance? On Fri, 15 Jan 1999, George Woltman wrote: > At 12:24 AM 1/13/99 -0800, Leu Enterprises Unlimited wrote: > >On one CPU, after two days worth of burn-in, the time required to > >complete 100 iterations on the stock number went down, as I would expect. > > > >On a second CPU, the time actually *increased*. From 1 day, 18 hours, > >and 55 minutes, to 1d 19h 13m! > > I'd be surprised if burning in had an effect on iteration times. > More likely, 100 iterations is not enough to get a truly accurate > timing. I'd be extremely surprised, since the speed of the computations is strongly linked to the processor clock, so either you're measuring clock drift (and yes, that is temperature linked) or due to your small samples the variance mentioned which is about 1% is actually noice. - -- Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/ Get the rest there. ------------------------------ From: Henrik Olsen <[EMAIL PROTECTED]> Date: Sat, 16 Jan 1999 19:25:28 +0000 ( ) Subject: Re: Mersenne: Small doubt On Fri, 15 Jan 1999, Roger Vives Miret wrote: > Date: Fri, 15 Jan 1999 10:12:10 +0100 > From: Roger Vives Miret <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Mersenne: Small doubt > > Hi list, > > Running prime95 following message is shown: > "Factored M8496239 through 1577822272*2^32 (pass 5 of 16). > Clocks 22113124 = 0.221 sec." > ^^^^^^^^ ^^^^^ > May anyone tell me what is the number following 'clocks' word (in the > example 22113124) and the time (?) (in the example 0.221)? > > Thanks! > > Roger Vives Clocks would be the number of CPU clock cycles spend on each iteration averaged since the last message, the time is the calculated time based on this cycle count. As has been mentioned one this list earlier, the time is based on the processor speed as set in the configuration, so it doesn't necessarily have anything to do with reality. - -- Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/ Get the rest there. ------------------------------ From: "Ethan Hansen" <[EMAIL PROTECTED]> Date: Sat, 16 Jan 1999 12:54:29 -0800 Subject: Re: Mersenne: mprime for QA or performance? - -----Original Message----- From: George Woltman <[EMAIL PROTECTED]> >Hi, > >At 12:24 AM 1/13/99 -0800, Leu Enterprises Unlimited wrote: >>On one CPU, after two days worth of burn-in, the time required to >>complete 100 iterations on the stock number went down, as I would expect. >> >>On a second CPU, the time actually *increased*. From 1 day, 18 hours, >>and 55 minutes, to 1d 19h 13m! > >I'd be surprised if burning in had an effect on iteration times. >More likely, 100 iterations is not enough to get a truly accurate >timing. <snip> Very true. All things being equal, execution timings are governed solely by the clock speed. For a fixed clock and bus multiplier, a chip neither speeds up nor slows down during its life. The *maximum* speed a given chip runs at may change slightly, but any timing differences noted in mprime or Prime95 are likely the result of either different system and memory loadings, or timing roundoff errors. >>If anyone knowledgeable would care to comment about mprime's suitability >>for Q.A. > >mprime is great for QA. It generates heat (by FPU use) and tons of >memory accesses. If there are any hardware problems there, they are likely >to show up in an extended torture test. > Prime95 and mprime both provide excellent QA capability. A better test, however, is to run both m/prime95 and a second FPU and memory intensive application simultaneously. <snip> >Best regards, >George Regards, Ethan ------------------------------ End of Mersenne Digest V1 #497 ******************************
