Re: Mersenne: Weird ILLEGAL SUMOUT
Hi, At 10:48 PM 6/24/00 +0200, Steinar H. Gunderson wrote: >This machine is overclocked (112MHz x 4.0 for a 400MHz Pentium II), but >it has run mprime (and about 100 hours of torture testing in one go) stably >for about two years now. What puzzles me, is that there are only 42 >iterations from the saving to the illegal sumout... Isn't it so that mprime >only checks for errors every 64 iterations or something? The ILLEGAL SUMOUT and SUMINP != SUMOUT error checks are done on every iteration. The good news for you is that mprime usually recovers from ILLEGAL SUMOUT errors without any problems. > In that case, could >the saving (I'm using Linux 2.4.0-test1 and an unstable ReiserFS patch as >well -- not exactly the `safest' platform, but we run these QA tests on pairs >of machines and compare residues during the entire test) have caused the >error? It could have - all it takes is one driver or OS bug that does not save the FPU state properly to cause this error. REgards, George _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Weird ILLEGAL SUMOUT
Hmmm... Just a few minutes ago, my mprime v20 gave me: Iteration: 8312000 / 15269993 [54.43%]. Per iteration time: 0.424 sec. (190008097 clocks) Iteration: 8312694/15269993, ERROR: ILLEGAL SUMOUT Possible hardware failure, consult the readme file. Continuing from last save file. Waiting five minutes before restarting. Resuming M15269993 at iteration 8312652 [54.43%] Iteration: 8313000 / 15269993 [54.44%]. Per iteration time: 0.428 sec. (191927493 clocks) Iteration: 8314000 / 15269993 [54.44%]. Per iteration time: 1.913 sec. (857236303 clocks) This machine is overclocked (112MHz x 4.0 for a 400MHz Pentium II), but it has run mprime (and about 100 hours of torture testing in one go) stably for about two years now. What puzzles me, is that there are only 42 iterations from the saving to the illegal sumout... Isn't it so that mprime only checks for errors every 64 iterations or something? In that case, could the saving (I'm using Linux 2.4.0-test1 and an unstable ReiserFS patch as well -- not exactly the `safest' platform, but we run these QA tests on pairs of machines and compare residues during the entire test) have caused the error? /* 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
Re: Mersenne: Contact Primenet
George Woltman wrote: > >There used to be an option in Test->Primenet to force a connection. > > It was moved to Advanced / Manual Communication. Thanks everyone, I am guilty as charged; I did not read the Whatsnew. I'm not sure why this action deserves to be "Advanced" and require the password to activate. Still, that isn't hard to do. Cheers... Russ _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: HLLLL and HLL....
Hi: [EMAIL PROTECTED] wrote: > < accurately, you'd really need the separate code fragments to be in > their own dedicated segments. This is not the way that un*x or Win32 > applications are usually coded. > > Not being up on the latest HLL compilers, I would still suspect that some > compiler directives/options would be available to handle alignment properly > without much headache, especially if it is as important as you suggest.>> > > I have the teensiest fraction of knowledge about C (I'm trying to learn it > now), but I know a little about compiling C programs. With DJGPP, you can > enable cool options like -malign-double which can really speed up some > programs. Is this the "alignment" that you're speaking of? > On IA32 system, the alignment is one of the most important factors to achieve a decent performance. Unfortunately, some compilers (GNU/gcc) do not make the alignment correctly in a easy way. When writing Glucas, I discovered than -malign-double only aligns double when they are global-static variables. The local variables on the stack are not aligned, there is only a 50% chance of that (because they are 4-byte aligned). In a bad alignment scenery the performance can drop to the half (or even more). To achieve good performance I had to try the the same trick based in a built-in malloc than FFTW uses, i.e., allocate conditionally 4 bytes in the calling routine and so the doubles on the called are properly aligned, an ugly solution, you see. Regards Guillermo. _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
