Forum Discussion
@Ariuc Looks like you've done your homework.
I just want to make sure that other users who are not using higher tier hardware like you are, and who are not well versed on what loadline calibration actually does, don't just rush into pushing the 0 mOhms Loadline calibration (LLC level 8, Ultra Extreme, etc) into their CPU's and think "wow this is the best thing ever, why don't they all come like this?"
Raja, one of the engineers at Asus (when their forums still allowed private messages) taught me what the AC and DC loadlines (not to be confused with Loadline calibration, or LLC (also known as VRM loadline or just "Vcore Loadline Calibrationi)) did on auto/offset voltages, and he also explained the dangers of removing too much vdroop. Asus and other ODM's allowed such high levels of vdroop removal because "people kept begging them for it", so they gave the community what they wanted, even though they knew most end users had no idea how loadlines actually work (who here on this thread understood that Loadline Calibration is in mOhms (the same resistance value as the AC and DC loadlines?) and what the actual "levels" really meant? See?
For Gigabyte Z390 boards using 8 core processors, here are the resistance values for each level of Loadline Calibration:
Standard / Auto / Normal: 1.6 mOhms
Low: 1.3 mOhms
Medium: 1.0 mOhms
High: 0.8 mOhms
Turbo: 0.4 mOhms
Extreme: 0.2 mOhms
Ultra Extreme: 0.01 mOhms.
Vdroop = Amps * Resistance. Gigabyte boards have amps monitoring via the IR 35201 voltage controller (or the Intersil controllers) in HWINFO64 (Asus does not, sadly, even the eVGA Z390 dark doesn't seem to), so if you see your amps in IR 35201, multiply that by your LLC resistance, and then subtract that from your bios set voltage in millivolts. Example:
1.30v=1300mv, turbo LLC=0.4 mOhms. 100 amps load: 0.4 * 100 = 40. 40mv drop. 1300-40=1260mv=1.260v. Your VR VOUT should read 1.260v. That's your load voltage with 100 amps. Ignore the ITE 8688E sensor (Super I/O chip) and 8792E sensor (more accurate but won't show accurate vdroop).
It's also not Asus or Gigabyte's or other ODM's fault that transient spikes and drops happen. Asus doesn't make the VRM's. The companies like DrMos, Osemi(?), International Rectifier, Renesas (Intersil), etc, make them. You have the voltage controller itself and then the actual power mosfets. But these VRM's are not spec'd to run with a 0 mOhm loadline at all. Even the official datasheets show the loadline information and none have a 0 mOhm loadline as part of the specifications. So that's something worth noting.
I assume since you're a gamer, you probably have discord. You can add me if you wish with the tag at the of my exact same username: #6092
One way you can test for transient spikes is to use the hardest stress test possible, in this case, Prime95 with FMA3 or AVX (I like testing 15K in place fixed AVX or 21K or 22K fixed, or even FMA3), and find the VMIN first, which takes a lot of work (basically, to save time, the absolute minimum voltage you can set in bios, *WITH* LLC5 or LLC6 vdroop), to not crash a prime thread at load in 15 minutes.
https://mersenneforum.org/showthread.php?t=24094
This version of prime95 allows you to enable or disable AVX and FMA3 right in the stress test without editing TXT files (recommend anyone who enjoys torturing their CPU's grab it), but yeah, for exammple, do a prime test with FMA3 enabled, 15K fixed in place FFT (custom, min and max range 15K), with let's say, 1.30v and LLC6 and start there. If you INSTANTLY reach 100C and BSOD, disable AVX2 (FMA3) and just do AVX instead. If you pass 15 minutes, reduce voltage 10mv, reboot and try again until it crashes. Then record the **LOAD** VOLTAGE (not bios voltage!) that it took to pass. Your motherboard has a good bios which reads CPU voltage properly at load, as does Gigabyte Z390 boards (VR VOUT sensor in HWinfo, for anyone reading this!) and some MSI boards have VR VOUT. For non Asus WS / Maximus Z390 boards, if you have VR VOUT access in HWInfo64, use that for load voltage, guys.
Anyway record this voltage. So in your case if you set 1.30v in bios, LLC6, it might be 1.225v at full load on your Asus WS. If that's your stable prime 15K AVX FFT (29.8 builid 3) test, now switch to Ultra Extreme.
And set your bios voltage to 1.230v. LLC8 or Gigabyte Ultra Extreme. Yes, 1.230v. Because that was your load voltage remember? (usually controllers go in 5mv steps so im giving a cushion for accuracy).
Then run LLC8 + 1.230v. Do prime95 AVX 15K in place fixed FFT (custom).--min and max range 15K.
Your system won't last long. (If 1.230v were your actual load VMIN). You will either BSOD or a thread will crash in the first 5 minutes. That's because of transient drops. Even though it looks like Prime95 is putting a constant full even load on your CPU, the load actually changes very often, too fast to register, thus transient drop=crash.
Feel free to message me on discord (remember, my username with #6092 at the end, Falkentyne) if you want to mess with this XD
And now that I derailed this thread talking about VRM's....back to your standard programming!
I received yet another crash with no error, and with error´including whea internal parity error. So i went back to LLC 6 from 8 at 4.9 ghz, 1.3 volt. Started from 1.2v and worked upwards. My load lines did not cause any heat issues or instability. Maybe a developer could explain if its a coding issue or cpu i would be glad. If this continues i might RMA my cpu and motherboard. Spectre and meltdown mitigation has been disabled, could this be a factor that brings up the error in event viewer, and coreparking disabled?
- 7 years ago
@Ariuc It's some sort of Intel microcode bug. RMA won't do anything.
I did some tests last night. I actually *disabled* loadline calibration completely (leaving it on the standard value of 1.6 mOhms of vdroop) and used Auto vcore, letting the Internal VR AC loadline do the work (which Intel specifies as 1.6 mOhms maximum also). This worked out fine (5 ghz) but idle voltages were much too high (1.40v) and low to medium load voltages were also too high, but Apex had no problems. 15k small FFT AVX prime95 ran fine here at 1.240v (VCC_Sense voltage) and 184 amps, and 96C max temps after 6 minutes, so this was ok but again not what I suggest. The reasaon I disabled Loadline Calibration and let the AC Loadlines do the work, is this improves transient response massively and stops excessive unmeasured voltage dips and spikes (Important for something like Prime95 on very high amps load).
I then enabled SVID offset, which kept idle voltages the same, and raised small FFT avx disabled prime95 by 30mv, but this raised AVX enabled prime95 small FFT by *90mv!*...leading to 212 amps, and 105C temps in FIVE seconds! Ouch....uh....
So SVID offset seems to boost certain load voltages.
Ok so I kept SVID offset enabled but set AC loadline to 1.0 mOhms (I kept DC loadline at 1.60 mOhms to match the CPU Vcore loadline calibration standard preset setting of 1.6 mOhms also). This reduced idle voltages significantly--down to 1.30 to 1.32v. Tested 0.9 and 1.0 mOhms for AC loadline were both rock stable in the harshest stress test on the planet (15K small FFT AVX prime95), with VR VOUT vcc_sense voltage reported at 1.230v (0.9 mOhms) and 1.250v (1.0 mOhms), and everything on the planet ran fine.
Except Apex Legends.
0.9 mOhms of AC loadline with SVID offset enabled caused random CPU parity errors. 1.0 mOhms didn't (most likely would have eventually; just didn't play long enough) but the game crashed anyway after awhile (with that typical "execute code before its ready" hexadecimal code crash). Probably 1.05 or 1.1 mOhms would be enough here but the idle voltage is getting too much for me to like.
I did these tests to take 'transient response' issues that occur when using CPU Vcore Loadline Calibration (aka VRM loadline) out of the picture. Since 15K AVX small FFT passed at very high amps, the transients were splendid. But the problem is, at a certain load voltage that would have no problem passing prime95, Apex Legends runs into this strange timing bug.
On my own system, it seems like, at 5 ghz, this "bug" happens if the CPU on-die sense voltage drops below 1.270v.So far, going back to "manual" voltages and tweaking the usual CPU Vcore loadline calibration (instead of auto or SVID offset enabled and messing with the AC loadline value), I found the following settings so far, seem to make Apex Legends stable:
5 ghz: 1.290v, Loadline Calibration=Extreme.
5 ghz: 1.310v, Loadline Calibration=Turbo
5.1 ghz: 1.360v, Loadline Calibration=Turbo.
Hopefully @OrioStorm manages to code a fix in for this issue soon, and someone at Intel makes a microcode update that fixes this permanently (If Oriostorm can convince the right people at Intel that this is an internal processor bug).
- 7 years ago
Hello,
I recently bougth myself a new pc with a ryzen 5 3600 and a rx5700. Most of the time if I start a match, before I choose my character i get a crash with the error "Apex crashed in atidxx64". My sytem is not overclocked or anything like that and I have fhe newest Drivers and updates installed! Here is an example for the crash:
crash:
{
atidxx64: 0000000000961F24
EXCEPTION_ACCESS_VIOLATION(read): 00000286E03D0000
}
cpu: "AMD Ryzen 5 3600 6-Core Processor "
callstack:
{
KERNELBASE: 00000000000FF67A
ntdll: 00000000000A4AF2
ntdll: 000000000008C6D6
ntdll: 00000000000A11FF
ntdll: 000000000006A289
ntdll: 000000000009FE6E
atidxx64: 0000000000961F24
atidxx64: 000000000009194F
atidxx64: 0000000000091545
atidxx64: 0000000000091CDF
atidxx64: 000000000002A4C0
atidxx64: 00000000000298ED
atidxx64: 000000000000A4E1
atidxx64: 00000000007A054C
atidxx64: 00000000007CFCBB
atidxx64: 000000000001BFA0
atiuxp64: 000000000000D37D
d3d11: 0000000000025BC5
d3d11: 0000000000025FF3
d3d11: 000000000007CDE3
d3d11: 000000000001E869
d3d11: 000000000002AF09
d3d11: 000000000002AF90
d3d11: 000000000002B398
d3d11: 000000000002B950
d3d11: 0000000000031174
d3d11: 0000000000030C47
R5Apex: 00000000003E998E
R5Apex: 00000000003E9CD5
KERNEL32: 0000000000017BD4
ntdll: 000000000006CED1
}
registers:
{
rax = 72
rbx = 0
rcx = 0x000002866148DFB0
rdx = 0x7EF42050
rsp = 0x000000B90B2CE498
rbp = 0
rsi = 1024 // 0x00000400
rdi = 0x00000286E03B0050
r8 = 112
r9 = 5
r10 = 0x00000286E03C2050
r11 = 0x0000028661480000
r12 = 1024 // 0x00000400
r13 = 0x00000286E03B0050
r14 = 1024 // 0x00000400
r15 = 0
rip = 0x00007FF96BF61F24
xmm0 = [ [1.5414283e-44, 0, 1.5414283e-44, 0], [11, 0, 11, 0] ]
xmm1 = [ [-5.0440096e+17, 9.0523881e-43, 1.4012985e-45, 0], [0xDCDFFFC0, 0x00000286, 0x00000001, 0x00000000] ]
xmm2 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm3 = [ [-0.5, 0, 0, 0], [0xBF000000, 0x00000000, 0x00000000, 0x00000000] ]
xmm4 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm5 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm6 = [ [7.1746481e-43, 7.1746481e-43, 1.4012985e-44, 1.4012985e-45], [512, 512, 10, 1] ]
xmm7 = [ [1.0089349e-43, 1.4012985e-45, 0, 0], [72, 1, 0, 0] ]
xmm8 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm9 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm10 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm11 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm12 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm13 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm14 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm15 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
}
build_id: 1567806032I hope someone can help me soon, becasuse it is very annoying!
- 7 years ago
Hello, I have a game crash in Apex Legends, here the txt file Please fix it, I bought a battlepass and can't play the game! crash txt
- 7 years ago
Here we go again ☹️
No overclock. Trying the AVX - 2 quick-fix now.