Alex-Ro wrote:
So,the problem is the following,have one maximus v extreme and 3570K.Say i power on the pc,test stability with prime/lynx/games==> perfect stability with x vcore(read on a multimeter).Say i shut down the pc,go for a walk,come back,power on with the exact same settings,prime fails in 2 minutes,vcore required is x + 0.02.Now this situation repeats on and on,if i set the vcore in uefi x+0.02 it's stable all the time.
The only thing i can think is that motherboard set's the skew's different on power up as the skew setting are all on auto.So my question is the following: is it possible to implement a feature in uefi so that it reads the actual skew setting applied by the motherboard on auto?
Btw,i had couple of mobo's and ivy bridge cpu's,i encountered this problem almost every time.My temperatures are all in range so no problem in this department.
This feature would also benefit extreme overclockers too ,cause i know those damn skew setting can give you those 50 mhz or 0.2 blck needed to crack a record or something ....
Any auto settings that have been developed by us (the "skews" for example) will be coded to move with other settings or sit at base default value. In any case where Shamino requests they shift, the shift will be conditional (voltage or frequency), that means once they are "set" at a given point they are "set" and won't move unless you make changes to the related settings in UEFI. Some of these "skew" settings are too conditional for us to apply our own values as well, so we don't actually move them at all.
Bottom line with these "dialled in" overclocks where you set voltages within one notch of failure, is that things can be subject to drift in IMC training (generally higher frequency or very tight memory settings - gets more apparent the higher the CPU is clocked as well).
The IMC R/W training routines are designed to operate flawlessly at stock operating frequencies of the processor. That would be stock CPU frequency and stock DRAM frequency (DDR3-1600, with CL and WCL stipulations). The further away you move from that, the more chance there is of the applied overclock falling prey to the tolerance bands of the automated IMC training routines. A small shift in de-skewing of any lines or the centering of the DQ signals around Vref can trip up what appeared to be a "stable" overclock. That and there are two different types of training routine (long and short). The shorter routine counters temperature related drift (short ZQ cal), and is performed on warm system resets. The longer training is performed on AC power cycle and or when a related bus frequency is changed.
At higher frequency, the margin between data being valid or misread (logic high or low), is reduced, so a few ps either side can be enough for an overclock to swing between stable and non-stable in a given test or benchmark.
If you want to fiddle with our "skew" settings, then the best way to do it is to get a pen and paper and move one of them at a time, one step at a time and note the changes in stability. Some of the settings will vary from CPU to CPU as well and operating frequency (no magic bullet for all CPUs). The one that might affect Vcore somewhat is BCLK Skew and if available, "Skew" Driving Voltage (best settings will likely need to be found on a case by case basis).
You can also try toggling read and write additional swizzle and MRC fast boot to see if it has any impact on your stable config or not from POST to POST. If not, then not much you can do about it, just chock it down to non-controllable drift.