Yeah, quick update part 5000:

*It 'aint the AMD CPU which is freezing. It's something other related to either MB/RD790/PLL/AOD. Because my chip has now started going whacko and boots stock (defaults) at 1.184V 2369MHz and 1.8V DIMMs. So when I try to underlock it to 2.3G after bootup, it freezes at 2.32G, 2.34, 2.35G.

This is why I said it's all just so flocked up and convoluted!!

*Also, I tried some cold at work v.quickly and whilst it booted -15C, the oc limit was still the same and now my temp sensors inside the cores have stopped working -> stuck at 0C. Even the internal tjunction sense is reading a little too low, usually it was at 33C idle in this environment 1.192V and now its at 23C, which is ambient. So its incorrect.

*And whilst my chip never booted 1.184V (reboot loops) I thought I'd get into Windows and P95 test and bench 1.184V idle/1.176V load 2.3G to see what happens. Well whadya know, it runs it perfectly fine, I gamed it after that:



This just makes no sense
So now I'm curious to know why the hell it won't boot with 1.184V.

*BIOS P0F even wth the patch disabled through the BIOS still degrades perf by a long margin. 1880KB/s compression to 666KB/s.

*People talk about "IPC" a lot but I don't know if they're unaware or not understanding enough but IPC is never constant and differs with every sort of software (instructions) used because some instructions are more complex and do more useful work than other simple ones, thus most software never utilizes max IPC capability of a core even for 1% of the runtime. Thus some software only utilize 0.8 i/c while others can get 2 i/c out of the same core. Those utilization near the maximum of the architectural limit show better perf. quite obviously and higher CPU power usage.

For instance. I ran benches and looked at IPC and L1/L2 accesses. Any benchmark/software which accesses L1 greatly with high IPC=higher power draw. As an example, Super Pi 32M only used maximum IPC of 0.8 i/c whilst EVEREST FPU Julia used 2.5 i/c and Prime95 utilized 1.7 i/c fixed (hence the power -> v.high each core utilization). Any software which can utilize near the maximum IPC limit with complex instructions will in effect perform far better than if it used simple instructions with low IPC usage. You can see P95 above and EVEREST FPU Julia here:



*Another problem I noticed whilst debugging SuperPi on this platform. There's an unnecessary delay hence the times are slower than they should be (which doesn't happen on X2/P4/C2). No idea about others but this is the case with mine. Writes to HD by SuperPi are being denied which is adding latency/wasting clock cycles because until that data is written the calculation doesn't move on. Out of 37,xxx events a minimum of 500 (v.reserved there) were write failures and another 500 were just rewrite attempts. Why? The reason given was "too fast I/O". See below for what I mean:



More confusion, more problems.

Here's some Pi 32M action for you to compete with.
1.5minute compared to 32minutes for SPi mod 1.5, talk about inefficiency.