Throttling Coniserations: Stress-Testing Newly Installed CPU or SoC

[zzzzzzzzzz2]

Background:
Up until recently, CPU or System-on-Chip (SoC) devices I have stress-tested and that have newly been installed or Thermal Interface Material (TIM) newly applied, have not throttled their performance. In these cases, the cooling system was good enough and the stress procedure was simple: Run a thread in each core for a prolonged period of time (I often used 48 hours), then let cool. The processor would then be effectively broken in to work consistently, and the Thermal Interface Material should have become well distributed.

Especially in modern times, I have come across cooling solutions that are inadequate to cool the newly installed or TIM-ed CPU or SoCs, and are still to be used with the CPUs or SoCs in a final product. Good examples of this are computers with small form factors (oftentimes having a non-standard case), smartphones, and similar electronics.

The Problem:
Newly installed or TIM-ed CPUs and SoCs that have inadequate cooling solutions exhibit behaviors during stress tests that do not manifest when the cooling solutions are adequate. For these devices, one typically observes throttling of performance and sustained high temperatures. As the TIM flows, cures, or sets, the throttling decreases and temperatures might decrease or stay the same.

The Considerations:
It is important to consider how to go about initially stress-testing CPUs or SoCs that have inadequate cooling solutions (and consequently thermal throttle performance) so that they be well exerted to the maximum of their intended performance, and so that their TIM flows, cures, or sets well and properly. If one allows the CPU/SoC to run at maximum, performance throttling occurs and the CPU/SoC cannot run for a prolonged period of time at maximum exertion. I am also uncertain how much the thermal throttling affects the TIM's ability to flow, cure, or set correctly.

The Questions:
What is the best way to go about stress testing under the problem condition described herein?

My impression is that, to be able to account for the various considerations of the problem, one should perform initial stress-testing in one continuous run where the performance is at first intentionally restricted (to avoid thermal throttling's instability), then eventually allow performance to rise in steps until maximum. I would think that this method would best minimize any problems, while also most closely achieving the desired outcome.


What do you guys think? Questions and Comments are welcome.

 

[Zerileous]

Which TIM are you referring to?

Looking at Thermal Grizzly's webpage, all of the conventional TIM offerings state, "no curing," Noctua lists there paste as "no break in or burn in period required," and I believe the same is true for Arctic MX-4 and pretty much any recent paste. As fair as I know it is not necessary to burn in or break in a paste application any more.

 

[EarthDog]

Which TIM are you referring to?

Looking at Thermal Grizzly's webpage, all of the conventional TIM offerings state, "no curing," Noctua lists there paste as "no break in or burn in period required," and I believe the same is true for Arctic MX-4 and pretty much any recent paste. As fair as I know it is not necessary to burn in or break in a paste application any more.

This. There may be others out there, but off the top of my head only arctic silver 5 has a curing time (200 hours or something) and they claim 1-2C difference IIRC.

I'm not e entirely sure of your point or goal here zzzzzzzz, but a simple prolonged load to get the processor hot will 'settle' the paste. Natural use. No cycling, no breaking in, no intentional restricting, no curing, no per core testing, nothing. If we follow your method, a 8c/16t cpu would take 16 days to do what you believe it does. The level of effort to go through what I think you are trying to do, I'm not sure is worth the outcome (no difference).

 

[zzzzzzzzzz2]

Which TIM are you referring to?

Looking at Thermal Grizzly's webpage, all of the conventional TIM offerings state, "no curing," Noctua lists there paste as "no break in or burn in period required," and I believe the same is true for Arctic MX-4 and pretty much any recent paste. As fair as I know it is not necessary to burn in or break in a paste application any more.

This. There may be others out there, but off the top of my head only arctic silver 5 has a curing time (200 hours or something) and they claim 1-2C difference IIRC.

It has been a while (at least 10 years) since I last applied or procured thermal compound. Arctic Silver 5 is also what comes to mind when I think of high curing time. For the thermal pastes that advertise or market as no cure time, it is my experience that it the claim is not true (and typically is actually low cure time) or no cure time at a particular level of performance (which is generally not peak, but often close).

I'm not e entirely sure of your point or goal here zzzzzzzz, but a simple prolonged load to get the processor hot will 'settle' the paste. Natural use. No cycling, no breaking in, no intentional restricting, no curing, no per core testing, nothing. If we follow your method, a 8c/16t cpu would take 16 days to do what you believe it does. The level of effort to go through what I think you are trying to do, I'm not sure is worth the outcome (no difference).

The method I was proposing should take less time, where there is thermal throttling of performance present. As for whether there would be an difference in the end, that is a point I was hoping to receive feedback or opinions about (Thank you).

A large part of the goal of this thread is to acquire feedback and opinions as to how to best manage thermal throttling during an initial stress test.

The main issues I have been trying to address with this thread are the effects of thermal throttling of performance during the initial stress test period. It had been my understanding that peak thermal transfer performance is achieved by stress-testing at the maximum level of performance; however, simply running at maximum for a prolonged period cannot be done due to the processors' down-clocking itself when a thermal threshold is reached. Performance throttling would wherefore be unavoidable. The goal of what I was proposing was intended to optimize the stressing process. A processor's thermal throttling of performance mechanism may not be optimal for stress-testing for initial TIM settling. Many implementations of thermal throttling of performance that I have seen generally have performance drop quite a lot, yet do not allow much time before the high performance state is allowed and achieved again due to temperature changing about the thermal threshold (performance takes the shape of a sine wave on a performance-time graph). My hypothesis was that, by intentionally throttling performance oneself and then stepping up the performance, one would best approach the simple prolonged stress at maximum performance when the processor's automatic thermal throttling cannot otherwise be avoided. I had thought it more important to maintain performance stability than time at peak performance. Peak performance was still considered to be important, so performance may be stepped-up to approach it.

I should further clarify aspects of the methodology. Each core would not be necessarily be stressed individually, but rather performance of each core be restricted to a level less than peak (effectively an underclock of each core) and then stepped up until maximum. This would be done in one continuous run.

The difficult part of my proposed method is determining when to step up or, potentially, down if the new level of performance is too quickly approaching the thermal throttle threshold. Given the added complexity of my proposed stress method, I would think its management would best be implemented in software (heuristic management). I am uncertain if such software exists at present, nor have I recently explored the current stress testing software.

 

[EarthDog]

For the thermal pastes that advertise or market as no cure time, it is my experience that it the claim is not true (and typically is actually low cure time) or no cure time at a particular level of performance (which is generally not peak, but often close).

I dont imagine you see any appreciable difference. If there was, you can bet it would be listed.

The main issues I have been trying to address with this thread are the effects of thermal throttling of performance during the initial stress test period.

Put simply, you shouldn't be running into thermal throttling when stress testing in the first place. If you are then your overclock should be lowered or another change needs to be made (better heatsink, avx offset, etc). Nobody (I know of) tells you stress test while throttling...that makes no sense to me.

For example, a 9900k throttles at 100c, we share with people to keep stress testing up to around 90c. This way, there is no thermal throttling during testing. You get full performance and clearly heat things up as close as you can to the throttling point while still maintaining peak performance.

Again, if people are stress testing while being throttled in any way (temp, current, etc) it isn't being done right. So while I like the thinking around the so-called 'problem', the idea of stress testing while throttled is already fundamentally incorrect and not how it should be done. Don't do that and there are no reindeer games to play with each core etc. The TIM settles on its own without any kind of artificial cycling or games. The amount of effort for no gains just doesn't make this viable. Test properly and one doesn't have to reinvent the wheel.

EDIT: So I read this thread a couple of times to see if I was missing something... and walked away with 'not much'. The problem as you describe it, I don't think is much of a problem in the first place. You cannot overclock a SoC (right?), so I ask, why are you even stress testing it in the first place? A newly installed CPU, at stock speeds, shouldn't throttle... and if it does, it isn't due to TIM needing to settle or cure. So, in the end, I still don't really understand the point in this kind of testing (as I understand it). I don't think most (all?) SoCs can overclock and if you have a new CPU, if you are overclocking, you need a better cooler in the first place. I just don't see the point nor it being any more efficient.

 

[zzzzzzzzzz2]

Sorry for the long delay to respond; there have been rather urgent things that needed my attention.

Put simply, you shouldn't be running into thermal throttling when stress testing in the first place. If you are then your overclock should be lowered or another change needs to be made (better heatsink, avx offset, etc). Nobody (I know of) tells you stress test while throttling...that makes no sense to me.

For example, a 9900k throttles at 100c, we share with people to keep stress testing up to around 90c. This way, there is no thermal throttling during testing. You get full performance and clearly heat things up as close as you can to the throttling point while still maintaining peak performance.

Again, if people are stress testing while being throttled in any way (temp, current, etc) it isn't being done right. So while I like the thinking around the so-called 'problem', the idea of stress testing while throttled is already fundamentally incorrect and not how it should be done. Don't do that and there are no reindeer games to play with each core etc. The TIM settles on its own without any kind of artificial cycling or games. The amount of effort for no gains just doesn't make this viable. Test properly and one doesn't have to reinvent the wheel.

I do agree that it certainly is preferable to test without throttling and to have a proper cooling solution; however, the premise of topic of this thread provides that throttling or inadequate cooling to be a given that cannot be improved upon. Unfortunately, the option to improve the cooling or lower the overclock or voltage is not always available. Again, I give examples of devices with small form factors. The most obvious of such devices are those used in in the portable computing market, such as smartphones. In modern times, it is considered fashionable for smartphones to be very thin, and the devices are often built with inadequate cooling. While it may possibly to improve the cooling solution by modifying the device (for example, by cutting into the case and attaching a decent heatsink/fan), it is generally not practical to do so. Wherefore, it seems important to address how to best handle the cooling problem, given the constraints.

I hope this clarifies the intent of this thread topic.

You cannot overclock a SoC (right?)

The SoC (System-on-Chip) is a compilation of various functionality, that would traditionally be discrete, onto a single chip. SoCs typically still have discrete functionality of, but not limited to, CPU and GPU, and overclocking/underclocking and power management for the individual functionality is possible. Whether it is proper to state that an SoC is overclocked, I am uncertain. Perhaps one should refer to the individual functionality member to the SoCs (i.e. overclocking SoC CPU or undervolting SoC GPU) rather than to the SoCs themselves.

As a side note, it seems that this thread would have been better suited for the Cooling forum. Perhaps a moderator/administrator would move the thread there.