Overclock.net › Forums › Intel › Intel Motherboards › Asus Rampage V Extreme Owners thread
New Posts  All Forums:Forum Nav:

Asus Rampage V Extreme Owners thread - Page 979

post #9781 of 10638
Quote:
Originally Posted by Qwinn View Post

So, the moral of the following story is, Never Condescend To A Cuban
Warning: Spoiler! (Click to show)
(Context here: http://rog.asus.com/forum/showthread.php?59803-Does-anyone-have-adaptive-cache-voltage-working/page4

Adaptive Cache:
Cache Multiplier: 38x
Offset: Auto
Additional Turbo Cache Voltage: 1.60

Cache voltage idles at 0.735v
Actual max voltage of cache under load: 1.056v.
All other voltages readable by HWInfo64 same as running in Offset Mode +0.27v.

Passed 5 consecutive runs of Realbench Benchmark (best test I could think of to cause cache voltage to ramp up and down a lot).





All readable HWInfo64 voltages running in Offset 0.27v mode:




All readable HWInfo64 voltages after running 5 consecutive Realbench benchmarks in Adaptive mode (the only differences are the cache voltage minimum and maximum values):





So, for at least this brief moment, my full-of-misconceptions idiot of a coder self is the only human being on the planet successfully running stable and by all appearances completely safe decent (38x) overclock that idles at 0.735v cache volts on an Asus motherboard.

Sometimes even people who don't know the intricate inner workings of vid tables or PCU's can do things that the experts condescendingly insist isn't possible . Imagine that.

Cause here's what I find amusing. Never once did it occur to any of the experts that INTEL MAY NOT HAVE BEEN LYING WHEN THEY SAID THEY FIXED IT IN THE NEW MICROCODE. However the BIOS handles the value that is input into the Additional Turbo field, we know that it *wasn't working on microcode 2d*. But Intel says it's working now, and as demonstrated above, THEY'VE GOT A PRETTY SIGNIFICANT LEG TO STAND ON. However the BIOS handles that value before passing it off to the PCU, *the need to handle that value may have changed due to Intel's fix*. There's no possible way to know unless you *look*. But the experts can't be bothered to look. Just because Intel changed the microcode in the handling of this specific issue couldn't possibly result in requiring a change to the way the BIOS was implemented *when the functionality was broken*. In fact, it's not just plausible but a SURE THING that the way the BIOS programmers implemented the passing off of that Additional Turbo value to the PCU/vid table/whatever (which almost certainly involved some heavy massaging of the value in the then-futile attempt to get Intel's broken functionality to work, back when they could be bothered to try, and which was very plausibly left in that massaged state once it was decided further efforts weren't worthwhile) nonetheless remained perfectly in sync with the way Intel implemented their fix in a future microcode.

Which they hadn't written yet. Because magic. And time travel. Maybe they figured out how to use that neat gadget in the 3DMark Timespy demo.

I know that the actual longevity gains of running at 0.27v lower at idle isn't earth shattering. Yeah, I know that current at idle is low enough that it doesn't make a huge difference. That's not the issue. The issue is unwarranted arrogance, and condescension, and a refusal to even acknowledge the possibility that a 25 year programmer could figure out how a piece of software works simply by observing its behavior.

A good 50% of the debugging I've done in my life has been in the absence of being able to read the actual underlying code. Here's a mod I did for Planescape Torment where I fixed literally over a 1000 bugs without ever being able to see a single line of code in the engine:

http://readme.spellholdstudios.net/PSTFixpack_Readme.html


So: I repeat: Never condescend to a Cuban, especially when making stupid assumptions like "Intel says they fixed it in the new microcode, but we'll just assume they're lying without a single test, and no matter what changes they made, our code that interfaces with theirs, which we wrote when their functionality was broken, and no working implementation was possible, is still perfect. How dare you suggest any other possibility. Thread locked.". It'll never end well for you.

I'll go off and enjoy being the only person in the world idling at 0.735v cache with a 38x multiplier and stable under highly variable load, despite being assured by the experts that it's completely broken. It warms the cackles my cold misconception-filled ignorant know-nothing heart..

EDIT: An even more specific moral: Never condescend to a Cuban when he was going WAY out of his way to be as utterly polite and respectful as humanly possible. I don't think you even have to be Cuban to find that insufferable
.
Great job and interesting... the base turbo multiplier is 3.7. Have you tried anything above 3.8? (which is basically the non OC-socket limit for cache at stock voltage?)
x99
(22 items)
 
Z370
(8 items)
 
x299
(18 items)
 
CPUCPUMotherboardGraphics
i7 5960X i7 6950X Asus Rampage V Extreme 10 2 GTX Titan X Pascal 
RAMHard DriveHard DriveHard Drive
GSkill 3200c14 TZs 8x8GB @ 3400c13 Intel 750 NVMe 400GB 2x Plextor SSD 256 Raid 0 (Win 7) Samsung NVMe 950 Pro M.2 
Optical DriveCoolingCoolingCooling
Plextor 810 2x XSPC RX360 Koolance 380i D5 
CoolingOSOSOS
Aquaero 6 Windows 10 x64  Windows 7 Pro Linux Mint 
MonitorKeyboardPowerCase
Seiki 50" 4K monitor (720P-2160i) 240-30Hz Das Keyboard Model S Pro Corsair AX1200 Case Labs SM8 
MouseAudio
Steelseries Rival Ultimate Ears TF10 
CPUMotherboardGraphicsRAM
8700K ASUS Maximus X Apex GTX 1080 2x8 GB G.Skill 4400c19 
Hard DriveCoolingOSCase
Samsung 960 Pro 360Rad + Chiller Win 10 HWBOT OBT 
CPUCPUMotherboardGraphics
7740X 7980XE ASUS Rampage Vi Apex 2x Nvidia Titan Xp SLi 
RAMHard DriveHard DriveHard Drive
G.Skill 3600c15 2x8GB kits Samsung 960 Pro, NVMe WD Raptor 1T Plextor SSDs Raid 0 
Optical DriveCoolingOSOS
Plextor DVD/BR R/W (very) Custom Water Windows 10 Pro Windows 7 Pro 
MonitorKeyboardPowerCase
ASUS 144Hz Ducky Corsair 1500i Microcool Benchetto 101 
MouseAudio
Steelseries Rival Ultimate ears TF10s (IEMs) 
  hide details  
Reply
x99
(22 items)
 
Z370
(8 items)
 
x299
(18 items)
 
CPUCPUMotherboardGraphics
i7 5960X i7 6950X Asus Rampage V Extreme 10 2 GTX Titan X Pascal 
RAMHard DriveHard DriveHard Drive
GSkill 3200c14 TZs 8x8GB @ 3400c13 Intel 750 NVMe 400GB 2x Plextor SSD 256 Raid 0 (Win 7) Samsung NVMe 950 Pro M.2 
Optical DriveCoolingCoolingCooling
Plextor 810 2x XSPC RX360 Koolance 380i D5 
CoolingOSOSOS
Aquaero 6 Windows 10 x64  Windows 7 Pro Linux Mint 
MonitorKeyboardPowerCase
Seiki 50" 4K monitor (720P-2160i) 240-30Hz Das Keyboard Model S Pro Corsair AX1200 Case Labs SM8 
MouseAudio
Steelseries Rival Ultimate Ears TF10 
CPUMotherboardGraphicsRAM
8700K ASUS Maximus X Apex GTX 1080 2x8 GB G.Skill 4400c19 
Hard DriveCoolingOSCase
Samsung 960 Pro 360Rad + Chiller Win 10 HWBOT OBT 
CPUCPUMotherboardGraphics
7740X 7980XE ASUS Rampage Vi Apex 2x Nvidia Titan Xp SLi 
RAMHard DriveHard DriveHard Drive
G.Skill 3600c15 2x8GB kits Samsung 960 Pro, NVMe WD Raptor 1T Plextor SSDs Raid 0 
Optical DriveCoolingOSOS
Plextor DVD/BR R/W (very) Custom Water Windows 10 Pro Windows 7 Pro 
MonitorKeyboardPowerCase
ASUS 144Hz Ducky Corsair 1500i Microcool Benchetto 101 
MouseAudio
Steelseries Rival Ultimate ears TF10s (IEMs) 
  hide details  
Reply

Gear mentioned in this thread:

post #9782 of 10638
Quote:
Originally Posted by Jpmboy View Post

Great job and interesting... the base turbo multiplier is 3.7.

Thank you! And I may be misunderstanding... do you mean at stock settings, cache clocks up to 3.7 under load? I don't think so on a 5930k. Pretty sure I only boost up to 3000 at stock settings. I can easily check though.
Quote:
Have you tried anything above 3.8? (which is basically the non OC-socket limit for cache at stock voltage?)

The best I could probably get out of it in the current state of code is 3.9. At the higher settings of Adaptive Turbo, "divide by 4" seems to become more like "divide by 16". I tried booting with that setting set to the maximum allowable by the BIOS, 1.92v. Max actual voltage got as high as 1.092v. I doubt I could run higher than 3.9 at that stable under load.

The last thing Raja said before he decided I couldn't have anything useful or interesting to say and locked the thread over at the ROG forums was that a lookup table to get that setting more in line with the actual results wasn't possible because there's a variance between CPU's in terms of results of access to the VID table. Had I had a chance to respond, I would have said that:

1) Given the current indignation at even thinking of revisiting this topic, it can be safely presumed that all tests that resulted in that variance between CPUs were on a previous microcode that everyone acknowledges was broken, so those results can no longer be presumed to still apply, and

2) Even if that variance still existed, okay, sure, I acknowledge you might not be able to get what you enter into the Additional Turbo field to exactly match up with the resulting actual max voltage. Please cite for me any other voltage you can enter that will line up exactly with what you get in the real world. I have my adaptive core add'l turbo to set to 1.27v, and I get 1.296v. We're not exactly accustomed to expecting real voltage to match what we set in the BIOS. Could the variance they're talking about between CPU's be accounted for enough to get the setting within a couple of bins of the actual voltage? Maaaaybe, within 4 bins? Could it at least be fudged enough that you *can* enter a figure that permits an actual max voltage above 1.1v? Absolutely. And even that's even presuming the bug is still on Intel's side rather than their own, the absolute assumption of which I feel I've demonstrated is no longer beyond question.

Especially cause, if that "1.92v" setting ever actually managed to reach the PCU to be acted upon in any way, I doubt I'd have a computer right now.

Oh, and also, isn't 3.8 pretty much the max clock at *any* voltage on non-OC-socket/Broadwell-E?
Edited by Qwinn - 7/30/16 at 11:05am
    
CPUMotherboardGraphicsGraphics
Intel Processor 5930k RAMPAGE V EXTREME NVIDIA GeForce GTX 980 Ti NVIDIA GeForce GTX 980 Ti 
RAMHard DriveCoolingOS
G.Skill 32gb DDR4-2666Mhz 15L Intel 750 PCIe SSD 1.2TB Thermaltake Water 3.0 Ultimate Windows 10 64-Bit Professional 
MonitorKeyboardPowerCase
ROG Swift Saitek Eclipse II EVGA SuperNOVA 1200 P2 ThermalTake v71 
Mouse
Razer A5090 Master of Destiny 
  hide details  
Reply
    
CPUMotherboardGraphicsGraphics
Intel Processor 5930k RAMPAGE V EXTREME NVIDIA GeForce GTX 980 Ti NVIDIA GeForce GTX 980 Ti 
RAMHard DriveCoolingOS
G.Skill 32gb DDR4-2666Mhz 15L Intel 750 PCIe SSD 1.2TB Thermaltake Water 3.0 Ultimate Windows 10 64-Bit Professional 
MonitorKeyboardPowerCase
ROG Swift Saitek Eclipse II EVGA SuperNOVA 1200 P2 ThermalTake v71 
Mouse
Razer A5090 Master of Destiny 
  hide details  
Reply
post #9783 of 10638
Quote:
Originally Posted by Qwinn View Post

Especially cause, if that "1.92v" setting ever actually managed to reach the PCU to be acted upon in any way, I doubt I'd have a computer right now

Well, since you seem to have such extensive programming knowledge, you probably know this already - but Intel XTU writes directly to the MSR. You could try setting cache at default and running 1.92v through this? Just a thought...

That said, from what you're posting on the latest microcode, adaptive is just as broken on the latest microcode as it has always been (I''ve tested version 37). Intel's XTU does the same thing you're reporting via UEFI with the latest microcode. Intel make the software, they make the microcode, they make the chipset, they make the CPU. If they don't have it working properly, it says a lot.
post #9784 of 10638
Quote:
Well, since you seem to have such extensive programming knowledge, you probably know this already - but Intel XTU writes directly to the MSR. You could try setting cache at default and running 1.92v through this? Just a thought...

Since my position is that the last remaining bug in this is in the ASUS Bios, and XTU would bypass that, I'd have to be pretty idiotic to try that. You, on the other hand, believe that Intel is responsible, so if you're right, XTU passing the value to the MSR should exhibit the same *lack* of destructive behavior that I'm experiencing by passing it through the BIOS.

Passing 1.92v to the MSR through the BIOS is by all appearances harmless. If you're right, and the BIOS works the same as XTU, then passing it through XTU shouldn't be any more destructive than what I just tried.

I just risked my chip to prove my point. Passing it through XTU without issue would prove yours. I risked my chip and proved my confidence in my convictions, successfully. You sure enough about your position to demonstrate yours?
Edited by Qwinn - 7/30/16 at 11:47am
    
CPUMotherboardGraphicsGraphics
Intel Processor 5930k RAMPAGE V EXTREME NVIDIA GeForce GTX 980 Ti NVIDIA GeForce GTX 980 Ti 
RAMHard DriveCoolingOS
G.Skill 32gb DDR4-2666Mhz 15L Intel 750 PCIe SSD 1.2TB Thermaltake Water 3.0 Ultimate Windows 10 64-Bit Professional 
MonitorKeyboardPowerCase
ROG Swift Saitek Eclipse II EVGA SuperNOVA 1200 P2 ThermalTake v71 
Mouse
Razer A5090 Master of Destiny 
  hide details  
Reply
    
CPUMotherboardGraphicsGraphics
Intel Processor 5930k RAMPAGE V EXTREME NVIDIA GeForce GTX 980 Ti NVIDIA GeForce GTX 980 Ti 
RAMHard DriveCoolingOS
G.Skill 32gb DDR4-2666Mhz 15L Intel 750 PCIe SSD 1.2TB Thermaltake Water 3.0 Ultimate Windows 10 64-Bit Professional 
MonitorKeyboardPowerCase
ROG Swift Saitek Eclipse II EVGA SuperNOVA 1200 P2 ThermalTake v71 
Mouse
Razer A5090 Master of Destiny 
  hide details  
Reply
post #9785 of 10638
Quote:
Originally Posted by Qwinn View Post

Shouldn't someone have mentioned that entering a higher value in a single field, the higher value of which is never actually applied anywhere, gets the desired results?

Hello

No they shouldn't. There's nobody outside of Intel that knows the repercussions of setting this type of voltage value. At any given time it may be a possibility that the system would indeed apply this insanely high set voltage and would result in irreversible damage to the processor. Only a fool would advocate such a thing be done. And the only users that would feel this type of advice is beneficial probably do not need to be changing settings anyway. This being the case there is no reason to even bring this to the public view.
post #9786 of 10638
Quote:
Originally Posted by Qwinn View Post

Thank you! And I may be misunderstanding... do you mean at stock settings, cache clocks up to 3.7 under load? I don't think so on a 5930k. Pretty sure I only boost up to 3000 at stock settings. I can easily check though.
The best I could probably get out of it in the current state of code is 3.9. At the higher settings of Adaptive Turbo, "divide by 4" seems to become more like "divide by 16". I tried booting with that setting set to the maximum allowable by the BIOS, 1.92v. Max actual voltage got as high as 1.092v. I doubt I could run higher than 3.9 at that stable under load.

The last thing Raja said before he decided I couldn't have anything useful or interesting to say and locked the thread over at the ROG forums was that a lookup table to get that setting more in line with the actual results wasn't possible because there's a variance between CPU's in terms of results of access to the VID table. Had I had a chance to respond, I would have said that:

1) Given the current indignation at even thinking of revisiting this topic, it can be safely presumed that all tests that resulted in that variance between CPUs were on a previous microcode that everyone acknowledges was broken, so those results can no longer be presumed to still apply, and

2) Even if that variance still existed, okay, sure, I acknowledge you might not be able to get what you enter into the Additional Turbo field to exactly match up with the resulting actual max voltage. Please cite for me any other voltage you can enter that will line up exactly with what you get in the real world. I have my adaptive core add'l turbo to set to 1.27v, and I get 1.296v. We're not exactly accustomed to expecting real voltage to match what we set in the BIOS. Could the variance they're talking about between CPU's be accounted for enough to get the setting within a couple of bins of the actual voltage? Maaaaybe, within 4 bins? Could it at least be fudged enough that you *can* enter a figure that permits an actual max voltage above 1.1v? Absolutely. And even that's even presuming the bug is still on Intel's side rather than their own, the absolute assumption of which I feel I've demonstrated is no longer beyond question.

Especially cause, if that "1.92v" setting ever actually managed to reach the PCU to be acted upon in any way, I doubt I'd have a computer right now.

Oh, and also, isn't 3.8 pretty much the max clock at *any* voltage on non-OC-socket/Broadwell-E?

37 is the stock max turbo multiplier on the core. When you install the chip and/or hit clrcmos, the stock operating voltage is adaptive (dynamic voltage) for core and cache, and cache stock turbo max works in this setting, AFAIK. What is the max freq you see for cache at full stock settings?
Bottom line for me is, Adaptive cache has not worked well for the cache freqs I run. Unfortunately my 5960X/R5E is taking a break until a new case arrives...
x99
(22 items)
 
Z370
(8 items)
 
x299
(18 items)
 
CPUCPUMotherboardGraphics
i7 5960X i7 6950X Asus Rampage V Extreme 10 2 GTX Titan X Pascal 
RAMHard DriveHard DriveHard Drive
GSkill 3200c14 TZs 8x8GB @ 3400c13 Intel 750 NVMe 400GB 2x Plextor SSD 256 Raid 0 (Win 7) Samsung NVMe 950 Pro M.2 
Optical DriveCoolingCoolingCooling
Plextor 810 2x XSPC RX360 Koolance 380i D5 
CoolingOSOSOS
Aquaero 6 Windows 10 x64  Windows 7 Pro Linux Mint 
MonitorKeyboardPowerCase
Seiki 50" 4K monitor (720P-2160i) 240-30Hz Das Keyboard Model S Pro Corsair AX1200 Case Labs SM8 
MouseAudio
Steelseries Rival Ultimate Ears TF10 
CPUMotherboardGraphicsRAM
8700K ASUS Maximus X Apex GTX 1080 2x8 GB G.Skill 4400c19 
Hard DriveCoolingOSCase
Samsung 960 Pro 360Rad + Chiller Win 10 HWBOT OBT 
CPUCPUMotherboardGraphics
7740X 7980XE ASUS Rampage Vi Apex 2x Nvidia Titan Xp SLi 
RAMHard DriveHard DriveHard Drive
G.Skill 3600c15 2x8GB kits Samsung 960 Pro, NVMe WD Raptor 1T Plextor SSDs Raid 0 
Optical DriveCoolingOSOS
Plextor DVD/BR R/W (very) Custom Water Windows 10 Pro Windows 7 Pro 
MonitorKeyboardPowerCase
ASUS 144Hz Ducky Corsair 1500i Microcool Benchetto 101 
MouseAudio
Steelseries Rival Ultimate ears TF10s (IEMs) 
  hide details  
Reply
x99
(22 items)
 
Z370
(8 items)
 
x299
(18 items)
 
CPUCPUMotherboardGraphics
i7 5960X i7 6950X Asus Rampage V Extreme 10 2 GTX Titan X Pascal 
RAMHard DriveHard DriveHard Drive
GSkill 3200c14 TZs 8x8GB @ 3400c13 Intel 750 NVMe 400GB 2x Plextor SSD 256 Raid 0 (Win 7) Samsung NVMe 950 Pro M.2 
Optical DriveCoolingCoolingCooling
Plextor 810 2x XSPC RX360 Koolance 380i D5 
CoolingOSOSOS
Aquaero 6 Windows 10 x64  Windows 7 Pro Linux Mint 
MonitorKeyboardPowerCase
Seiki 50" 4K monitor (720P-2160i) 240-30Hz Das Keyboard Model S Pro Corsair AX1200 Case Labs SM8 
MouseAudio
Steelseries Rival Ultimate Ears TF10 
CPUMotherboardGraphicsRAM
8700K ASUS Maximus X Apex GTX 1080 2x8 GB G.Skill 4400c19 
Hard DriveCoolingOSCase
Samsung 960 Pro 360Rad + Chiller Win 10 HWBOT OBT 
CPUCPUMotherboardGraphics
7740X 7980XE ASUS Rampage Vi Apex 2x Nvidia Titan Xp SLi 
RAMHard DriveHard DriveHard Drive
G.Skill 3600c15 2x8GB kits Samsung 960 Pro, NVMe WD Raptor 1T Plextor SSDs Raid 0 
Optical DriveCoolingOSOS
Plextor DVD/BR R/W (very) Custom Water Windows 10 Pro Windows 7 Pro 
MonitorKeyboardPowerCase
ASUS 144Hz Ducky Corsair 1500i Microcool Benchetto 101 
MouseAudio
Steelseries Rival Ultimate ears TF10s (IEMs) 
  hide details  
Reply
post #9787 of 10638
Actually, let me modify this:
Quote:
Since my position is that the last remaining bug in this is in the ASUS Bios,

I'll retract this. I'm only stating that it's entirely possible. There is nothing in the experienced behavior that precludes the possibility that the problem has been fixed and the remaining issue exists in the ASUS Bios. Could it ALSO be on the Intel side? Sure. Insufficient data to narrow it down further. All I'm asserting is that, unless you tested Intel's purported fix on the newest microcode, and inspected the entered value to see if it is massaged in any way before it's passed on to Intel, you also have insufficient data to determine it. And everything that's been said suggests, very strongly, that no one's been inclined to try to test it.

So no, even though you've previously been a complete ass to me on this forum, silent scone, I don't want you to fry your chip, and I don't suggest you actually try the XTU experiment.

You guys keep saying "Intel has to fix it". Intel says they've fixed it. If you have tested the most current iteration of their fix, fine. But no one's come out and said that, and you've all said In one loud voice that it's not necessary, you already know they're wrong, and no changes they made to implement their fix could possibly require any change on the procedure on your side, which was written when their code didn't work, that passes the entered value to them.

Look, you know what my 20 years of experience in IT have taught me above all? That the following situation happens:

1) Diligent techies are tasked with creating a data entry app (such as a UEFI Bios) and interfacing the user-entered values with another vendor's interface specifications.

2) Following the vendor's guidelines isn't working. Diligent techies try massaging the entered data to observe and test the results, to see if they can determine what the problem is (in fact, this has been pretty much confirmed as having happened in this current scenario).

3) Vendor acknowledges that the feature isn't currently working.

4) Boss calls down: stop wasting your time on it. Move on to the next project.

5) Data entry side, where the massaging and testing was taking place, is abandoned at the exact point that call came down. Attempts to tweak to make the vendor's function work, failed attempts to build a lookup table to get the desired results, remain in place.

If you've worked in IT, you know that the above doesn't just happen, it happens multiple times a day.

To preclude the possibility out of hand isn't reasonable.

And this conversation has already consumed about ten times the amount of time that someone saying "You know, it's not beyond the realm of possibility, and we know pretty much exactly where we'd need to look. Let me look in the BIOS code for 15 minutes and make sure." would have spent on the issue.
Edited by Qwinn - 7/30/16 at 12:18pm
    
CPUMotherboardGraphicsGraphics
Intel Processor 5930k RAMPAGE V EXTREME NVIDIA GeForce GTX 980 Ti NVIDIA GeForce GTX 980 Ti 
RAMHard DriveCoolingOS
G.Skill 32gb DDR4-2666Mhz 15L Intel 750 PCIe SSD 1.2TB Thermaltake Water 3.0 Ultimate Windows 10 64-Bit Professional 
MonitorKeyboardPowerCase
ROG Swift Saitek Eclipse II EVGA SuperNOVA 1200 P2 ThermalTake v71 
Mouse
Razer A5090 Master of Destiny 
  hide details  
Reply
    
CPUMotherboardGraphicsGraphics
Intel Processor 5930k RAMPAGE V EXTREME NVIDIA GeForce GTX 980 Ti NVIDIA GeForce GTX 980 Ti 
RAMHard DriveCoolingOS
G.Skill 32gb DDR4-2666Mhz 15L Intel 750 PCIe SSD 1.2TB Thermaltake Water 3.0 Ultimate Windows 10 64-Bit Professional 
MonitorKeyboardPowerCase
ROG Swift Saitek Eclipse II EVGA SuperNOVA 1200 P2 ThermalTake v71 
Mouse
Razer A5090 Master of Destiny 
  hide details  
Reply
post #9788 of 10638
Quote:
Originally Posted by Qwinn View Post

The full extent of it's current "brokenness" is 100% explainable by the value being entered in the BIOS is being stored or passed somewhere incorrectly, before anything Intel even gets to look at it. That single hypothetical error is sufficient to explain the entire witnessed behavior. It's behaving exactly as it should be... except that what you enter in that field and what you actually get as the desired maximum voltage don't match.

That's it. That is sufficient to entirely explain the current behavior - which no one else has tested on microcode 38 to my knowledge - for even a second.

Now, having worked in the world of IT for a long time, I may have witnessed the following scenario once, maybe twice:

1) Diligent techies in charge of a data entry application (like a BIOS setup) are tasked with accepting the user's input data and transferring it to another vendor's specifications for interface with their software.

2) The vendor's interface isn't responding as it should. Diligent techies try various ways of massaging and adjusting the entered values that they're exporting to the vendor's interface to get the vendor's feature to work right.

3) The call comes down from the boss: The vendor has said this isn't working properly. Stop wasting time on it. Move on to the next project.

4) The code in question is abandoned at the exact point where that call came down, and any massaging they were doing trying to get it to work right is left in place.

If you've worked in any large IT department, you know that the above doesn't just happen often, it happens multiple times a day.

And it would account 100% for the current observed behavior. And if, as you say, it's just as broken as it ever was.... how come I can run at a decent overclock with 0.735v idle? That's fully functional in my opinion. Shouldn't someone have mentioned that entering a higher value in a single field, the higher value of which is never actually applied anywhere, gets the desired results? Cause if that's all it takes for you guys to dismiss something as "hopelessly broken", well, I wish my previous bosses would have accepted that kind of evaluation. Would've made life pretty easy.



Look here:







1) Adaptive Vcore works fine in XTU. You can set Adaptive in UEFI, or leave it on Auto, XTU will override it and apply the selected value and force static or adaptive according to what you select.

2) When cache voltage is left in auto state in UEFI, XTU application of adaptive voltage is borked in a similar manner to yours. It does exactly what it was doing before. If adaptive is set in UEFI then XTU simply applies a manual voltage when an adaptive voltage is set.

3) This proves it has nothing to do with ASUS, and you were very bull-headed in stating that. Chances are you realized you went off half cocked and are now backtracking hence all these on-the-fly edits and retractions.
Quote:
Originally Posted by Qwinn View Post



3) The call comes down from the boss: The vendor has said this isn't working properly. Stop wasting time on it. Move on to the next project.

I think you should probably make use of this snippet, as you're wasting yours and others time with this.
Edited by Silent Scone - 7/30/16 at 12:36pm
post #9789 of 10638
Wow, I thought that post you just quoted was nixed entirely by an accidental close of the browser. I never actually noticed that it posted, and not sure when I had an opportunity to hit the submit button in it. I wound up rewriting the whole thing from memory from scratch (my post 9787). How weird.

Anyway, my acknowledgment that it could still be on Intel's side came before anyone posted anything else that would lead me to doubt my current convictions. I didn't come to any new realizations, I just realized I phrased it badly. When you're saying something is possible, and three people insist repeatedly that it's *not* possible, it's rhetorically very easy to slip into "I'm sure what I think is possible happened". And upon 3 minutes consideration I moderated it to the current form of, I reject your insistence that it HAS to be on Intel's side even after they've purportedly fixed it and it doesn't bear any investigation that could've been accomplished in one tenth the time we've spent arguing about it. This is me trying to be responsible and not allow the heat of repeated condescension burning with the heat of a fiery thousand suns to make me immoderate in my declarations, which you've seen fit to denigrate.

Now, looking at your pictures, the top left picture in XTU shows this:

Cache Voltage Mode: Adaptive
Cache Voltage: 1.255v
Cache offset: 0.

It is impossible to get these readings through setting up adaptive in the BIOS. Even a setting of 1.92v for additional turbo in the BIOS cannot yield a real world maximum cache voltage over 1.1v. So, XTU is achieving something very different than the BIOS. This is entirely consistent with my position. Given that screenshot, I am extremely confident that if you entered 1.92v *there*, the chip would burn up. Again - consistent with my position, not yours.

"When cache voltage is left in auto state in UEFI, XTU application of adaptive voltage is borked in a similar manner to yours."

In that top left picture, what is the UEFI set to?

If actual cache voltage can go over 1.1v at any settings, it is in no way borked in a similar matter to mine.
Edited by Qwinn - 7/30/16 at 12:41pm
    
CPUMotherboardGraphicsGraphics
Intel Processor 5930k RAMPAGE V EXTREME NVIDIA GeForce GTX 980 Ti NVIDIA GeForce GTX 980 Ti 
RAMHard DriveCoolingOS
G.Skill 32gb DDR4-2666Mhz 15L Intel 750 PCIe SSD 1.2TB Thermaltake Water 3.0 Ultimate Windows 10 64-Bit Professional 
MonitorKeyboardPowerCase
ROG Swift Saitek Eclipse II EVGA SuperNOVA 1200 P2 ThermalTake v71 
Mouse
Razer A5090 Master of Destiny 
  hide details  
Reply
    
CPUMotherboardGraphicsGraphics
Intel Processor 5930k RAMPAGE V EXTREME NVIDIA GeForce GTX 980 Ti NVIDIA GeForce GTX 980 Ti 
RAMHard DriveCoolingOS
G.Skill 32gb DDR4-2666Mhz 15L Intel 750 PCIe SSD 1.2TB Thermaltake Water 3.0 Ultimate Windows 10 64-Bit Professional 
MonitorKeyboardPowerCase
ROG Swift Saitek Eclipse II EVGA SuperNOVA 1200 P2 ThermalTake v71 
Mouse
Razer A5090 Master of Destiny 
  hide details  
Reply
post #9790 of 10638
Quote:
Originally Posted by Qwinn View Post

Wow, I thought that post you just quoted was nixed entirely by an accidental close of the browser. I never actually noticed that it posted, and not sure when I had an opportunity to hit the submit button in it. I wound up rewriting the whole thing from memory from scratch (my post 9787). How weird.

Hello

Really? So you edited a post that was thought to be non-existent also? This statement and all the ongoing edits is starting to let all the pieces fall into place.

Quote:
Originally Posted by Qwinn View Post

Anyway, my acknowledgment edits that it could still be on Intel's side came before after anyone posted anything else that would lead me to doubt my current convictions.

Hello

Fixed this for you. smile.gif
Edited by Praz - 7/30/16 at 12:49pm
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Intel Motherboards

Gear mentioned in this thread:

Overclock.net › Forums › Intel › Intel Motherboards › Asus Rampage V Extreme Owners thread