The Stilt

Thanks for the bios. There is no difference in SuperPI performance between F2A85-V PRO and F2A85X-UP4, the times were within the margin of error. The CLK Mux feature is PLL related. There are two PLLs on F2A85-V PRO and F2A85X-UP4 which can be used to generate the BCLK frequency. One is located inside the FCH (Internal PLL) and the second one is the external located between the PCI-E slots. Even the F2A85X-UP4 features an external digital PLL, for some reason Gigabyte does not use it for BCLK until the adjustment range of the internal PLL has been exhausted (136MHz BCLK). I've asked the reason for this but they never gave me any answer. Asus F2A85-V PRO never uses the internal PLL for the BCLK, only the external. The CLK Mux controls the different frequencies. Without it enabled the all of the clocks are tied to BCLK. When enabled the clocks are separated by the mux control. The PCI-E frequency stays at 100MHz even when the BCLK is raised. I could not test the Gigabyte board above 108MHz BCLK as the board flips out after that when AHCI is enabled. No such issues on Asus.

On LN2 you can do 1.6 - 1.65V, depending on the leakage. At 1.7V or beyond the NB gets damaged (GPU first then the rest of it). Any chance you could upload the F3I bios for UP4? I have all of the other alphabets besides that.

1.4V, just outside the "kill zone"

No need for the videos, I never thought you would be cheating intentionally. Found one of the reasons why my time was so slow. On XP you'll just never ever - ever never disable the "Luna" theme. It is over four seconds faster than the Classic theme. A quite "nice" glitch. Still, I am atleast five seconds slower than I should be. The DRAM/NB timings have been tweaked as far as they go, the adjustment range has been literally exhausted. Cannot go any tighter. Still need to check something. I noticed that Gigabyte does not enable the "CLK Mux". I certainly hope this is not done on purpose, yet I would not be too surprised... http://www.hwbot.org/submission/2386335_the_stilt_superpi___32m_a10_5800k_18min_14sec_718ms

tCWL 5, 6, 7. 7 MEMCLKs appears to be the fastest. The difference is barely noticeable <0.1 sec. I´ll try on Gigabyte next time. There might be some differences in DRAM-NB calibrations, but nothing which could explain the difference.

Are you sure you did not forget "Turbo Core" on or something? Swapped the PSC to Elpida Hypers and did some tests. DDR-2133 7-7-5-19-1T is around five seconds slower than DDR-2666 9-11-8-24-1T. DDR-2400 8-9-7-24-1T is around two seconds slower than DDR-2666 9-11-8-24-1T. My 18.20.xx time was done on tweaked XP, it made around 6 seconds of difference. Your time should be atleast 2 seconds slower than mine as thats the difference between our memory frequencies. I also have tighten up the FIFO latency manually (these adjustments are not available on any motherboard), it is worth around 1 second. None of the tweaks (besides large system cache) made any difference, my OS is quite light by default (41MB RAM usage after boot). Purging the physical memory / releasing the system resource allocation (Wazaa) only seems to be worth of 0.5 seconds or so. So where has my 10 seconds gone

That is unacceptable! http://hwbot.org/submission/2385234_the_stilt_superpi___32m_a10_5800k_18min_20sec_219ms

It is decent. The trouble is that you need a high leakage part for 3D. There is a strict upper limit for UNB VDD which cannot be passed on any of the parts, no matter if they have low or high leakage properties. Or you can, but you'll kill the chip if you do. A part with higher leakage properties will require less voltage for frequency X than a part with lower leakage properties. The 'voltage range' will simply be exhausted too soon on the low leakage parts.

It has been so long since I really benched SuperPI so I've already forgot all of the tweaks The memory bandwidth on 15h is irrelevant on SuperPI while the global latency is everything, a complete opposite to 3D. A 1.6GB/s increase in the bandwidth yielded less than 2 second improvement, while the FIFO latency remained at the same level (MEMCLK/NCLKs). After calibrating certain settings manually I was able to disable SlowAccessMode and tighten up the internal syncronization. The 'data eye' is exactly where it should be, even I don't have a scope in my disposal Atleast I can say that ACI would have worked http://www.hwbot.org/submission/2384254_the_stilt_superpi___32m_a10_5800k_18min_26sec_479ms?recalculate=true The bandwidth and the latency seems to be okay too.

The "King Trinity" was better than I remembered. An early, low leak chip I binned a year ago. http://www.hwbot.org/submission/2384150_the_stilt_superpi___32m_a10_5800k_18min_34sec_512ms?recalculate=true

What alloy are you using? "Alloy 82" (Indium Corp)? Did you remove the oxidation prior applying the sTIM? Did you remove the nickel plating from the thermal interface area (core-IHS)? Questions, questions

7790s (or CIslands in general) have a new kind of power management which is very different compared to the previous generations. There are new PowerTune based limits for power and current. Asus HD7790-DC2OC-1GD5 has following limits: PowerTune Power Control Limit: 20% Base TDP: 100W cTDP: 110W (ODM & model specific) TDC: 82A (75A on reference card) Maximum Power Delivery Limit: 115W The current on 7790 cards is calculated based on CAC values (I think) so the calculations might flip when the temperature is under zero. On Tahiti cards for example there were just two PowerTune limits (1 & 2, in watts) which were controlled by the Power Tune Control Limit.

I don't feel too comfortable with the idea. Simply because I feel that the expenses belong to the manufacturers rather than to the customers who purchase their products. All the things the software would have done, should have been done by the manufacturers in the first place. The software has capabilities beyond pure overclocking, it can be used for debugging / troubleshooting and for power optimizations too. So the argument about it being unsupported because of overclocking and voided warranties is quite thin. I cannot even elaborate enough how frustrating it is to watch by. This is just one isolated case, the whole thruth is way much worse. Something is fundamentally very wrong with this industry. An uneducated and unemployed guy should and must not be able to constantly outperform most of the engineers and designers working in the leading positions. It is like guiding a surgeon thru your own heart operation. Sounds like mockery, yet it is anything but. It is a very sad and a frustrating fact. Anyway, the thread has derailed a bit: If I manage to get the required information and if I can get even one of the manufacturers to make their board to work as it should, then the software will be published as it was originally planned. Otherwise it will never be seen or heard again.

Unless I'm willing to do some jailtime, then no. The software contains too much of confidential information. Information which is not only related to AMD but on other companies too. Without this information the functionality of the software would be very limited. It would not have anything which AOD for example does not have. It would not justify the amount of work required.

Asus did more than any of the other vendors combined. They made the changes and fixes I asked them to do. They shared the information about their products and helped me in every way they could. They even sent me components from the factory for the reworks I wanted to try out to improve the overclockability. Of course they did get something in exchange, I shared features such as "BApm", "Master Powermode" and "GPU Unlock" with them. They also got good rep. and test information to use in their future products. So when people say I favor Asus while pissing on the others vendors, what can I say? Thats the truth. In fact I would favor ANY vendor who would do the things Asus has done and would make as good products as they do. The vendors who make bad products and are not even trying to improve them, and on the top of that take a piss on me by stealing (cracking) my work... I could compare them to stray dogs, which I don´t do as I happen to like stray dogs Still even Asus boards are not perfect. They too have bugs which have appeared in the newer bios versions and some of the GPU related things are just as flaky as on other boards. This is partitially because even the vendors do not have an unrestricted access to all of the documentation...

I was working on OCI (Orochi Control Interface) too. The "core" of the software was already fully compatible as the basic Core/CNB/IMC structure is nearly identical between Orochi and 15h APUs. Eventhou the support for Barracuda platform requires roughly 1/10 of the work compared to 15h APUs, I chose to start with the APUs first. Simply because the APUs needed it so much more. For the CPU/NPUs there is really no 'magic' you can do, unlike for the APUs.

I've had enough. I am ready to "pull the plug" on this project. I feel like a god damn Don Quijote. The complete lack of communication makes this task impossible. At no point I have received any support from AMD or any of the motherboard vendors (Asus being a slight exception). It is like squeezing water out of a stone. Even for the smallest drops of information I had to either bribe, blackmail or steal. The rest (99.5%) I had to figure out by myself, which I did well. On the top of that my work gets "erased" regular basis. Either by AMD or by the motherboard vendors. AMD makes changes by changing the behavior of the display driver (which controls everything on APUs). The motherboard vendors seem to have hard time following the design guidelines which is the biggest spike in my flesh. The motherboard vendors put all of their resources on Intel platforms and none on AMD (can't blaim them really). Even after seven months after the launch of Trinity APUs the bioses are still in the "twilight zone". The bioses are riddled with bugs and some of the "tweaks" the vendors use do more harm than good. They also rarely follow the official design guidelines so I cannot make a unified solution which would work on all motherboard. Bioses are nothing like wine, they don't get better when they get older. They are more like a opened beer bottle. For every single fixed issue atleast two more will emerge. I have sent too many emails and used way too much time in trying to help the vendors to fix the issues. I have even sent them the fixed version of the actual code to make it easier for them to fix their bioses. Still they are not able / willing to do anything about it. I never asked any money or anything else from anyone (a one big f__king mistake really). If I would have been paid, lets say even 20 euros per each hour I have spent on ACI/TCI (or on the APUs in general), I would be around 15k euros richer. Better go filling McDonald's™ job applications. Sorry guys

TCI K2 has escalated into something else... Rather than being a evolution version, I have fully rewritten the software. Since it now supports Richland APUs too, the name "Trinity Control Interface" was no longer suitable. Therefore the new name of the software is "APU Control Interface". Changes: - Supports all 15h (10-1Fh = Richland, Trinity) based APUs / CPUs, desktop, mobile and embedded (locked and unlocked parts). - Uses dedicated drivers to access the HW, no 3rd party software assist required (TCI K2 uses R&W). - GPU Frequency Unlock (unlocks the SCLK frequency on locked APUs). - Power Calibration (With "Aggressive" setting up to 20% power reduction can be achieved, without losing any performance). - Additional memory timing parameters (NB Sync, RdPtrInit, etc). - Leakage values are no longer estimated, they are part specific (based on factory data). - Improvements... everywhere. - A GUI It will still take some time until it is ready for release.

Or air cooling? If so it is most likely either VR_Hot (VRM) or CPU HTC activation (@ 70,0°C). Enable "PowerMode" with TCI K2 and see if it makes any difference. However it certainly isn´t VRM OCP.

Version 1.1 Changes: Added a motherboard specific profile (ASRock FM2A85X Extreme6) Added Pll gearing advisor for internal FCH (A55/A75/A85) Pll*1 Added DRAM Refresh Rate (tREF) reading and adjustment Extended UNB Vdd range up to 1.57500V on all SVI2 compliant VRM controllers*2 Added VRM Status (diagnostic) menu for selected motherboards (PMBUS)*3 Fixed divider calculation on internal FCH Pll (maximum precision and range allowed by hardware available now) Fixed N (M/N) ratio calculation issue on ICS477 ext. Pll Re-enabled full BApm control*4 *1 Due the fact that the internal Pll of the FCH is fairly inaccurate, I added a "gearing / frequency advisor" to help users to find the most accurate output frequency available. "Internal Pll Next Gear" shows the next possible BCLK frequency while the "Internal Pll Previous Gear" shows the previous (lower) frequency, if available. The new BCLK frequency is inserted as usual (in xxx.x or xxx,x format) and the programming values are exactly the same as shown in "Previous & Next Gear" lines. Do note that other frequencies than the ones displayed in "Previous & Next Gear" lines are NOT available. Inserting any other values will result undefined behavior. Also to keep everything syncronized properly, change the BCLK frequency in small steps. Some of the domains will get out of sync at some point regardless of the size of the adjustment steps. In this case increase the BCLK frequency a bit from the bios and try again. The adjustment range is ~100.0 - 141.4MHz (HW limitation with default configuration). *2 Anything higher 1.47500V for the UNB can damage the APU permanently in normal operating temperatures. Parts with higher nominal leakage can be damaged with less than that so beware! *3 VRM diagnostic info and Loop 1 (Core VRM) / Loop 2 (UNB VRM) temperature reading available on: ASRock FM2A85X Extreme6, Gigabyte F2A85X-UP4 & MSI FM2-A85XA-GD65. *4 BApm + other power management features are FULLY disabled by a special test mode. When disabled there is basically no power management available, no limiters -> wide open throttle all the time. The APU WILL EXCEED the TDP when BApm is turned off. Domains critical to performance (NCLK) will be locked to maximum performance PState. Available under: 7. Power & Thermal Management -> Command "BApm" -> Enabled or Disabled. NOTE: Some versions of Catalyst display drivers & SMC firmware will re-enable BApm automatically. TCI K2 V1.1 //MOD-BREAK: also uploaded V1.1 to our server, link: http://downloads.hwbot.org/downloads/tools/TCIK2_V1.1.zip

F2A85-V Pro tuned further, phase two... Soon...

Yeah, me and macci had the AMD OC Challenge 2012 venue at Akiba. Two Contour 2+ HD (POV view), 2x static HD cams and several press operated still / video cams were running. Atleast 38+ hours worth of video to be edited FPSI: 2012 / 37 - Penang Malaysia, Line T (PGT) - Lot P/N F356-1K - Core PS0 Fuse 0x20h (1.35000V) - IMC PS0 0x3Ch (1.17500V), IMC Delta Fuse (0x2h negative).

Thanks =) @ Massman: I´ve posted max CPU frequency results on three different 5800Ks. I am seeing around 100-300MHz improvement with the recent modifications. 7.32GHz (from July) -> 7605MHz max. 7.60GHz -> 7785MHz max. 7.81GHz -> 7938MHz+ max (live at Akiba) With a golden chip 8GHz+ is a fact. These chips are not even specially binned, the one that does 7938MHz is a recent retail CPU