Please do not post a support request without first reading and following the advice in

Opinion on overclock settings

  • The following applied to the specifics of my Retroflag case, which feeds power to the RPI through the gpio, incidentally disabling over_voltage_sdram. I had forgotten this detail and it occured to me post.

    In any scope, results in no change reported by:
    for id in core sdram_p sdram_i sdram_c ; do echo -e "$id:\t$(vcgencmd measure_volts $id)"; done
    always same
    sdram_p: volt=1.2250V
    sdram_i: volt=1.2500V
    sdram_c: volt=1.2500V

    Maybe it is

    My device:

    • Raspberry PI 3B+ with 5V 2.5A power supply
    • Retroflag Megapi case with fan*
    • RetroPie 4.4 built from SD image on Retropie website (retropie-4.4-rpi2_rpi3.img)*
    • vcgencmd version
      Nov 4 2018 16:31:07
      Copyright (c) 2012 Broadcom
      version ed5baf9520a3c4ca82ba38594b898f0c0446da66 (clean) (release)

  • I tried some more sdram_over_voltage with no breakthrough, including; over_voltage_sdram=, avoid_pwm_pll=1, force_turbo=1
    I think that maybe it is under a different alias, or I'm missing something about the capabilities of the 3b+.

    I read some more about the PLL using a clock of 19.2MHz on modern PI's and I adjusted some values and results that I will change in the above post if they are stable.

    #This is derived from the LPDDR2E* clock 533.3‾ and hasn't achieved stability.
    #PLL 19.2*31=595.2 rounded and used an odd multiplier but I got an interesting result
    #Measuring voltage with "vcgencmd measure_volts core" returned "volt=1.3875V" as opposed to the skewed value that results from using core_freq=600
    #adjusting to over_voltage=3 resulted in the same clamped value of "volt=1.3937V"
    #there is likely something I don't understand happening with these skewed voltages, will investigate further

    Further tests, shows that I am getting voltage modification from something additionally(gpu_freq? overhead?). As it might be related to my powersupply I would like others feedback on this.

    EDIT: The references for LPDDR2 I think the extra wide modules run in 1.8v or maybe it is the LPDDR2E I couldn't find the reference on the wiki page, GDDR6 isn't even a new thing, its hard to site this stuff. Regardless, I couldn't get the 533Mhz to stabilize. And now ignoring sdram_over_clock and _schmoo on the RPI3B+ and moving on to the dynamic PLL that is possibly tied to the core_freq.

    The dynamics of the "Pulse Width Modulator on Phase Locked Loop" (pwm_pll) used to achieve the accurate frequencies; there wasn't many references especially for the RPI3/3B/3B+. From what I can understand*; There is a clock, the PLL; that can be divided, and with it you can simulate a constant voltage with the PWM, and this is used for overclocking the SoC there is also a PWM for the GPIO and two for RPI3B GPIO. The other articles I read** state that one of these PLLs is dynamically set by the core_freq, however finding the formula for the voltage controlled oscillator to the clock isn't as simple as dividing by 19.2, I did try some arbitrary factoring. *article1 **article2

    My results: (Updated) Unstable
    OCing the core_freq to 566 and gpu_freq to 500 and arm_freq_1565, has given me a much more constant voltage.
    with over_voltage of 2 I get a more consistent voltage of 1.3875 and the arm_freq is without as many fluctuations, however occasionally this is dropped and I get the skewed voltage values again. SDRAM is a more volatile space, and I haven't yet decided the best approach but remained at underclock of 450 for the extra voltage .05-.025 voltage that is programmed on the RPI3B+.

  • The Retroflag case connects to and powers the Raspberry Pi through the GPIO

    I took it off and discovered that the over_voltage_sdram works as per normal. I'm going to run some more tests without the fan.
    In addition to the above, better power management exists than I previously knew. Running quake III using the Overclock in my next post I discovered a completely new powerstate/overclock, that which didn't exist using the GPIO power. The ARM CPU frequency is ignored despite being set to force_turbo and 1565, and instead has changed to 1200, the core voltage additionally has dropped to 1.2875. CPU and GPU are reaching up to 68 degrees Celsius. The game runs fine, but this never happened before using the case, this is most likely from reaching the soft_temp_limit no?

    EDIT: I much later realized that I had used the incorrect definition sdram_over_voltage instead of over_voltage_sdram.

  • Latest overclock displaying regular voltages: 1.3875V Core 1.2250V Sdram

    • RPI3B+ Element14
    • Retroflag MegaPi case with GPIO Switch and Fan
    • 5V 2.5A power supply, 2m (long) cable

    Pretty freakin' stable.

  • I realized that my RPI is being fed power through the GPIO of my case, I disassembled it and tried the over_voltage_sdram, with RPI powered normally. This was indeed the reason I couldnt over_volt the sdram, I guess I'll try and make up for it editing the posts above to clarify that. Now, I can try overclocking the sdram but I don't know if I want to, if I'm just going to put the case back on.

    As I though this was indeed the reason, though I tested both over_voltage_sdram names, I must have misused the parameters to not notice the incorrect one. Additionally, only sometimes does an over_voltage_sdram=8 reach 1.4000V while other times it will reach 1.3936V

  • I dialed in over_voltage_sdram with the case back on and the sdram voltage is reflecting the change. I couldn't say what oversight I had that it didn't appear to be working for me, I doubt that there was an OTP bit when I plugged the usb power directly in. Hmm, I dont know.

    I added the sdram overclock that I wanted to, to my configuration.


    The sdram was a bottleneck, and EmulationStation is remarkably faster than before. I don't know about the voltage values, I wanted the highest for the physical because of the overclock; the controller and i/o I thought would be just as stable, but maybe they prefer uniform. Anyway, its been stable.

  • I over_volted the sdram controller, and it seems noticeably faster. I don't know which one is the main factor for stabilizing the freq. I/O and controller were at the defaults for my device, and the previously unstable value of 533 has been very stable with only physical ram overvoltage. I guess that is speculation a lucky guess maybe.

    will give you boot time information and more.

  • So I guess the RPI3 and the RPI3B+ have the same SOC and could theoretically use the same overclock, whats to say otherwise? They may require different over_voltage values.

    I thought that my fan wasn't running right because of low voltage, It turns out I definitely had it screwed on too tight, its pretty sensitive though, I'll just have to tinker with it for a while.

    I still get low-voltage whenever I plug in a controller to charge, what do you guys think my best solution is? Should I get a 5.2V power supply, or should I try to make a hardware sacrifice, disable onboard wlan? Does anyone know how? Will it also disable bluetooth?

  • @Dwarfboysim @quicksilver
    I think OP could make best use of a higher sdram clock, I believe he has the same ram as the B+. I could not go past 600mhz however 600 is very stable and the double data rate is like adding 200mhz right?

    I haven't successfully set any *freq_min values.
    I set force_turbo because of this as it speeds up the OS and boot times immensely.
    It does speed up the OS, however I haven't noticed the boot time is at all significantly faster, forgive my fallibility.

    There are considerations for the wear and tear. All of these components have a high operating temperature, but the pi can only generate so much heat there are failsafes for temperature limits. There are other considerations.

    I think it weighs on whether you have a faulty or defective board. I'm thinking of failing electronics and I'm not seeing that the pi shares anything with these other than its electronic. It just can't generate enough heat, or can it?

    I use an element14 board.
    My rpi2 is a vilros.
    I miss that the rpi2 never needed a fan.
    What is left to say for fanless rpi3?
    Does anyone have an effective schematic, an overclock for non-cool systems?

  • I have been experiencing some voltage issues I haven't read about. I have been testing overclock settings with Quake III as instructed by @quicksilver earlier in this thread. I have been performing the tests in two different power supplies (one at my house and the other at my Mom's).

    After ticking the core and gpu settings past 450 I began to notice an under-voltage warning accompanied by frame drops, I adjusted over-voltage but it never helped. But when I would run the test at my house it would run flawlessly without voltages warnings, frame drops, or crashing.

    I have tested these these settings for 6 hours, that long because I fell asleep; woke up and it was still running, 1800 frags and still running smooth with no voltage issues.


    Those settings get intermittent under-voltage warnings when I use the power supply at me Mom's house. They are both the same canakit 5v 2.5a power supplies, nor do I get the voltage warnings when testing at default settings with that power supply. But I am not yet ready to lay full blame on the power supply, it could be the connector on the NesPi+. I made physical adjustments to the connector when I bought it, to make a better connection, but it has since sunk back into the case. I am not looking forward to opening it up as it is highly customized.

    Thank you to @Efriim for posting the results of your experiments, this has been the most helpful thread for information on overclocking.

  • @GoldManSex778 I had issues with my canakit power supply and the nespi case. I would get intermittent low voltage warnings when overclocked so I switched to a different brand power supply. If one of your canakit power supplies has issues and the other doesn't, it's possible one is defective or is going bad.

    Also remember that over volting can make your overclock more stable but it will make your issue with a bad power supply worse, not better.

  • @GoldManSex778
    Sometimes I get low voltage, due to the wall outlet to usb being loose on either end. I didn't expect that this was the case but resituating the connection has usually 9/10 solved it.

    I think I have a 3M 20AWG no switch cord 5V 2.5A iTrunk media Power supply.

    I don't have much to say about the over_voltage settings and low-voltage warnings, I've tested multiple processes that use all cores, and I will get low-voltage whether default settings or no.

    sdram_over_voltage=5 needs to be over_voltage_sdram=5 I think I made the same mistake, it might have been posted incorrectly somewhere.

    You're welcome, I was learning a lot back then everything was new.

    I haven't refined the overclocking I was using last, this again is on a rpi3b+

    #dtparam=sd_overclock=100 #samsung sdcard

    If on a RPI3b+ over_voltage=; greater than 2 I think will have no use unless you are using arm_freq 600-1200. The AVS will typically raise the voltage to 1.3500V or 1.34375V if the arm_freq is above 1200 and will not go above 1.39375V. I have not been able to get a 1.4000V but I have gotten a 1.3850V ( I think it was an AVS 1.3350V + overvolt 2 (0.050V)).

    It is also possible to enter microvolt amounts for example:
    over_voltage=25000 is equal to over_voltage=1
    over_voltage=50000 is equal to over_voltage=2
    any microvolt amount entered will be emulated by the controller. This I think has no change on the AVS though, as that is something I haven't figured out yet entirely. If you have an AVS 143750 then adding over_voltage=6250 will result in 1.2V + 0.14375V(AVS) + 0.00625(overvolt) = 1.3500V. The AVS is set on boot it could be based on the last highest OSC of which is used to achieve the voltages or SoC core frequencies. I wouldn't recommend setting the osc manually using the config.txt unless you know what you're doing.

    The really high sdram_freq hasn't ever had a problem with emulations, however using memtester it still has errors. Lowering the arm_freq with this setting improves the stability lowering the errors found in memtester during bitflips, and the over_voltage_sdram_c can still be experimented with.

    I have been underclocking lately, unplugging the fan because it fits too tight in my case and gets pressed on by the heatsink. Probably invest in sandpaper soon.

    Here is a combined script for getting some useful data

    for id in core sdram_p sdram_i sdram_c ; do echo -e "$id:\t$(vcgencmd measure_volts $id)"; done
    for src in arm core h264 isp v3d; do echo -e "$src:\t$(vcgencmd measure_clock $src)"; done
    cpuTemp0=$(cat /sys/class/thermal/thermal_zone0/temp)
    cpuTempM=$(($cpuTemp2 % $cpuTemp1))
    echo CPU temp"="$cpuTemp1"."$cpuTempM"'C"
    echo GPU $(/opt/vc/bin/vcgencmd measure_temp)
    #free -h
    #df -h

    sudo chmod +x

  • @quicksilver Thank you, I am not surprised as I have heard of canakit's power supplies being subpar. Glad I have at least one good one, would you recommend the power supply you are using?

    As for the over-volting, the only reason I have it set that high is because I thought the under-volt warnings indicated that I needed to raise the voltages, but as you said, this didn't help.

    @Efriim thank you, that is a good point about the connection quality, the good power supply gives a satisfying snug fit feeling when I plug it in, the other doesn't. This could be compounded by the connector on the nespi.

    Thank you for reminding me about the over_voltage_sdram, I copied some of your settings a few times so it is possible. I remember you writing about that in a previous post and I made a mental note to check that.

    I don't understand what you mean by AVS (average voltage?) or OSC. I definitely will be bringing the settings down, although all the 5s really tickle my inner math teacher.

    Those are definitely some interesting settings you have and that script looks very useful!

    Thank you both again!

  • @GoldManSex778
    AVS is Adaptive Voltage Scaling, and OSC is I think Oscillator; something crystal.

    vcgencmd get_config int
    will tell you what is set for the config
    vcgencmd get_config int | egrep "(arm|core|gpu|sdram|osc)_freq|over_voltage"
    will highlight relevant freq and volt settings, the osc and avs_boost are in 0xF hex.
    the over_voltage_avs I don't think can be set in config.txt, however the desired osc can be set and again I would strongly forewarn against this.
    vcgencmd read_ring_osc 1 or 2, 8, 10, 11, 14
    will read other oscs. I don't know what all the different ones correlate to 1 - 14.

    with my settings I showed previously; increment to "over_voltage_sdram_c=5"; got no errors in 7 * 100mb tests, * 3 (edit: bad multiplication 3x interrupted at 7 was about 20) instances of memtester on 3 of 4 cores, just now. Now testing 4 instances of memtester on each core.
    I'm surprised I'm not getting undervoltage either.
    Test Completed
    4* memtester 100M 20 w/ 5 * ssh connections and EmulationStation in the background, taking commands from the 5th TTY.
    That is 400M of memory locked at one time and being processed by 4 cpu cores.
    I only encountered one error right after reading OSCs and issuing a few commands, yet it was the usual bitflip 154.
    This was excessive and a good test; Most applications never use all four cores. Next time I think I would run memtester 150 3.

    Micro-Usb connections are really obsolete, more so in this type of usage. A cool thing I noticed about the retroflag cases is; the microusb connector is on a separate board, a usb-c could be soldered on more easily.

    btw what model of pi are you using?

  • @Efriim Thank you! That looks like a lot of fun, maybe not as much fun as watching a bunch of dim-witted bots slug it out for hours. But most of the fun I now have on the pi is getting stuff like this working, ironic isn't it. Thank you for explaining that, I am able to follow most of what you have written, still my overclocking experience comes from the days when you had to flip dip switches or flash a bios to get a few extra frames in Half-Life; it astonishes me that I am over-clocking something by editing a text file.

    That is a very good idea about soldering another power connector, having a more robust power option would solve a lot of problems on the nespi case. I wouldn't be brave enough to try it with my soldering skills, usb-c would probably require a whole new board, the specs look scary 20v 5amps 100watts; electrical fires scare me, and these fly-by-night canakit power supplies do not ease my concerns.

    I am using a 3b+, NesPi+ case, 5v Noctua fan powered from the case, and a 256 gb flash drive stuffed in it; so there is no small load on it.

  • An honest question: Why are you using anything else than the official Raspberry Pi power supply? I see people complaining everywhere about sub-par power supplies, but the official one is dirt cheap and has never given me any undervoltage warnings. Not even when overclocking my Pi 3B+ and running Linpack on it.

  • @Brunnis That is a fair point, and for my part it boils down to caveat emptor. Even now when I look up "raspberry pi 3b+ power supply" on amazon, canakit dominates the top results with four and a half star ratings; below that is a galaxy of off-name brands, it is difficult for me to see where the official power supply is.

    The first power supply I got came with the kit, worked flawlessly. I went to local "cell phone accessory" stores but none of them had anything that went up to 2.5 amps. I have a drawer full of micro-usb power adapters, a couple of which go up to 2.4 amps but they don't push enough power for the 3b+. So when I ordered the second I went with canakit.

    I don't know whether I am a bad consumer who made poor choices, or a poor consumer given a choice between only bad choices.

  • @GoldManSex778 I can understand that. I tried searching Amazon and you're right, it doesn't seem like they even have the official one. Strange. It's easy to get hold of it here in Sweden.

    Just saw that CanaKit actually sell the official one:

    They only seem to carry the universal one. There's also another one that looks like this here in the EU:

    I have one of each and they both work equally well, as far as I can tell.

  • @Brunnis
    Likewise as GoldMan. I searched on amazon for the the PSU when I was upgrading around last christmas from a rpi2 that I had for a couple years and had found nothing of the official power supplies. I didn't know an official power supply existed until a couple months ago on the forums here, I almost denied its existence.

    I had increased the over_voltage from 1 to 2 on my configuration and I started to get undervolt warnings again. I guess the power of awareness makes this seem really obvious now, but I have quite a few things plugged in as it is sort of a balance of power. I set it back to over_voltage=1 and it is okay; over_voltage=1 has been enough for both core_freq=600 and arm_freq=1500 on rpi3b+.

  • @Efriim That is actually very reassuring, there is very little information that I have found that indicates what over-voltage "ought" to be sufficient. What all do you have connected to your pi, besides a commodore 64 printer?

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.