Stock system fails stress test

[PetrolHead]

To begin with, here are my system specs:

CPU: AMD Phenom II X6 1090T BE
GPU: NVidia GTX 650
MB: ASRock 970M Pro3
RAM: 2 x 8 GB Kinston HyperX Fury Black DDR3 (official numbers 1600 MHz CL10, stock values 1333 MHz CL9 due to Phenom II)
PSU: Cooler Master V650S
HDD: Samsung 850 EVO SSD 250 GB
Case: BitFenix Prodigy M
CPU Cooler: Arctic Cooling Freezer A11
Fans: 2 x BitFenix Spectre 120 mm
OS: Windows 8.1 64-bit & Linux Mint 17.2 Cinnamon 64-bit

I was taking a swing at overclocking my current system and had ended up with what I thought was
a pretty stable overclock. I could run Prime 95 with all of my six cores for 8 hours without any errors
and I also cleared 4 hours of Prime95 with a single worker while testing the stability of my OC'd Turbo
Core mode. Socket temp maxed out at the recommended 70 C limit and CPU temp maxed out around
54 C. I ran different benchmarks (GeekBench 3.3, PerfomanceTest 8.0, Cinebench R15, Unigine Heaven,
3DMark11, 3DMark, CPU-Z, SuperPi mod1.5 XS, SiSoftware Sandra Lite 2015.SP3) and encountered
no issues with any of them. Even RealBench benchmarked without a glitch. However, while running the
RealBench stress test (set for 16 GB and 2 hours) I got nine result mismatches in the first 90 minutes or
so (I was afk, so couldn't stop the test before). I know that passing Prime95 or having low temps do not
guarantee stability, but I was still surprised to run into an issue. Naturally, I started to lower my already
very mild OC and running the stress test again. Then I reached stock values and I still get a result
mismatch withing the first 700 seconds of the test.

So far I have tried relaxing my RAM timings a bit and even running it with as 1066 MHz CL7 (SPD values
for this clock speed), but to no avail. I've been looking at the log files, trying to find any and all error
messages, and I found this at the beginning of the log file:

Handbrake: x264 [warning]: --psnr used with psy on: results will be invalid!
x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!

It seems that it takes the stress test about 700 seconds to finish one cycle. Now, if the above error message
means what it sounds like, I will always get an error message when the cycle finishes, no matter what I do.
Could this be the reason the test fails even when the system is running at stock values? The benchmark
itself I've run 10 times in a row without any stability issues with a stock system. I would welcome any tips
and possible explanations.

P.S. It should be noted that the RAM modules aren't officially supported for my motherboard. Kingston's
memory search suggests these for the ASRock 970 Pro3 R2.0, which is essentially the ATX-sized version of
my mATX motherboard. ASRock just hasn't tested this kit on the motherboard, so can't really guarantee
compatibility. This is why I've concentrated on trying to find a stable timing for the RAM, but then again
I've had zero issues with my stock system before running RealBench stress test. If the RAM was really
incompatible, I wouldn't expect it to be as stable as it has been.

P.P.S I am at the moment running Prime95 with custom settings so that it uses all of the 16 GB of RAM I
have. It has been running for a bit over an hour now without any issues.

Edit: I forgot to mention that I'm running RealBench 2.41and I've also tried running the stress test using
8 GB of RAM, but the result is the same.

[lunatic987]

PetrolHead wrote:


I don't know if this is the same problem as with the RB's ST, but the above at least produced a problem. The
SHA-1 hash I get is:

"B057ABE9F6B48CA1C35316B1145064A23F8FDB13"

This is clearly not the hash it should be. I ran the test again and the resulting file had the same hash the first
one had. So, the error at least seems consistent. Would I be correct to assume that this means the GPU is most likely
the reason for my RB related issues?

Wow, I had to sign up twice just to post. I had searched because Realbench stated I had a hash error of some type. I found this thread, and followed given instructions to generate it again via blender. The hash from the jpg blender generated was exactly the same as above. I found it rather interesting that not only was the hash different than expected as well, that it exactly matched this one, thought to be an error.

[Nodens]

I am not sure what type of flickering you are getting from your description. But opaque triangles like the one you describe are usually pointing to a faulty or overheating card. I've also seen them with faulty SLI bridges but you're not on an SLI setup. Have you checked the GPU temperatures while playing and while running the ST?

Now regarding the hash, that is not the hash you should get for sure. Just to rule out the tool you used for hashing, can you please use this: http://implbits.com/products/hashtab/ (It adds a tab on windows file properties that show you all kinds of hash algos..very convenient for checking file integrity as well and it's free). The fact that it is consistent is strange. Although I would like to see if the result is the same for say 10 runs.
Are you on the latest driver (358.91)?
Also can you run the command again but this time like this:
"blender -b bmps.blend -F JPEG -o out -t 0 -f 1 --debug-all >debug.txt"
Then zip the jpeg file along with the debug.txt, upload the zip somewhere and give me the link.


EDIT: One last question. Do you have any version of python installed on your system? Can you type "set" in a command prompt and on the output check if there are PYTHONHOME and PYTHONPATH variables declared (in case you're using an application with bundled python that also decided to export it's python installation globally)?
It will look like this for example:
PYTHONHOME=C:\Code\Python27
PYTHONPATH=C:\Code\Python27

[PetrolHead]

Nodens wrote:
I am not sure what type of flickering you are getting from your description. But opaque
triangles like the one you describe are usually pointing to a faulty or overheating card. I've also seen them with
faulty SLI bridges but you're not on an SLI setup. Have you checked the GPU temperatures while playing and while
running the ST?

The flickering looked a bit like there was a shadow around the ancient (a structure inside the base), which
turned on an off at a rapid rate. I tried to reproduce the graphical bugs yesterday, but didn't manage to
do so, even after the GPU had reached it's peak temp during DotA. Also, if I remember correctly, when
the bugs have appeared, they've appeared the second I start to play or watch a tournament match. If
there haven't been any bugs at the start, they haven't appeared during the match either. I'll keep trying.

I had checked the GPU temperatures before, but hadn't written them down, so I re-checked them yesterday.
During RB's ST the GPU temp reached 52 C just before the first cycle finished and the first mismatch was
noticed. Before that it had stayed at 51 C for almost 6 minutes, so it wasn't going to go much higher.
During DotA 2 the GPU temp had at some pointed peaked at 59 C - possibly during a big team fight - but
mostly hovered between 54-56 C. Also, during Unigine Heaven Extreme the GPU temp is around 59-60 C,
but doesn't usually go beyond that.

Now regarding the hash, that is not the hash you should get for sure. Just to rule out the tool you
used for hashing, can you please use this: http://implbits.com/products/hashtab/.

Done. That one gives the same hash. The program I initially used was 7zip.

The fact that it is consistent is strange. Although I would like to see if the result is the same for
say 10 runs.

So far I've only done four runs and all result in the same hash. I'll play around with the GPU and system settings
and see if I can get different hashes. Partially because I'm currently running a light OC at the moment, and partially
because I want to see if running the GPU at a slower speed makes a difference. The hash might still be wrong, but
if I get it to change by changing something, that could help pinpoint the source for the error.

Regarding my OC, my current settings are as follows:

GPU - stock
RAM - OC'd from 1333 MHz 9-9-9-25-1T to 1600 MHz 9-9-9-25-2T, voltage changed from 1.585V to 1.5V
CPU-NB/HT - OC'd from 2000 MHz to 2200 Mhz, stock voltage
CPU - Turbo Core mode OC'd from 3,6 GHz to 4,0 GHz, otherwise stock (including voltages)

The OC has been achieved purely by changing the multipliers. I haven't touched the FSB frequency,
nor the PCI-e frequency. The SSD drive is in AHCI mode, but I haven't checked if the firmware is
up to date. That'll be next on my list.

Are you on the latest driver (358.91)?

Yes.

Also can you run the command again but this time like this:
"blender -b bmps.blend -F JPEG -o out -t 0 -f 1 --debug-all >debug.txt"
Then zip the jpeg file along with the debug.txt, upload the zip somewhere and give me the link.

I'll PM you the link.

EDIT: One last question. Do you have any version of python installed on your system?
Can you type "set" in a command prompt and on the output check if there are PYTHONHOME
and PYTHONPATH variables declared (in case you're using an application with bundled python that
also decided to export it's python installation globally)?
It will look like this for example:
PYTHONHOME=C:\Code\Python27
PYTHONPATH=C:\Code\Python27

I haven't installed Python and the above variables haven't been declared. The only Python-files I have
at the moment are in RealBench directories.

[PetrolHead]

I just noticed that running the blend command from the command line doesn't seem to load the GPU up at
all. The GPU stays in its lowest, "2D Desktop" power setting and doesn't show any activity above what it
has to do when displaying the desktop. The CPU on the other hand is under 100% load, so I'm going to
concentrate on trying different underclocking settings in the next couple of days. I tried the following settings a
few minutes ago, but the hash remained the same:

CPU - Turbo Core still OC'd as stated previously, but clock speed under full load lowered from 3200 MHz -> 3000 MHz
CPU-NB/HT - Both underclocked from 2200 MHz to 1800 MHz

I did try to run the RB's ST with the GPU core and memory underclocked by 100 MHz each and increased the fan speed,
which kept the GPU temp at 43 C or below. Still resulted in a mismatch.

[PetrolHead]

lunatic987, could you share your full system specs and possibly a screen capture of CPU-Z which shows the
revision of your CPU? It seems that Blender is doing things slightly differently on my processor (AMD Phenom
II X6 1090T BE, revision PH-E0), possibly to work around some design errors and mistakes that are specific
to this processor revision. This is why the hash is different and why it's consistent. This also means
that it's nothing to worry about.

[lunatic987]

PetrolHead wrote:
lunatic987, could you share your full system specs and possibly a screen capture of CPU-Z which shows the
revision of your CPU? It seems that Blender is doing things slightly differently on my processor (AMD Phenom
II X6 1090T BE, revision PH-E0), possibly to work around some design errors and mistakes that are specific
to this processor revision. This is why the hash is different and why it's consistent. This also means
that it's nothing to worry about.

oh I'm definitely not concerned with it, just had wondered why realbench was stating that that there was a hash error first time trying to use it.

no need for a screen cap, it's Phenom ii x6 1100T BE, revision PH-E0. The fact it was consistent for you, and then for me, would have ruled out any concern. Of course since blender is reporting differently, this would actually fall back to realbench needing a specific check for this (which considering age of processor I doubt it would be worth the effort, and we have a way around it, with an apparent correct SHA-1 hash)

edit: However,
cpu: AMD Phenom II x6 1100T BE, with a aftermarket heatsink forget brand atm. Typically I keep it barely overclocked ~3500 mhz at bios auto voltages.
GPU: R9 290
MB: Asus M5A97
Ram: 4x4 GB corsair vengeance 1600 ddr3
PSU: Corsair X750M
HDD: Intel SSD 120 GB + a few Sata HD.
OS: Windows 7/64

Only reason I tried out realbench was to see what it was really, and to compare some minor tweaking I was going to try, however, heat remains an issue for cpu/mb (oddly not the graphics card) and has always been no matter what I've tried with the case, which happens to be older 4 bay tower.

[Nodens]

Yep both chips are the same PH-E0 revision.

New version coming up shortly that handles these CPUs and any other possible CPU in which Blender may use different algorithms for. New version will check against the first computed hash instead of the constant that computes for everyone else.

[demoncamber]

Bingo, I think I just found my issue.
PH-EO here as well.

[Nodens]

Wait for new version please.

[demoncamber]

No problem dude! Thank you for your hard work.