Question DDR4 Chip and 10700K Overclocking Help.

Page 3 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.

Maikurosofuto

Reputable
Oct 24, 2019
106
16
4,615
Hi, I have two questions to ask. I am trying to find out what the chip of my memory is and if these voltages are good.

I have two TF3D48G2666HC15B01, which is 2666 CL15-17-17-35 1.2V with XMP enabled, i was able to do a quick stable OC to 2933 CL15-18-18-36 1.3V. I tried rising the voltage a bit to 1.35 and tightening the timings to 15-17-17-36, but seems unstable. I can't find anywhere the type of my memory chip, with these timings, do you guys have any clue?

About my voltages, i can't find my actual SA voltage readings in my BIOS, just the VCCIO, which i set to 1.1 (stock is 1.15). Is this too much or is it a reasonable value?
NVuSHAB.png
neyKETj.png
 
Last edited:

Maikurosofuto

Reputable
Oct 24, 2019
106
16
4,615
Thanks for the heads-up, DB.

Maikurosofuto,

I've reviewed each post in this thread, so to summarize, here's where you seem to be at:

i7- 10700K
5.1Ghz All Cores
79°C
LLC4
Adaptive Vcore, Offset - 0.105V (1.326V Peak running Prime95)

P95, AIDA64, CineBench R20, RealBench

Stable using IETU Settings
Unstable with IETU Settings in BIOS

Overclocking requires that we minimize as many variables as possible, of which there are dozens. So in order to compare apples to apples, we must always be very specific. Unless you're accustomed to closely observing the relationships between Core voltage, power consumption, V/F curves and thermal behavior, using both numerical values as well as graphical patterns, most users don't realize how various utilities and their assorted tests can differ drastically in the nature of the workloads they impose on a processor, which can dramatically affect stability.

“Stress” tests vary widely and can be characterized into two categories; stability tests which are fluctuating workloads, and thermal tests which are steady workloads. Prime95 v29.8 Small FFTs (AVX disabled) is ideally suited for testing power consumption and thermal performance, because it conforms to Intel's Datasheets as a steady-state 100% workload. You can also use v26.6 Small FFTs, which is an identical workload, but without any AVX code. (As per Intel's Datasheets, TDP and Thermal Specifications are validated without AVX.)

Utilities that don't overload or underload your processor will give you valid power and thermal baselines. Here’s a comparison of utilities grouped as thermal and stability tests according to % of TDP, averaged across six processor Generations at stock settings rounded to the nearest 5%:

u9JTLsO.jpg

Although these tests range from 70% to 130% TDP workload, Windows Task Manager interprets every test as 100% CPU Utilization, which is processor resource activity, NOT actual workload. Core temperatures respond directly to Power consumption (Watts), which is driven by Core voltage and workload. Prime95 v29.8 Small FFTs (AVX disabled) provides a steady 100% workload, even when TDP is exceeded by overclocking. (The topic of TDP is another involved discussion, which for the purposes of this thread, is unnecessary and will likely confuse the issue).

As you can see from the scale, Intel Extreme Tuning Utility is a fluctuating workload that's only about 80%. Conversely, AIDA64 has 4 CPU related stress test selections (CPU, FPU, Cache, Memory) which have 15 possible combinations that yield 15 different workloads and Core temperatures. That's a lot of variables and inconsistencies, which may explain when you plug IETU settings into BIOS, why utilities with heavier workloads crash. The vast majority of users don't specify exactly which test(s) they ran, nor do they typically mention ambient room temperature (normal is 22°C), which can as well be a HUGE variable.

Concerning LLC (Load Line Calibration); the purpose is to compensate for the difference between the "set" no load Core voltage in BIOS and the actual Core voltage when under a 100% workload. For example, if a wall socket in your house is probed with a voltmeter, then a very high load such as air conditioning switches on, you'll see the voltage "sag" by a volt or two, which is normal and expected. The same applies to processors, which is know as "Vdroop". Even the highest quality PSUs and efficient motherboard VRMs are affected.

When adjusting LLC, the goal is to find a setting which allows the Core voltage in Windows during a steady-state 100% workload to match the Core voltage set in BIOS. Intel intends that there should be at least a minimal sag or "undershoot", but any surge or "overshoot" is not recommended for CPU longevity. Motherboards with tight VRM regulation may vary by as little as 16 to 24mv, which, for example, means if BIOS is set for 1.260, then 100% workload in Windows should ideally vary from ~ 1.244 to 1.236. Keep in mind that since Vcore settings are in 5mv (.005) increments, but the resulting values are in 8mv (.008) increments, you will find that certain settings will cause the values in Windows to "toggle" between voltages more than others.

When workloads spike higher due to processing dense segments of code, power consumption also spikes higher which causes Core voltage to momentarily spike lower or "sag". It's during these moments of lower Vcore when the processor is most vulnerable to BSOD crashes. Therefore, when adjusting Core voltage and LLC in BIOS, it's critical to closely observe Core voltage behavior in Windows. A better method to successfully accomplish this task with the least amount of frustration is to run a steady-state 100% workload, which refers back to Prime95 v29.8 Small FFTs with all AVX test selections disabled.

When used in conjunction with HWiNFO, if you right-click on parameters such as Vcore, Package Power and Package Temperature (typically the hottest Core), it will open a graph for each, which will allow you to expand your view beyond the blinders of numerical values and take advantage of "the big picture". You can't expect to make these critical adjustments accurately when running fluctuating workloads that look like a bad day on the stock market. After you've found the most ideal LLC setting, you can then move on to stability testing with fluctuating workloads.

Here's how different workloads look on a graph:

gaaHaa3.jpg


Shown above from left to right: Small FFTs, Blend, Linpack and IntelBurn Test.​

Note the steady-state signature of Small FFTs, which allows accurate measurements of power consumption, Core voltage and Core temperatures. A steady 100% workload is key for testing so the CPU, cooler, socket, motherboard and voltage regulator modules can thermally stabilize.

Being fully aware of your test conditions and minimizing the variables involved will help you to achieve stability. As Phaaze88 has already been pointed out, although Silicon Lottery provides examples of various Core voltages used for different overclocking combinations, they're also specific regarding their QVL and test conditions. They also state that beyond Core voltage, LLC and AVX offsets, other BIOS adjustments such as PLL, SA and I/O voltages, Uncore or Ring ratio are typically unnecessary. To experienced overclockers, this suggests that for your overclock, which is not unreasonable, higher Vcore should be all that's needed.

As Unolocogringo and Karadjgne have observed, we know that since your RAM is somewhat less than a matched set, it introduces yet another set of variables. So to rule out RAM stability issues, while testing CPU overclock stability it's standard procedure to approach CPU overclocking and RAM overclocking separately; not simultaneously. I suggest that you run your RAM at stock settings, not XMP. After you achieve a stable CPU overclock, you can later tweak RAM settings, but beware that unstable RAM is the most expedient way to corrupt your software, which my esteemed colleague, Darkbreeze, has very clearly and adamantly emphasized. As such, since BSOD crashes are an inevitable part of the overclocking process, always perform a full system backup prior to conducting any overclocking endeavors.

Although you're running the latest version of IETU, here's a link to the latest version of its successor, Intel® Performance Maximizer for 10th Generation Intel® Core™ Processors. Not to introduce further variables, but you might want to give it a try instead of IETU.

You might also want to read my Intel Temperature Guide. Section 8 covers Overclocking and Voltage. Just click on the link in my signature.

CT :sol:
Wow, thats a really nice complete info. As soon as i can i will carefully read each advice and try step by step tweaking the BIOS. I really appreciate all the attempts to help me, i will update them after following these steps.
 

Maikurosofuto

Reputable
Oct 24, 2019
106
16
4,615
So far, I have done 3 different tests using P95 v29.8 (Blend AVX, Small FFTs AVX Off and Small FFTs AVX On) for 3 different settings (XTU 5.1 GHz, IPM 5 GHz and Stock 4.7 GHz). Still testing some things, but I noticed something a little peculiar, when I saw the results between XTU and IPM I noticed that XTU obviously has a higher Vcore but it was showing me a minimally lower temperature being 83C + 1.314V, while with IPM it was 85C + 1,279V. I tested the XTU after the IPM, so the processor was even previously heated up making even less sense. Could XTU be sending less current and increasing Vcore, this being the explanation for being so stable?
7om68In.jpg
LlmmjWy.jpg

I haven't started to tweaking the BIOS yet, I'll be doing it now, I just got a little thoughtful about this occurrence that I mentioned.
 
Last edited:
You can't "increase Vcore" AND "send less current". They are, for our intents and purposes, the same thing. It takes 1 volt to push 1 amp through 1 ohm of resistance. That is Ohm's law.

So if you increase the core voltage, and raise the frequency, you are going to be pushing more current through the CPU, not less, which means more heat, not less.

Something about this whole thing has my spidey senses tingling, because I've NEVER seen XTU or any desktop or automatic utility do a better job, with lower temps, than what could be done in the BIOS. Desktop and automatic type utilities ALWAYS resort to erring to the side of caution by RAISING voltage to levels higher than we'd usually use if configuring things manually, in order to minimize any chance of instability, and that ALWAYS results in higher core temperatures without exception.

The fact that you are seeing a raised level of stability, with a higher Vcore, but a lower temperature, completely flies in the face of normalcy, unless I'm missing something and if I am I'm sure Comp or somebody else will correct me, but I don't think that I am.
 

CompuTronix

Intel Master
Moderator
Maikurosofuto,

Here's some additional thoughts:

If you don't intend to use your rig for rendering or transcoding, then don't use AVX / AVX2 in Prime95, because it's brutal 130% workload which is completely unrealistic. If you do use heavy apps that run AVX, then use an "AVX Offset" in BIOS to limit your Core temperatures. If you're concerned about recent games that use AVX, the code is much less intensive than Prime95, so your Core temperatures during games should never approach or equal Prime95 Small FFTs with all AVX test selections disabled.

Much of your concerns regarding thermal and stability inconsistencies point back to differences in various software workloads, as I explained and illustrated in my post on the previous page. Some workloads, more than others, run code which is more intensive on the processor's FPU (Floating Point Unit) which is the number-crunching component in the CPU. This requires higher voltage that consumes more power and dissipates more heat, and accounts for the differences in Vcore and Core temperatures you see in IETU and IPM.

Nonetheless, you're still not seeing the big picture. If you also focus on Package power consumption (Watts) and closely observe the graphs, not just in the two Intel utilities, but in HWiNFO as well, you'll begin to get a better idea of the dynamics, interactions and behaviors that various workloads place on the processor in terms of cause and effect. Some utilities that are less intense can causes higher peak Vcore but consume less power, while others that are more intense can consume more power but have lower peak Vcore. This is why a steady-state 100% workload such as P95 Small FFTs without AVX is such a valuable tool for establishing a baseline.

Also, it's quite possible that you might be closer than you think to achieving CPU stability. Since your previous BIOS settings initially tested stable but crashed after 15 minutes, all that may be needed is an increase in Vcore of just another 20 millivolts. Since you were at 1.326, you certainly have enough headroom. Although you mentioned that you're not comfortable above 1.35 volts, 14 nanometer processors can tolerate 1.40 quite well.

Keep in mind that for your final 100 MHz increase, a corresponding increase in Core voltage of about 50 millivolts (0.050) is needed to maintain stability. If 70 millivolts (0.070) or more is needed for the next stable 100 MHz increase, it means you're attempting to overclock your processor beyond its capability. All processors potentially reach a limit where an additional increase in Core voltage will not stabilize another 100 MHz increase in Frequency.

Here’s an example of a typical Voltage / Frequency Curve:

69cEJPc.jpg
I suggest that you temporarily disregard working with fluctuating workloads and concentrate on setting LLC correctly, as I described in my previous post, by instead using a steady-state 100% workload (P95 Small FFTs No AVX) to eliminate as many variables as possible. Leave all BIOS settings, including your slightly mismatched RAM, in Auto, except for Vcore and LLC. Start at 4.9 GHz and patiently work with Vcore and LLC till you find a setting that provides a slight Vdroop. Once LLC is tweaked in, then you can focus on working with just Vcore and frequency, again using only P95 Small FFT No AVX.

After you've achieved your highest stable P95 overclock for 2 hours, then you can run further stability tests with fluctuating workloads. Refrain from RAM tweaking until after you're confident that your CPU overclock is indeed stable. If a RAM tweak then causes instabilities, you won't mistake it for a CPU instability. Although your primary timings are identical, there can be secondary or tertiary timings that differ. In this instance, set the faster module to match the slower module. Use a methodical approach and take it one step at a time.

CT :sol:
 
  • Like
Reactions: Darkbreeze
I suggest that you temporarily disregard working with fluctuating workloads and concentrate on setting LLC correctly, as I described in my previous post, by instead using a steady-state 100% workload (P95 Small FFTs No AVX) to eliminate as many variables as possible. Leave all BIOS settings, including your slightly mismatched RAM, in Auto, except for Vcore and LLC. Start at 4.9 GHz and patiently work with Vcore and LLC till you find a setting that provides a slight Vdroop. Once LLC is tweaked in, then you can focus on working with just Vcore and frequency, again using only P95 Small FFT No AVX.

After you've achieved your highest stable P95 overclock for 2 hours, then you can run further stability tests with fluctuating workloads. Refrain from RAM tweaking until after you're confident that your CPU overclock is indeed stable. If a RAM tweak then causes instabilities, you won't mistake it for a CPU instability. Although your primary timings are identical, there can be secondary or tertiary timings that differ. In this instance, set the faster module to match the slower module. Use a methodical approach and take it one step at a time.

CT :sol:
This. Sooooo much THIS.
 

Maikurosofuto

Reputable
Oct 24, 2019
106
16
4,615
Hello guys, sorry but I think I will have to wait to overclock through the BIOS. The BIOS on this motherboard does not appear to be fully polished, the LLC settings regardless of the value give me a not so linear Vdroop, I tried a manual voltage instead of the adaptive one and my processor simply stuck at the base frequency (3800mhz), I will report this behavior to ASUS and see their positioning, but thanks for everyone's help.
 
Last edited: