Re: Mersenne: Different results
On 18 May 2001, at 14:15, George Woltman wrote: This suggestion is actually a high priority for the next release. The error is probably caused by some driver or program initialization that isn't saving the FPU state properly. The error is benign as you found out. I think the main advantage of this feature is it will lead to slightly faster boot times and thereby improve prime95's reputation of not interfering with your everyday work. Could I respectfully suggest: (a) the startup delay (in seconds) is included as a setting in local.ini and would default to zero, except for NTPrime and Prime95 when run as service is set, when the default would be 60 seconds; (b) a command-line switch is provided which would cause the startup delay to be omitted, even if set in local.ini. Regards Brian Beesley _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Fw: numeric hazards of high performance CPU design = Pentium 4 - constant speed problem
I came about this information on degrading calculations after about 10 minutes of usage. I think it can help explain stange behavour on your test of Prime 95 for P4. Don't be confuse by the web page title. Roger Gariépy :-) - :-( [EMAIL PROTECTED] - Original Message - From: validlab [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 17, 2001 5:20 PM Subject: numeric hazards of high performance CPU design http://www.inqst.com/articles/athlon4/0516main.htm _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Different results
Hello Mersenne, George woltman wrote: This suggestion is actually a high priority for the next release. The error is probably caused by some driver or program initialization that isn't saving the FPU state properly. The error is benign as you found out. I think the main advantage of this feature is it will lead to slightly faster boot times and thereby improve prime95's reputation of not interfering with your everyday work. Glad to see this. 99% of errors form my computer are at boot usually after a new program install. I try to remember to uncheck Windows95 service when installing anything but sometimes it slips by. Timothy Luders replying form the digest _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Fw: numeric hazards of high performance CPU design =Pentium 4 - constant speed problem
I just felt I had to say, that I am very disturbed by this. The idea of my CPU simply shutting down when it overheats is a sensible idea. This is much more dodgy, espicaly as there doesn't seem to be any way of finding out, short of lots of benchmarks, if your processor is doing this... :-( It also raises problems for prime95, as it looks like running prime95 will reduce your PC's speed by half. I am going to recieve a pentium 4 shortly, and although I shall try to send it back for an AMD processor, if I can't I shall run tests with prime95. However if these figures are true then it won't be searching for primes :-( Chris -- Chris Jefferson, Girton College, Cambridge, CB3 0JG --- http://mrjeff.webjump.com Don't bother, it's not worth looking at. On Sat, 19 May 2001, Roger Gariépy wrote: I came about this information on degrading calculations after about 10 minutes of usage. I think it can help explain stange behavour on your test of Prime 95 for P4. Don't be confuse by the web page title. Roger Gariépy :-) - :-( [EMAIL PROTECTED] - Original Message - From: validlab [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 17, 2001 5:20 PM Subject: numeric hazards of high performance CPU design http://www.inqst.com/articles/athlon4/0516main.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 Digest V1 #854
Mersenne Digest Saturday, May 19 2001 Volume 01 : Number 854 -- Date: Wed, 16 May 2001 19:52:48 -0500 From: Ken Kriesel [EMAIL PROTECTED] Subject: 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 -- Date: Thu, 17 May 2001 00:39:11 -0500 From: Jeramy Ross [EMAIL PROTECTED] Subject: Re: Mersenne: SUMOUT errors A interesting note, and I forgot to include this in my original post, but the computer that I encountered the illegal sumouts on was a 500MHz K6 PC. Perhaps this is a problem when running those software modems on a K6 based machine?? - - Jeramy Original Message - From: Steve [EMAIL PROTECTED] For what it's worth, I have had the exact same problem getting illegal sumouts when using the modem on this 475Mhz K6 PC. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Fri, 18 May 2001 01:17:45 +1000 From: Steve Phipps [EMAIL PROTECTED] Subject: Re: Mersenne: ECM Question... While we're on the subject, can someone explain how to derive the group order for factors found using ECM? I've been carrying out ECM on an old PC for almost a year now, and I'd like to be able to derive, and factorise, the group orders for the factors that I've found. I've been making an effort to understand the maths, and I'm getting there slowly, but I've found nothing yet that explains how to derive the group orders. If my understanding is correct, you would need to know the equations used by mprime to derive the co-ordinates of the starting point for each curve. Anyway, if someone could explain how to derive the group order, or point me in the right direction, I'd be very grateful. Regards, Steve If the sigma is the same, then a curve with B1=25 will find any factor that a curve with B1=5 finds. When you run 700 random curves at B1=25, you might theoretically miss a factor that someone else finds with B1=5, if he gets a lucky sigma so that the group order is very smooth. But in general, using the same number of curves, the higher bound should find all the factors that the lower
Re: Mersenne: Fw: numeric hazards of high performance CPU design = Pentium 4 - constant speed problem
Hi, At 04:52 PM 5/19/2001 +0100, Chris Jefferson wrote: I just felt I had to say, that I am very disturbed by this. The idea of my CPU simply shutting down when it overheats is a sensible idea. This is much more dodgy, espicaly as there doesn't seem to be any way of finding out, short of lots of benchmarks, if your processor is doing this... :-( Although I've not run LL tests for extended periods of times, I have never noticed the CPU throttling down by half. Time will tell if this is a significant problem or will only be seen in cheap P4 machines with inadequate cooling. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Fw: numeric hazards of high performance CPU design = Pentium 4 - constant speed problem
At 04:52 PM 5/19/2001 +0100, Chris Jefferson wrote: I just felt I had to say, that I am very disturbed by this. The idea of my CPU simply shutting down when it overheats is a sensible idea. This is much more dodgy, espicaly as there doesn't seem to be any way of finding out, short of lots of benchmarks, if your processor is doing this... :-( Actually this is nothing new. My Toshiba Satellite 200 CDS (100 MHz Pentium P5, manufactured December 1996) even has a BIOS setting to let you either turn on an extra cooling fan or reduce the processor speed if required; and the manual states that, if the processor still gets too warm even with the fan running, the speed will be reduced anyway. The laptop system provides this option as a choice since the user may require continued (relatively) fast operation or may wish to maximize battery life (by not running the fan). Seems to make sense to me. In any case I'd rather have the processor slow down than cook itself to the point of system instability. What _is_ a concern is that the the CPU temperature sensor is appropriately positioned and calibrated so that the speed is reduced (thus reducing power consumption and therefore heat output) _before_ the limiting die temperature is reached, so that there is minimal risk of incorrect operation. I am far from convinced that this design criterion is always met. Also, many BIOSes allow the overheat throttle speed to be set to 100% - disabling this safety feature. In any case, CPU overheat throttling should be thought of as a hardware preservation device. Its presence is not an excuse for a lack of provision of proper cooling to the processor. The alternative of the system shutting down is viable, and achievable by BIOS configuration in all the recent systems I've seen (by setting the throttled speed to zero). In practise, this is likely to cause a total system crash; IMHO almost all users would rather the system limped on, possibly restoring itself to normal operation if the cause of the excess heating is removed, than simply ceasing to respond. Having said all that, a system which does exhibit thermal throttling almost certainly has either an inadequate heatsink, or grossly restricted airflow, or is operating in an unacceptably high ambient temperature. It should be possible to prevent thermal throttling by fixing one or more of these problems. BTW if you have Prime95 or mprime running with a displayed console window, reduced clock speed will be evident. Since the CPU clock _but not the memory bus speed_ will be reduced, the clocks per iteration will _fall_ to an unusually low level. However you should notice that the per iteration time no longer corresponds to real elapsed time between output lines. On 19 May 2001, at 16:24, George Woltman wrote: Although I've not run LL tests for extended periods of times, I have never noticed the CPU throttling down by half. Time will tell if this is a significant problem or will only be seen in cheap P4 machines with inadequate cooling. It would be interesting to see if George has any data from his system as to any difference in steady-state CPU temperature depending on whether Prime95 is running the old x87 code, or the new SSE2 code; also whether he noticed any rise in CPU temperature as the SSE2 code has been improved in efficiency. If you read the article _carefully_ you will see that the author's chief concern is for the existing 0.18 micron fab 1.7GHz variant of the Pentium P4 processor. P4s rated at lower speeds will have a lower power consumption and are therefore less likely to overheat. In any case, one of the systems referred to in the text as sufferring from the 10 minute performance drop was found to have a misaligned air duct which would reduce the processor cooling efficiency markedly. The article's conclusion is that customers requiring fast P4 systems may well find it worthwhile waiting for the 0.13 micron fab variants which will be coming online later this year - together with new Intel chipsets which support DDR SDRAM. I don't know for a fact whether there really is a problem with overheating in the 1.7GHz P4 for which there isn't an adequate heatsink; whether there is a quality control problem resulting in temperature sensors being set too sensitive to prevent _some_ installations from thermal _damage_; whether the cooling provided by the systems referred to in the article is deficient in design or construction; or whether the testing facility used by the authors of the article simply has too high an ambient temperature. However it is _certain_ that the processors built using 0.13 micron technology will consume less power at the same clock speed than existing 0.18 micron parts. BTW the existing 1.33 GHz Athlon is also quite close to the limit of what even the best heatsinks can cope with without the die temperature becoming critical. Though reducing the mask dimensions will continue to help
Mersenne: Re: numeric hazards of high performance CPU design = Pentium 4 - constant speed problem
On Sat, May 19, 2001 at 10:53:13PM -, Brian J. Beesley wrote: BTW if you have Prime95 or mprime running with a displayed console window, reduced clock speed will be evident. Since the CPU clock _but not the memory bus speed_ will be reduced, the clocks per iteration will _fall_ to an unusually low level. However you should notice that the per iteration time no longer corresponds to real elapsed time between output lines. Hmmm... What do you mean by a displayed console window? An MS-DOS-window? I'm quite positive that mprime on Linux doesn't slow that much down when I open up a copy of /bin/sh, at least :-) /* 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
