Prime95 version 27.3

[erg]

If you read my original post, I'm asking if it's my hardware or a software bug. I have been running prime95 over the years (I think I first ran it on a 486) and I know that it's used to find bugs in hardware. However, I'd be a bad tester if I didn't report that it crashed and the output log, especially on a unreleased version of mprime that uses a new instruction set.

[flashjh]

Originally Posted by erg

If you read my original post, I'm asking if it's my hardware or a software bug. I have been running prime95 over the years (I think I first ran it on a 486) and I know that it's used to find bugs in hardware. However, I'd be a bad tester if I didn't report that it crashed and the output log, especially on a unreleased version of mprime that uses a new instruction set.

Have you tried 26.6 yet?

[cheesehead]

Originally Posted by Dubslow

His point was that he has two identical machines, each at the same hardware settings.

When Intel manufactures a given type of CPU chip, it tests each finished chip at a range of clock speeds, then divides the chips according to how fast each chip operates stably. That is, there's nothing different about the manufacture of, say, a 3.2 GHz chip and a 3.4 GHz chip of the same line, except that various impurities and manufacturing variances result in the second chip's slightly greater ability to run stably during that final manufacturing test (and so, Intel can charge a higher price for the second chip).

His having two supposedly-identical machines, each at the same hardware settings, does not imply that each will necessarily run stably at the same overclock speeds.

You appear to know all this already ...

However, I do agree with you that it is more likely to be bad hardware than an MPrime bug.

... yet you write "more likely" rather than "almost certainly"? :-)

MPrime runs on other OCd SB-E machines fine (not sure about the RAM OC)

There's _no_ reason at all why Mprime should not run fine on OC'd RAM, too, as long as the hardware itself performs correctly. There is nothing in Mprime (or other GIMPS software) that is hardware-speed-sensitive for correct execution.

Edit: Going back and rereading the posts, the "Illegal instruction" is not an error typically associated with hardware problems.

The hardware can drop a bit in a branch address or instruction code, now and then, when stressed by high clock speed.

[James Heinrich]

Originally Posted by cheesehead

Are you aware that when Intel manufactures a given type of CPU chip...

It's not just Intel, nor CPUs. His 2133MHz RAM is no different than "slower" RAM, except for whatever QA process the manufacturer put it through seemed to indicate it could operate adequately at the higher speed.

[kladner]

When RAM is run at its higher limit there are questions as to timing, voltage, and so on. And, particular groups of specimens from a product line will have variations which may add up in different ways.

These machines might run stably at the same OC, but might need different tweaks.

I suggest running memtest86+ on the machine with errors. If it passes a couple of full cycles of tests there, then look to other causes. Memory faults are a fairly common cause for some kinds of P95 errors. It might even be that the one machine has a borderline or defective memory part.

EDIT: It wouldn't hurt to run memtest86+ on both machines.

Download from memtest.org-

http://www.memtest.org/#downiso

[LaurV]

@OP:

From the Prime95 documentation, stress.txt file, the last FAQ section:

FREQUENTLY ASKED QUESTIONS
--------------------------

Q) My machine is not overclocked. If I'm getting an error, then there must
be a bug in the program, right?

A) The torture test is comparing your machines results against
KNOWN CORRECT RESULTS. If your machine cannot generate correct
results, you have a hardware problem. HOWEVER, if you are failing
the torture test in the SAME SPOT with the SAME ERROR MESSAGE
every time, then ask for help at http://mersenneforum.org - it is
possible that a recent change to the torture test code may have
introduced a software bug.

Q) How long should I run the torture test?

A) I recommend running it for somewhere between 6 and 24 hours.
The program has been known to fail only after several hours and in
some cases several weeks of operation. In most cases though, it will
fail within a few minutes on a flaky machine.

Q) Prime95 reports errors during the torture test, but other stability
tests don't. Do I have a problem?

A) Yes, you've reached the point where your machine has been
pushed just beyond its limits. Follow the recommendations above
to make your machine 100% stable or decide to live with a
machine that could have problems in rare circumstances.

Q) A forum member said "Don't bother with prime95, it always pukes on me,
and my system is stable!. What do you make of that?"

or

"We had a server at work that ran for 2 MONTHS straight, without a reboot
I installed Prime95 on it and ran it - a couple minutes later I get an error.
You are going to tell me that the server wasn't stable?"

A) These users obviously do not subscribe to the 100% rock solid
school of thought. THEIR MACHINES DO HAVE HARDWARE PROBLEMS.
But since they are not presently running any programs that reveal
the hardware problem, the machines are quite stable. As long as
these machines never run a program that uncovers the hardware problem,
then the machines will continue to be stable.

[ilkyest]

Hello pals

I'm trying donwload the source, but it stops at 8%

There's another mirror to download it? I'm trying linux-64 one

[Paulie]

v7.3.1

My currently assigned LL tests went from 0.019/0.020 to 0.016/0.017 doing two LL's with 2 workers with 4 threads.

Changed it to 2 workers with 2 threads, and now it's 0.014/0.015. Think I should leave it here? :)

Compare your results to other computers at http://www.mersenne.org/report_benchmarks
Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
CPU speed: 3439.31 MHz, 4 hyperthreaded cores
CPU features: Prefetch, MMX, SSE, SSE2, SSE4, AVX
L1 cache size: 32 KB
L2 cache size: 256 KB, L3 cache size: 8 MB
L1 cache line size: 64 bytes
L2 cache line size: 64 bytes
TLBS: 64
Prime95 64-bit version 27.3, RdtscTiming=1
Best time for 768K FFT length: 4.491 ms., avg: 5.486 ms.
Best time for 896K FFT length: 5.444 ms., avg: 6.240 ms.
Best time for 1024K FFT length: 6.168 ms., avg: 7.625 ms.
Best time for 1280K FFT length: 7.959 ms., avg: 9.303 ms.
Best time for 1536K FFT length: 9.743 ms., avg: 11.358 ms.
Best time for 1792K FFT length: 11.762 ms., avg: 13.728 ms.
Best time for 2048K FFT length: 13.074 ms., avg: 14.491 ms.
Best time for 2560K FFT length: 16.186 ms., avg: 17.033 ms.
Best time for 3072K FFT length: 20.142 ms., avg: 20.391 ms.
Best time for 3584K FFT length: 25.137 ms., avg: 28.249 ms.
Best time for 4096K FFT length: 30.000 ms., avg: 32.604 ms.
Best time for 5120K FFT length: 36.839 ms., avg: 40.830 ms.
Best time for 6144K FFT length: 44.812 ms., avg: 49.416 ms.
Best time for 7168K FFT length: 52.300 ms., avg: 53.463 ms.
Best time for 8192K FFT length: 64.104 ms., avg: 70.425 ms.
Timing FFTs using 2 threads on 1 physical CPUs.
Best time for 768K FFT length: 3.325 ms., avg: 3.696 ms.
Best time for 896K FFT length: 2.891 ms., avg: 4.007 ms.
Best time for 1024K FFT length: 3.302 ms., avg: 4.762 ms.
Best time for 1280K FFT length: 4.239 ms., avg: 5.981 ms.
Best time for 1536K FFT length: 5.419 ms., avg: 7.148 ms.
Best time for 1792K FFT length: 6.457 ms., avg: 8.589 ms.
Best time for 2048K FFT length: 9.144 ms., avg: 9.697 ms.
Best time for 2560K FFT length: 8.886 ms., avg: 11.902 ms.
Best time for 3072K FFT length: 14.428 ms., avg: 15.856 ms.
Best time for 3584K FFT length: 17.372 ms., avg: 18.568 ms.
Best time for 4096K FFT length: 17.718 ms., avg: 19.569 ms.
Best time for 5120K FFT length: 24.748 ms., avg: 26.629 ms.
Best time for 6144K FFT length: 30.259 ms., avg: 32.215 ms.
Best time for 7168K FFT length: 36.635 ms., avg: 38.918 ms.
Best time for 8192K FFT length: 40.342 ms., avg: 44.105 ms.
Timing FFTs using 4 threads on 2 physical CPUs.
Best time for 768K FFT length: 2.380 ms., avg: 3.063 ms.
Best time for 896K FFT length: 3.696 ms., avg: 4.020 ms.
Best time for 1024K FFT length: 3.441 ms., avg: 4.359 ms.
Best time for 1280K FFT length: 5.157 ms., avg: 5.413 ms.
Best time for 1536K FFT length: 6.134 ms., avg: 6.601 ms.
Best time for 1792K FFT length: 7.748 ms., avg: 7.913 ms.
Best time for 2048K FFT length: 7.876 ms., avg: 8.463 ms.
Best time for 2560K FFT length: 8.953 ms., avg: 10.790 ms.
Best time for 3072K FFT length: 11.092 ms., avg: 12.802 ms.
Best time for 3584K FFT length: 14.431 ms., avg: 16.023 ms.
Best time for 4096K FFT length: 14.846 ms., avg: 16.779 ms.
Best time for 5120K FFT length: 18.036 ms., avg: 19.338 ms.
Best time for 6144K FFT length: 21.667 ms., avg: 23.123 ms.
Best time for 7168K FFT length: 26.077 ms., avg: 27.074 ms.
Best time for 8192K FFT length: 31.507 ms., avg: 37.065 ms.
Timing FFTs using 6 threads on 3 physical CPUs.
Best time for 768K FFT length: 2.689 ms., avg: 3.417 ms.
Best time for 896K FFT length: 2.745 ms., avg: 3.468 ms.
Best time for 1024K FFT length: 3.236 ms., avg: 4.197 ms.
Best time for 1280K FFT length: 3.820 ms., avg: 4.532 ms.
Best time for 1536K FFT length: 4.702 ms., avg: 5.250 ms.
Best time for 1792K FFT length: 5.540 ms., avg: 6.591 ms.
Best time for 2048K FFT length: 6.497 ms., avg: 7.486 ms.
Best time for 2560K FFT length: 7.792 ms., avg: 9.058 ms.
Best time for 3072K FFT length: 10.003 ms., avg: 11.712 ms.
Best time for 3584K FFT length: 11.770 ms., avg: 13.914 ms.
Best time for 4096K FFT length: 14.840 ms., avg: 15.970 ms.
Best time for 5120K FFT length: 18.398 ms., avg: 18.664 ms.
Best time for 6144K FFT length: 21.064 ms., avg: 21.364 ms.
Best time for 7168K FFT length: 22.786 ms., avg: 23.153 ms.
Best time for 8192K FFT length: 28.927 ms., avg: 31.337 ms.
Timing FFTs using 8 threads on 4 physical CPUs.
Best time for 768K FFT length: 2.369 ms., avg: 2.950 ms.
Best time for 896K FFT length: 2.835 ms., avg: 3.327 ms.
Best time for 1024K FFT length: 3.242 ms., avg: 3.842 ms.
Best time for 1280K FFT length: 3.885 ms., avg: 4.383 ms.
Best time for 1536K FFT length: 4.873 ms., avg: 5.024 ms.
Best time for 1792K FFT length: 5.862 ms., avg: 5.975 ms.
Best time for 2048K FFT length: 6.409 ms., avg: 6.510 ms.
Best time for 2560K FFT length: 8.186 ms., avg: 8.255 ms.
Best time for 3072K FFT length: 9.772 ms., avg: 9.922 ms.
Best time for 3584K FFT length: 12.079 ms., avg: 12.322 ms.
Best time for 4096K FFT length: 13.254 ms., avg: 13.447 ms.
Best time for 5120K FFT length: 14.245 ms., avg: 14.825 ms.
Best time for 6144K FFT length: 18.779 ms., avg: 19.279 ms.
Best time for 7168K FFT length: 22.479 ms., avg: 22.658 ms.
Best time for 8192K FFT length: 27.810 ms., avg: 28.033 ms.
Best time for 61 bit trial factors: 2.178 ms.
Best time for 62 bit trial factors: 2.193 ms.
Best time for 63 bit trial factors: 2.482 ms.
Best time for 64 bit trial factors: 2.556 ms.
Best time for 65 bit trial factors: 3.076 ms.
Best time for 66 bit trial factors: 3.618 ms.
Best time for 67 bit trial factors: 3.575 ms.
Best time for 75 bit trial factors: 3.477 ms.
Best time for 76 bit trial factors: 3.432 ms.
Best time for 77 bit trial factors: 3.485 ms.

[Dubslow]

Originally Posted by ilkyest

Hello pals

I'm trying donwload the source, but it stops at 8%

There's another mirror to download it? I'm trying linux-64 one

See http://mersenneforum.org/gimps

Originally Posted by Paulie

v7.3.1

My currently assigned LL tests went from 0.019/0.020 to 0.016/0.017 doing two LL's with 2 workers with 4 threads.

Changed it to 2 workers with 2 threads, and now it's 0.014/0.015. Think I should leave it here? :)

You do realize that two of your cores are not being used by Prime95? When I have hyperthreading on, I have four workers with two threads apiece, but both threads are on the same physical CPU; the simpler solution would be to just turn off hyperthreading, as I have now.

[bcp19]

Just noticed this and was wondering if this means the FFT may be too small(this has continued every 10k iter)?

Mar 11 15:37] Iteration: 29701632/332216777, ERROR: ROUND OFF (0.5) > 0.40
[Mar 11 15:37] Continuing from last save file.
[Mar 11 15:37] Resuming primality test of M332216777 using AVX Core2 type-3 FFT length 19200K, Pass1=768, Pass2=25K
[Mar 11 15:37] Iteration: 29692754 / 332216777 [8.93%].
[Mar 11 15:37] Possible hardware errors have occurred during the test! 1 ROUNDOFF > 0.4.
[Mar 11 15:37] Confidence in final result is fair.
[Mar 11 15:56] Iteration: 29700000 / 332216777 [8.93%].  Per iteration time: 154.336 ms.
[Mar 11 15:56] Possible hardware errors have occurred during the test! 1 ROUNDOFF > 0.4.
[Mar 11 15:56] Confidence in final result is fair.
[Mar 11 16:22] Iteration: 29710000 / 332216777 [8.94%].  Per iteration time: 153.918 ms.
[Mar 11 16:22] Possible hardware errors have occurred during the test! 1 ROUNDOFF > 0.4.
[Mar 11 16:22] Confidence in final result is fair.
[Mar 11 16:47] Iteration: 29720000 / 332216777 [8.94%].  Per iteration time: 153.768 ms.
[Mar 11 16:47] Possible hardware errors have occurred during the test! 1 ROUNDOFF > 0.4.
[Mar 11 16:47] Confidence in final result is fair.

[Prime95]

Originally Posted by bcp19

Just noticed this and was wondering if this means the FFT may be too small(this has continued every 10k iter)?

Prime95 will continue to warn you every 10K iterations about that one roundoff error - this is normal.

What isn't normal is the one roundoff error you did get. Worse yet, it wasn't reproducible. It might have been a true hardware error.

At a minimum, I'd turn on round off checking for every iteration. Report back with the maximum roundoff you are seeing.

P.S. Looking at the source, that FFT size is supposed to be good up to 352M. Looks more like a true hardware error. Torture test time.