Mersenne Digest Monday, June 11 2001 Volume 01 : Number 860 ---------------------------------------------------------------------- Date: Fri, 8 Jun 2001 12:06:58 -0700 From: "Pardoe, Richard (PRDR)" <[EMAIL PROTECTED]> Subject: RE: Mersenne: Strange behaviour Guido: No problem with taking up my time. From the description of the problem (machine is unusable during Stage 2), it sounds like you may have given Prime95 too much memory. As a result, not enough memory is left for your other processes. There is a nice description of setting the available memory in the readme.txt.(about halfway into the document). What is your machine memory and how much of it have you allocated to Prime95 for factoring? (Memory is set under Options - CPU) Finally, yest it is normal that P95 runs a self-test for each of the different FFT sizes. Rich Pardoe - -----Original Message----- From: Guido Lorenzini [mailto:[EMAIL PROTECTED]] The Duron completed the stage 1 without any problem, but during the stage 2 the time per iteration has slow down a lot, from 0.650 sec/it to many minutes for just one iteration. Above all the pc is unusable, Is it better if I force prime95 to start p-1 factoring from zero once again, hoping any problem occurs this time? What may be the problem? Has anybody ever observed something like this? Last question: is it normal that prime95 runs a self test each time it is going to test with different FFT sizes? _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 8 Jun 2001 12:22:12 -0700 From: "Aaron Blosser" <[EMAIL PROTECTED]> Subject: Normal behaviour? -> Re: Mersenne: Strange behaviour Guido, How much RAM is in your machine? Those large exponents can easily use a large chunk of memory when doing the P-1 testing, if I recall correctly. A relatively small amount of RAM could cause some serious paging to occur if it's running low. And it's normal for it to do a new test for a new FFT size. Your local.ini file should have lines in there indicating which FFT sizes it's done a test on already. I'd recommend letting it run those tests so it can make sure the boundaries are working right on your machine. Aaron - ----------------- - -- Original Message -- - ----------------- Don't like to take up your time, but the behaviour of Prime95 on a 750@795 Duron, P-1 factoring on 33.3mio exponent (B1=350000 and B2=4025000), is quite strange. The Duron completed the stage 1 without any problem, but during the stage 2 the time per iteration has slow down a lot, from 0.650 sec/it to many minutes for just one iteration. Above all the pc is unusable, so I've decided to edit manually worktodo.ini: from Test=33306743,68,0 to Test=33306743,68,1 to force prime95 to skip the factoring stage when the process was done for about 30% (The intermediate file mX306743 sizes 8,132 KB). I've tried to put everything on another machine but with no results: the behaviour was the same. Skipping the P-1 factoring stage shouldn't invalidate the LL test, as George says in undoc.txt: You can force prime95 to skip the trial factoring step prior to running a Lucas-Lehmer test. In prime.ini add this line: SkipTrialFactoring=1 By the way: I've done it but apparently nothing has changed. If I've understood properly, adding this line is like to manually edit worktodo.ini. Isn't it? Is it better if I force prime95 to start p-1 factoring from zero once again, hoping any problem occurs this time? What may be the problem? Has anybody ever observed something like this? Last question: is it normal that prime95 runs a self test each time it is going to test with different FFT sizes? Thank you in advance for answering and best regards from Italy. Guido72 _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 09 Jun 2001 00:42:53 -0400 From: Nathan Russell <[EMAIL PROTECTED]> Subject: Re: Mersenne: SUMOUT errors Thanks to all who helped me with the SUMOUT issue. For a variety of reasons, I bit the bullet and bought a hardware, external modem. Since doing so, I haven't had any problems (in fact, I had no problems after posting my first message, so it may have been something transitory involving the power supply). I also opened up the machine this past weekend and cleaned out some dust, in addition to removing and reinserting the memory, which had become slightly loose at one end. I also fixed the plastic air-directing device over the CPU, which was a little loose and causing some annoying noises. I don't know which issues, if any, were the problem, but I ran the machine through a 24-hour test after cleaning out the case and it passed. Thanks again to everyone who gave me advice, and also to those who gave me advice on modems several months ago; having a hardware modem makes a BIG difference for a lot of things. I did have some problems with dropping connections to start out, but I then realized that turning the modem off when offline to allow it to clear itself helped. Also, on noticing that the bottom of the modem was hot after half an hour of use, I simply elevated it astride two CD jewel cases, which has eliminated that problem from consideration. Nathan _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 9 Jun 2001 06:21:06 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Strange behaviour On 8 Jun 2001, at 19:50, Guido Lorenzini wrote: > Don't like to take up your time, but the behaviour of Prime95 on a > 750@795 Duron, P-1 factoring on 33.3mio exponent (B1=350000 and > B2=4025000), is quite strange. The Duron completed the stage 1 without > any problem, but during the stage 2 the time per iteration has slow > down a lot, from 0.650 sec/it to many minutes for just one iteration. With much disk thrashing? Sounds like your system is paging heavily, which means that you have set the P-1 factoring memory too high. How big you can get away with depends on the operating system but you should definitely not allow P-1 more than 32 MB less than the total memory on the system. 48 MB is safer especially with Windows NT/2000. Note that the P-1 factoring memory limit applies in stage 2. Stage 1 only uses about as much memory as LL testing. You've probably just come across this because of the exponent size. Smaller exponents will use less memory even in stage 2. > Above all the pc is unusable, so I've decided to edit manually > worktodo.ini: from Test=33306743,68,0 to Test=33306743,68,1 to > force prime95 to skip the factoring stage when the process was done > for about 30% (The intermediate file mX306743 sizes 8,132 KB). I've > tried to put everything on another machine but with no results: the > behaviour was the same. Skipping the P-1 factoring stage shouldn't > invalidate the LL test, as George says in undoc.txt: > > You can force prime95 to skip the trial factoring step prior to > running a Lucas-Lehmer test. In prime.ini add this line: > SkipTrialFactoring=1 > > By the way: I've done it but apparently nothing has changed. If I've > understood properly, adding this line is like to manually edit > worktodo.ini. Isn't it? Sensible. But you probably need to exit Prime95 & restart it to get it to take any notice of a change to prime.ini or local.ini. Stop & continue should suffice if you're just changing worktodo.ini. Anyhow I don't know what will happen if you try to suppress P-1 factoring halfway through the run! > > Is it better if I force prime95 to start p-1 factoring from zero once > again, hoping any problem occurs this time? What may be the problem? > Has anybody ever observed something like this? It's probably not worth the effort. Changing the ,0 to ,1 at the end of the worktodo.ini line tells Prime95 that P-1 has been completed. That should fix your problem. But change the P-1 memory before the next run ... e.g. if you have 128 MB RAM set both DayMemory & NightMemory in local.ini to 80 or less. I had a mild case of page thrashing in P-1 stage 2 on exponent 40250087 with a system running Win 2000 with DayMemory=96, NightMemory=96 on a 128 MB system despite a total lack of other load on the system. I recovered by restoring a backup of the Mxxxxxxx savefile taken the last day that stage 1 was running, changing DayMemory & NightMemory to 88 and restarting Prime95. Even that was close to the bone as page thrashing would set in as soon as anything else started running. Fortunately in my case this wasn't often, I wasn't relying on the system to do anything else. > > Last question: is it normal that prime95 runs a self test each time it > is going to test with different FFT sizes? Yes. It will do this before starting P-1 factoring. The code executed during P-1 stage 1 is _very_ similar to LL testing, so doing the selftest at that point makes sense. The next time it wants to use the same FFT size, it will remember that the selftest has already done. The FFT sizes which have been selftested are noted in local.ini. If you change the system in a major way (upgraded CPU, more memory etc.) it probably makes sense to remove the SelfTest lines from local.ini to force it to repeat the selftests. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 9 Jun 2001 09:53:06 -0700 From: "Aaron Blosser" <[EMAIL PROTECTED]> Subject: RE: Mersenne: SUMOUT errors > I also opened up the machine this past weekend and cleaned out some > dust, in addition to removing and reinserting the memory, which had > become slightly loose at one end. I also fixed the plastic > air-directing device over the CPU, which was a little loose and > causing some annoying noises. I'm always surprised (well, not really) at how incredibly dusty some people's machines can get. Maybe I'm just obsessive/compulsive, but I regularly clean all my systems at least every 2 months or so. :) Shut it down, take the can of compressed air and give it a good dusting. It wouldn't surprise me at all if a layer of dust sitting on your CPU or memory were causing overheating problems in some way or another. In humid areas, the dust will tend to absorb moisture and make a sticky residue which I'm sure could even cause shorting. Matter of fact, I had an old monitor I used to tote around with me... when I moved from Denver to Raleigh, I noticed the monitor would, every now and then, just short itself out in a brilliant display. Then it'd start working again. Finally I opened it up and saw that it had been arcing across some traces on the board where the humid air obviously was just too good a conductor to pass up. Why this monitor maker (some generic Korean company or another) chose to put higher voltage traces so near to lower potential traces, I have no idea. But more interesting was that in the dry Colorado air, I never had a problem. Only the muggy atmosphere of North Carolina set it off. Once I moved back to Colorado, it worked great again. My little bro and I could tell stories from when we both worked at a computer store. In one case, guy having problems brought his machine in and there were actually spiders living inside the thing. Dunno if he used this thing in a barn or what, but that was interesting. Usually the bugs we saw were already dead, but not always. Sort of gives new life to the term "debugging". SUMOUT errors could also be the result of improperly seated CPU or memory, so I'm glad you reseated all that... may have made more of a difference than merely cleaning it out. During my USWEST escapade (just "celebrated" the 3 year anniversary of being caught, by the way), I was keeping track of which machines were having problems. I think I saw about 4 or 5 machines of the 3500 or so. I was going to send that list to the techs in those areas to have them reseat things to see if that was the problem, but of course I never had the chance. Somewhere, US WEST (now Qwest) and the FBI have a list of machines with flaky hardware... hopefully they checked them out and fixed them. :) _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 09 Jun 2001 17:20:51 -0700 From: Spike Jones <[EMAIL PROTECTED]> Subject: Mersenne: taxifornia brownout You may have heard that our so-called Governor, here in the great state of Taxifornia has proposed replacing rolling blackouts with universal brownouts: reducing line voltage about 10-15% on hot days this summer. Any guesses at how that will effect a computer running GIMPS? spike _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 09 Jun 2001 23:01:50 -0400 From: vincent mooney <[EMAIL PROTECTED]> Subject: Re: Mersenne: taxifornia brownout I'd guess that sales of UPS's are on the upswing. At 05:20 PM 6/9/01 -0700, Spike wrote: >You may have heard that our so-called Governor, here in the >great state of Taxifornia has proposed replacing rolling >blackouts with universal brownouts: reducing line voltage >about 10-15% on hot days this summer. Any guesses >at how that will effect a computer running GIMPS? > >spike _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 9 Jun 2001 23:21:08 -0400 From: Pierre Abbat <[EMAIL PROTECTED]> Subject: Re: Mersenne: taxifornia brownout On Sat, 09 Jun 2001, vincent mooney wrote: >I'd guess that sales of UPS's are on the upswing. So how will that affect FedEx? phma _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 9 Jun 2001 22:53:03 -0700 From: "John R Pierce" <[EMAIL PROTECTED]> Subject: Re: Mersenne: taxifornia brownout > You may have heard that our so-called Governor, here in the > great state of Taxifornia has proposed replacing rolling > blackouts with universal brownouts: reducing line voltage > about 10-15% on hot days this summer. Any guesses > at how that will effect a computer running GIMPS? as long as the voltage stays above about 110V (they are talking about lowering the nominal voltage from 120 to 115), things should be fine. Geez, the switching power supplies in these PCs will probably run just fine on 90-100V (japanese power) - -jrp _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 10 Jun 2001 00:40:06 -0700 From: "Aaron Blosser" <[EMAIL PROTECTED]> Subject: RE: Mersenne: taxifornia brownout > You may have heard that our so-called Governor, here in the > great state of Taxifornia has proposed replacing rolling > blackouts with universal brownouts: reducing line voltage > about 10-15% on hot days this summer. Any guesses > at how that will effect a computer running GIMPS? Power supplies in today's PC's can usually switch fine down to 80-90 V AC. However, running like that for prolonged periods can cause problems in the long run since it forces the switching supply to run less efficiently. Also, brownouts can be really bad on motors. They have to work "harder" with less voltage and can easily burn out with as little as a 10% reduction in potential. In fact, for air conditioners, refrigerators, fans, etc. it's better to just turn them off during brownouts, otherwise you may be quite displeased to find that your refrigerator's condenser has pooped out on you, or that your ceiling fan is making unusual grinding noises now. Brownouts can even cause fires when marginal motors start to burn out and actually combust. No... that's why rolling blackouts are a MUCH better alternative than simply reducing line voltage. If they overdid it, you'd be creating much more problems. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 11 Jun 2001 17:10:48 -0500 From: "C. Daniel Sheets" <[EMAIL PROTECTED]> Subject: Mersenne: Interesting Results.txt Entries I had a computer working on an exponent. The computer did the self-test and passed, ran for a day (had 6 SUMOUT errors), started stage 2, got 78.57% through then had 3 more SUMOUT errors, then came these interesting lines: P-1 found a factor in stage #2, B1=150000, B2=1912500. ERROR: Factor doesn't divide N! Could someone please tell me what these are saying. The exponent that this computer was testing never fell off my list, yet the computer quit working on it and grabbed new exponents to work on. I have since added/reassigned the exponent to another of my computers to see if the same thing happens. I am suspect of the computer because of the SUMOUT errors and will look at heat and memory issues. Thanks for your time. C. Daniel Sheets Senior Systems Analyst Nephrology Analytical Services A Division of Minneapolis Medical Research Foundation United States Renal Data System Coordinating Center [EMAIL PROTECTED] [EMAIL PROTECTED] _________________________________________________________________________ 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 #860 ******************************
