- Joined
- Oct 18, 2005
- Thread Starter
- #21
After almost 7 hours of 36x testing, combined with all sorts of other random activities on the system, I figured it was stable enough at -0.110 V.
In trying to come up with what I do next, I figured the best thing would be to gain some insight into exactly how what I now know as "Speed Shift" behaves. More specifically, at any given setting I plop in, I want to know exactly what frequency multipliers are jumped to at all parts of the utilization spectrum.
The reason for this is because if I run into any problems with instability at lower usage/idle, knowing which multipliers are used might help me suss out if any specific frequency/voltage combo is particularly problematic, such as potentially prime testing that frequency. If this method does indeed end up reliably getting crashes at certain frequency/voltage steps on an adaptive curve at a given voltage offset setting, it could be used to fine tune the curve and maybe give it a little bump at certain frequency steps, instead of just backing off the entire thing.
It may sound like too much effort for too little reward, and it might be, which is why I don't plan on doing anything more than exploratory messing around with this, unless I run into actual issues with idle/mid-range/bursty load situations. And if all it takes to fix it is just 1 or 2 voltage bumps, maybe it isn't worth it. However, if the lower load situation instabilities that may occur end up becoming a much bigger problem, such as needing 4+ voltage bumps, it may become profitable to dig in deeper. The worst I can do is waste my time while learning a lot more about the CPUs for later.
I was hoping to find a piece of software that would log every single frequency multiplier change in a slice of time. While I haven't yet been able to find that, the closest thing I came to was MSI Afterburner.
MSI Afterburner's monitoring is far more CPU efficient than Hwinfo and other programs. Even at 100ms update rate, its CPU usage remains low (if I underclock the video card too low, it actually doesn't animate the line graphs smoothly ^_^).
Now, these charts can't be conveniently paused, nor can they be zoomed/scrolled. A horrible way to dig into the data. However, they can be logged. With what's displayed here, even with the high update rate, logging did not hammer the hard drive. It only did about 6 KB/s write.
So it appears I have what might end up being useful as a way to map out the frequency multipliers that actually are used, even if it's a terribly ghetto way to do it. I find it surprising nobody has already made software to analyze this more easily (maybe the CPU manufacturers have proprietary in-house stuff for testing/development)... or does such software exist?
Unfortunately Afterburner doesn't track core VID or Vcore. However, I can try doing logging with Hwinfo or a new program I found called Quick CPU.
One potential complication:
The monitoring software, particularly at high polling rates, will interfere and prevent many/all cores from falling to minimum frequency/power states, or make it so the lowest frequency multipliers occur much less often, making it more difficult to map them out. I think just setting a very low poll rate and letting it log for many hours would be the easiest way to mitigate/eliminate this problem.
So it's nice to know that these methods are at my disposal in case I need them.
Another potentially profitable piece of software is Quick CPU. It seems to have even more advanced settings than XTU or the MSI Bios, which may end up being great to experiment with for further wattage saving. And it's just overall very handy, and may even rival XTU as a live-tweaking tool.
Curse the great blinding whiteness of it all!
I feel like I'm wasting a huge opportunity not having anything specific I want to test, particularly with high power stress tests, while I sleep and a bunch of cold air can get in through the crack in the window, being that it's freezing outside. However, I decided to flip the script a bit and instead test the -0.110 V with 47x max turbo p-core just sitting doing almost nothing for several hours, and log the frequencies at a 5 second interval to minimize CPU usage. But I'll leave a couple things open to maybe let it spike up from time to time. I'm sure with various scheduled background BS spikes of various power will happen once in a while. The main purpose of the log will be to build a reference for later.
Aside from that, I'm also considering the idea of seeing what kind of overclock could be achieved without giving up too much undervolting. I figure with aggressive power-saving/auto-downclocking idle cores, increasing the maximum turbo frequency or whatever for the p-cores, even with a modest voltage bump upward compared to the max stable undervolt I've found so far, would likely allow for greater power if it's needed, while still overall using less power nearly all the time.
I've also reconsidered the idea of maintaining an underclock. If I need to process certain things (and not just add extra FPS to games), running at 36x instead of 47x+ is foolish, because it will just take longer to do the same processing anyway, using the same overall amount of power, as long as none of my applications/uses end up being power viruses that will use everything they can get (i doubt they will). So it's better to just make everything snappier and run them at higher frequency, so the spikes will be shorter and utilization % lower. Overall power usage should not increase much compared to underclocking. Underclocking only seems to be an amazing power saver when you're doing artificial load tests. Only undervolting itself is a reliable way to save power without increasing suffering.
In trying to come up with what I do next, I figured the best thing would be to gain some insight into exactly how what I now know as "Speed Shift" behaves. More specifically, at any given setting I plop in, I want to know exactly what frequency multipliers are jumped to at all parts of the utilization spectrum.
The reason for this is because if I run into any problems with instability at lower usage/idle, knowing which multipliers are used might help me suss out if any specific frequency/voltage combo is particularly problematic, such as potentially prime testing that frequency. If this method does indeed end up reliably getting crashes at certain frequency/voltage steps on an adaptive curve at a given voltage offset setting, it could be used to fine tune the curve and maybe give it a little bump at certain frequency steps, instead of just backing off the entire thing.
It may sound like too much effort for too little reward, and it might be, which is why I don't plan on doing anything more than exploratory messing around with this, unless I run into actual issues with idle/mid-range/bursty load situations. And if all it takes to fix it is just 1 or 2 voltage bumps, maybe it isn't worth it. However, if the lower load situation instabilities that may occur end up becoming a much bigger problem, such as needing 4+ voltage bumps, it may become profitable to dig in deeper. The worst I can do is waste my time while learning a lot more about the CPUs for later.
I was hoping to find a piece of software that would log every single frequency multiplier change in a slice of time. While I haven't yet been able to find that, the closest thing I came to was MSI Afterburner.
MSI Afterburner's monitoring is far more CPU efficient than Hwinfo and other programs. Even at 100ms update rate, its CPU usage remains low (if I underclock the video card too low, it actually doesn't animate the line graphs smoothly ^_^).

Now, these charts can't be conveniently paused, nor can they be zoomed/scrolled. A horrible way to dig into the data. However, they can be logged. With what's displayed here, even with the high update rate, logging did not hammer the hard drive. It only did about 6 KB/s write.

So it appears I have what might end up being useful as a way to map out the frequency multipliers that actually are used, even if it's a terribly ghetto way to do it. I find it surprising nobody has already made software to analyze this more easily (maybe the CPU manufacturers have proprietary in-house stuff for testing/development)... or does such software exist?
Unfortunately Afterburner doesn't track core VID or Vcore. However, I can try doing logging with Hwinfo or a new program I found called Quick CPU.
One potential complication:
The monitoring software, particularly at high polling rates, will interfere and prevent many/all cores from falling to minimum frequency/power states, or make it so the lowest frequency multipliers occur much less often, making it more difficult to map them out. I think just setting a very low poll rate and letting it log for many hours would be the easiest way to mitigate/eliminate this problem.
So it's nice to know that these methods are at my disposal in case I need them.
Another potentially profitable piece of software is Quick CPU. It seems to have even more advanced settings than XTU or the MSI Bios, which may end up being great to experiment with for further wattage saving. And it's just overall very handy, and may even rival XTU as a live-tweaking tool.
Curse the great blinding whiteness of it all!


I feel like I'm wasting a huge opportunity not having anything specific I want to test, particularly with high power stress tests, while I sleep and a bunch of cold air can get in through the crack in the window, being that it's freezing outside. However, I decided to flip the script a bit and instead test the -0.110 V with 47x max turbo p-core just sitting doing almost nothing for several hours, and log the frequencies at a 5 second interval to minimize CPU usage. But I'll leave a couple things open to maybe let it spike up from time to time. I'm sure with various scheduled background BS spikes of various power will happen once in a while. The main purpose of the log will be to build a reference for later.
Aside from that, I'm also considering the idea of seeing what kind of overclock could be achieved without giving up too much undervolting. I figure with aggressive power-saving/auto-downclocking idle cores, increasing the maximum turbo frequency or whatever for the p-cores, even with a modest voltage bump upward compared to the max stable undervolt I've found so far, would likely allow for greater power if it's needed, while still overall using less power nearly all the time.
I've also reconsidered the idea of maintaining an underclock. If I need to process certain things (and not just add extra FPS to games), running at 36x instead of 47x+ is foolish, because it will just take longer to do the same processing anyway, using the same overall amount of power, as long as none of my applications/uses end up being power viruses that will use everything they can get (i doubt they will). So it's better to just make everything snappier and run them at higher frequency, so the spikes will be shorter and utilization % lower. Overall power usage should not increase much compared to underclocking. Underclocking only seems to be an amazing power saver when you're doing artificial load tests. Only undervolting itself is a reliable way to save power without increasing suffering.