How to determine how much over_voltage is needed?
-
You might want to talke a look at the overclock page of the wiki, it explains pretty much everything (including overvoltage steps) : https://github.com/RetroPie/RetroPie-Setup/wiki/Overclocking
-
@thewinterdojer said in How to determine how much over_voltage is needed? [Overclock]:
arm_freq=1300
gpu_freq=500
sdram_freq=500
over_voltage=6
v3d_freq=525I was able to bump my
sdram_freq=588
usingover_voltage=4
. I never did try 3. I am atv3d_freq=500
vs. 525. I was never able to get a stable overclock atarm_freq=1350
. Maybe for a short while but eventually I would start having issues.My gpu_freq is 400 (default setting?) I believe. I could bump it to 500 for testing. Ironically or not I found my instability while installing optional packages. :)
I do use active cooling and it clearly runs cooler by several degrees but with that being said active/passive or none I think only the most aggressive settings are going to overheat it. I don't know if shortening the life matters as the trend seems to replace them annually or so.
CPU/GPU core voltage adjustment. [-16,8] equates to [0.8V,1.4V] with 0.025V steps. In other words, specifying -16 will give 0.8V as the GPU/core voltage, and specifying 8 will give 1.4V. For defaults see table below. Values above 6 are only allowed when force_turbo is specified: this sets the warranty bit if over_voltage_ is also set.*
It looks like it's upping the voltage in small increments which creates heat and heat is the enemy in this scenario. ;) With regular computers I've came across several CPU's that have permanent intermittent damage from extreme overclocks that eventually damage/melt that silicon just enough to wreck it and as far as I know there's no software to test for such conditions. With the Pi the price is right if it all goes south doing some testing. :)
-
@theWinterDojer i do not think there is really a reason to have multiple overclock settings. The way I understand overclocking is that you are raising the max thresholds of each setting, you are not forcing them to run that high. This allows your system to run at the maximums set for games requiring the additional speed/power, however if you are running games that don't need the additional resources, they will not need to use them.
So if you are running N64 your pi will push the limits and use everything you allow in your overclock settings, however, if you are running NES games, your system should not run any differntly than it did before.
Now all that said, you still need stable settings, so it is important to test settings to find settings that work for your pi. Even though NES won't push your resources, having the limits to high could still lead to negative performance. I just don't know that it is necessary to run 2 different overclocks when talking 1300 and 1350.
As for your over_voltage, if you are using a 5v 2.5 amp supply, I would reduce from 6 to 4 and see how it runs, if it is stable and no issues great, if you get lags, freezing or lightening bolts then increase to 5, and then last resort 6.
-
@tmntturtlguy THANK YOU. I've had the sneaking suspicion for awhile and when I was never corrected on it I just assumed I was maybe right. I knew the Pi dynamically allocates resources based on demand but I thought once overclocked it was pushing those values at all times. This makes much more sense, you saved me a lot of stress trying to remember if I was overclocked or not and going back and commenting out lines.
I thought 6 is high, but I was following the N64 optimization guide on the Wiki. I've been running these settings for a bit and I'm completely stable:
arm_freq=1300
gpu_freq=500
sdram_freq=500
over_voltage=4Gonna just leave it at this and stop worrying about it.
-
@thewinterdojer i would probably add back in the sdram_schmoo and sdram_over_voltage as well.
Here is what I run, i have had a lot of success on my build, this may or may not work on yours as you are running a 1300.
#uncomment to overclock the arm. 700 MHz is the default. arm_freq=1350 gpu_freq=500 core_freq=500 sdram_freq=500 sdram_schmoo=0x02000020 over_voltage=4 sdram_over_voltage=3 v3d_freq=525
-
@tmntturtlguy I've been struggling with that. I've read some conflicting comments and such, saying that it's not as necessary on a Pi 3 and that the setting is so difficult to dial in, it's better to leave untouched, but I don't know enough about it myself. All I know is that it's something to do with timings of the ram, to increase stability..
What are your thoughts on it, do you think it's really necessary? Also, with those settings, were you getting an under_voltage warning with
sdram_over_voltage=2
? -
@thewinterdojer i haven't seen to many negatives about the sdram_schmoo.....but I am not really familiar with the details of the setting outside of what i have read on the docs, the wiki, and a few youtube videos.
How i got to this point:
I started with the basic settings for overclocking like yours (without sdram_schmoo and without sdram_over_voltage) and had
over_voltage=3.
Running this way i never got the lightening bolt sign, however i noticed after playing for a while i would get some "stuttering" and pausing in the game play. I then upped my over_voltage to 4 and everything worked well. After this i added in the sdram_schmoo and sdram_over_voltage=2. Again i noticed some slight "stuttering" so i upped the sdram_over_voltage to = 3 and everything was smooth again.I need to spend more time playing N64 and PSP games to see how it runs when playing for an hour or 2 without stopping. There are so many things you can play with when overclocking, and just because it works on one pi, doesn't mean it will work on others. I also see a ton of people complain about gave performance and input lag, and I try out the same games with or without overclock and I can barely, if even notice the issues, so it seems to me that i am just not as picky about my game performance as others.
-
@tmntturtlguy In your post you kind of described my dilemma with it maybe being unnecessary. Once you added sdram_schmoo you noticed stuttering again until you upped the voltage to 3, so before you added it, everything was running smoothly. There isn't much about it in the Wiki other than it having to do with "timing of the sdram" I wish I knew more. A helpful fellow from Reddit had this to say about it which is the most I've seen:
Regarding sdram_schmoo, it is mainly used if you are pushing your system so hard it is locking up / freezing. Schmoo, combined with other settings like CAS latencies can be tweaked and fine-tuned to get your system to run ultra-fast but not freeze... However, in dialing in a schmoo, expect to spend 20-30 tries of getting a freeze, popping out the MicroSD card, changing your settings, and popping it back in, praying every time you've done the math right "this time".
Basically, you're fine as is, the settings you are looking into are for extracting every drop of performance from the system under extreme conditions -- in short, I wouldn't worry about them -
@thewinterdojer interesting info. I will have to spend some more time with it! I only overclock for n64, dreamcast, and psp, so getting ever last drop of performance isn't that big of a deal, however, I do want to get a few games to run a little better.....when I get a chance to play in the next few weeks I will test things out and report back.
-
@tmntturtlguy said in How to determine how much over_voltage is needed? [Overclock]:
So if you are running N64 your pi will push the limits and use everything you allow in your overclock settings, however, if you are running NES games, your system should not run any differntly than it did before.
Don't forget the scaling_governor setting would also make a difference in how the settings/resources are used too. I dial most settings to the maximum stable for my card (each Pi seems to be different) and rely on the scaling_governor to make the decision on when to ramp up. I believe it idles around 600Mhz and kicks up to 1300 (my max overclock) when a game starts. For sure it probably wastes some cycles on low resource usage tasks/games but it's ready to go on the more intensive ones. It's kind of the best of both worlds without constant tweaking.
Performance - Always use max cpu freq
Powersave - Always use min cpu freq
Ondemand - Change cpu freq depending on cpu load (On Rasbian, it just switches min and max)
Conservative - Smoothly change cpu freq depending on cpu load
Userspace - Allow user space daemon to control cpufreqwhen I get a chance to play in the next few weeks I will test things out and report back.
I would be curious what settings you get working stable as it help as a baseline so to speak on what people are able to squeeze out of a Pi.
-
@riverstorm Is the Ondemand option what the Pi defaults to? I didn't think it was necessary to mess with the governor unless you wanted to set it to Performance. Also doesn't
force_turbo=1
do the same thing as performance? -
@thewinterdojer said in How to determine how much over_voltage is needed? [Overclock]:
@riverstorm Is the Ondemand option what the Pi defaults to? I didn't think it was necessary to mess with the governor unless you wanted to set it to Performance. Also doesn't
force_turbo=1
do the same thing as performance?It's been a while since I looked at any of these settings. I believe Ondemand is the default. I never fully understood Performance even though it is the setting I use. It doesn't use max CPU all the time. If you use the
watch
command you'll see it bounce up and down. It's also easy to do some testing as Buzz has incorporated it into the RetroPie settings which make it a snap to turn on and off.What I found interesting is the governor kicks up and down frequently even for fractions of a second. It's literally ramps up on a load or resource intensive task and then immediately drops back down and then back up and back down. I wish it had like a threshold setting to leave it ramped up for a specified amount of time. In fact in less intensive games I would still experience stuttering so I now I default it to Performance.
It's almost like a regular computer when it comes to gaming. I never liked throttling. You would be standing around in an MMO and it downclocked to the minimum setting. Then when you start moving you experienced stuttering while it clocked back up. The throttling up and down isn't seamless to the user experience. For day to day tasks I think throttling is great & it's green but for gaming it's painful.
I don't believe
force_turbo=1
is the same setting unless it's coincidental that 1300 is what force_turbo=1 defaults to. This setting also voids the warranty. I suppose if you were overvolting to 8 and forcing 1.4V it might also void the warranty. I always thought Performance uses the default values (overclock or not) set by the parameters in the/boot/config.txt
. Basically the settings you're trying to tweak. -
If I remember correctly I believe the way Buzz configured the scaling_governor (Pefomance or otherwise) is to turn it on during game launch and turn it off when exiting the game. Hence the bouncing CPU. For me that's perfect. I don't see any issues perusing ES with Ondemand (and save resources) but once I start a game I have maximum performance available.
I have no idea what the power savings might come to but the trade-off in Peformance is worth extra electricity and wear and tear on the Pi to know all games are performing at max settings specified by the user. At minimum I don't have to tweak or change settings for extra performance.
I don't have a specific example but some games will lag/stutter with Ondemand where as with Performance they are smooth. That throttle up/down makes a difference. A battery operated rig I suppose is a different story when it comes to conserving energy and Ondemand or Powersave would probably be optimal.
-
@riverstorm Okay, thanks for all the information. I guess I have something to do when I get home today :) It almost doesn't seem like it's worth increasing your thresholds through overclocking without enabling performance mode... at least that's what I have gathered throughout this, I may be wrong on that. I'm going to give it a shot and see how it goes.
I have to enabled it through the runcommand menu on a emulator by emulator basis correct? So maybe for NES I can leave it off, and maybe turn it on for PSX and others, what do you think?
-
@thewinterdojer said in How to determine how much over_voltage is needed? [Overclock]:
It almost doesn't seem like it's worth increasing your thresholds through overclocking without enabling performance mode...
That's just from my experience with Ondemand and limited testing. When a game is idle (under the hood) it will downclock to I think it's 600Mhz then kick back up when needed so games on that threshold or even when they need just a small "kick" over the idle clock speed for even a moment it has to clock up and down. I think like TMNT pointed out if you like how it's working I wouldn't worry to much about using Ondemand vs Peformance.
The performance gain on many games might be small but the trade-off if only marginal is worth it to me. Even if the Pi went the way of a singe-o-matic puff of smoke after 6 months. That hasn't been the case though. Instead of guessing where a few extra Mhz of speed might be needed/beneficial I figure juice them all as the electric bill will still only be a few pennies more. I think our rate here is .07 per kilowatt and the Pi is so modestly priced that it has paid for itself month after month of gaming. We usually spend quite a bit more for one evening out vs the cost of one Pi.
I was messing with Soul Caliber which doesn't really work on the Pi at all but you could see the effects of the up/down clocking. The tearing and stuttering would go from awful to horrendous. Lot's of yo-yoing! I was running a small script that shows the speed, temp, etc. and then used
watch cgu_temp
on a separate monitor to see it kicking up and down. The thought is you can find games that kind of give you an idea how that setting works and how you want to leverage it.I have to enabled it through the runcommand menu on a emulator by emulator basis correct?
I would imagine you could enable it for just the emulators you want to boost. I set it globally via RetroPie Setup right in ES.
- RetroPie Setup
- C Configuration / Tools
- 825 runcommand - The 'runcommand' launch script - needed for launching the emulators from the frontend
- 5 CPU configuration
- 6 Force performance
-
This post is deleted!
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.