Prime95 version 27.3

[rjs5]

You can find Intel CPU information on the site below.
http://ark.intel.com/

A comment about performance. It appears that the source contains software PREFETCH instructions in a loop to gang prefetch the data before it is actually used. You might check the source code build and analyze the prefetch pattern.

Each CPU has a limited number of memory Read/write operations that can be active at any one time. After that maximum number is reached, the earlier CPU (P4 I think) would cancel a SW prefetch and the cache line would not be read.

Today, a SW prefetch will be completed. If the maximum number of Read/Writes has been reached, the prefetch instruction will stall until resources are available. An NTA prefetch should not evict a modified line but it could possibly evict earlier prefetched data. The earlier prefetch would be waisted.

If you are running two different workloads on one core and its Hyperthread, the prefetch from loop of one might similarly evict valid, useful data from the cache. It is more likely to happen since a core and its hyperthread share the cache.

The number of memory buffers per core is likely to be something in the 8 to 16 PER CORE range. Prefetching more will just cause a "read" stall.

Making sure the prefetching does not get too far ahead and stall execution or evict data needed, you can probably break up the prefetching so there is less pressure on the bus and hyperthread cache.

[fivemack]

It is an unstable box; the whole point of mprime is that it's been tested on enough machines that error messages of this kind mean your machine is broken.

[James Heinrich]

Immediate reproducable crash on very-small FFT:

Pminus1=N/A,1,2,10061,-1,1000000000,100000000000,60

P-1 on M10061 with B1=1000000000, B2=100000000000
Chance of finding a factor is an estimated 24.5%
Using AVX FFT length 512
SUMOUT error occurred.
Waiting five minutes before restarting.

[Prime95]

Originally Posted by James Heinrich

Immediate reproducable crash on very-small FFT

Thanks. For now, turn on round-off checking and the error should go away.

[Dubslow]

Originally Posted by fivemack

It is an unstable box; the whole point of mprime is that it's been tested on enough machines that error messages of this kind mean your machine is broken.

His point was that he has two identical machines, each at the same hardware settings. One (appears to be) is stable, the other isn't. However, I do agree with you that it is more likely to be bad hardware than an MPrime bug. MPrime runs on other OCd SB-E machines fine (not sure about the RAM OC), so try and figure out what would cause that particular error. Have you tried MPrime's torture test or memtest?

Edit: Going back and rereading the posts, the "Illegal instruction" is not an error typically associated with hardware problems. Reading the post after his, talking about prefetching and stuff, might be of relevance (but why one box and not the other?). I guess more memtest :P

[erg]

Both machines have the RAM set to 2133. I'm inclined to believe one of them is unstable, but this mprime is a beta version or something, so I thought I'd get a second opinion.

I will run more tests on the machine and perhaps put the RAM back to the default clock.

[Dubslow]

The RAM speed might be messing with MPrime, seeing as I don't think anybody else has used RAM that high with AVX, but then again, your other machine appears to be working fine, so I think it's unlikely to be MPrime with the bug.

[chalsall]

Originally Posted by erg

I will run more tests on the machine and perhaps put the RAM back to the default clock.

That would be a really good idea.

Based on heuristics, before you think that Prime95/mprime has a bug, assume your hardware is the problem.

Particularily if you are trying to push your hardware past its manufacturing specs....

[flashjh]

Originally Posted by erg

Both machines have the RAM set to 2133. I'm inclined to believe one of them is unstable, but this mprime is a beta version or something, so I thought I'd get a second opinion.

I will run more tests on the machine and perhaps put the RAM back to the default clock.

Anytime you get errors with MPrime/Prime95, it just about 100% likely a hardware problem (Maybe 101%)


Overclocking is also a good way to get errors, but MPrime/Prime95 are used to burn-in testing all the time. People often sell their systems as Prime95 stable, and for good reason. If you can get 72+ hours on a full Prime95 burn-in test with no errors, you almost certainly have perfect hardware.


With that said, you have two options:


1. Remove the overclock and retest. This option will tell you about the overclock and also test the rest of the hardware again.

2. Start swapping components between the computers, one at a time so you know what causes the problem. I'm inclined to think the memory and then the motherboard, but you never know.

Just keep in mind that no hardware is ever exactly the same. Though it would be nice, you're not likely to get a 100% match for any two builds. It's quite possible you'll get one system 100% stable on overclock and another that won't get 100% stable unless you're at stock. Good luck.

[Dubslow]

He said the RAM was rated for 2133, so technically only the mobo is overclocking with the ram interface, but the RAM itself should be fine.

[James Heinrich]

Originally Posted by Dubslow

He said the RAM was rated for 2133, so technically only the mobo is overclocking with the ram interface, but the RAM itself should be fine.

Not necessarily. My RAM is rated for 1600, but I can only get the system 98% stable at "stock" RAM speed no matter what I do. Dropping the RAM clock solved all my stability issues. RAM vendors are unfortunately aggressive with their marketing of high-speed RAM (there's not usually a lot of safe headroom, sometimes (as in my case) even negative headroom).