Opinion on overclock settings

Efriim

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.

sdram_freq=533
over_voltage_sdram_p=7
over_voltage_sdram_i=2
over_voltage_sdram_c=2

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.

Efriim

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.

dmesg
and
systemd-analyze
will give you boot time information and more.

Efriim

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?

Efriim

@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?

GoldManSex778

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.

#arm_freq=1450
gpu_freq=500
core_freq=500
sdram_freq=500
over_voltage=5
sdram_over_voltage=5

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.

quicksilver

@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.

Efriim

@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+

arm_freq=1500
gpu_freq=300
core_freq=600
sdram_freq=667
over_voltage_sdram_p=8
over_voltage_sdram_i=8
over_voltage_sdram_c=5
over_voltage=1 
#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
nano temp.sh

#!/bin/bash
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)
cpuTemp1=$(($cpuTemp0/1000))
cpuTemp2=$(($cpuTemp0/100))
cpuTempM=$(($cpuTemp2 % $cpuTemp1))
echo CPU temp"="$cpuTemp1"."$cpuTempM"'C"
echo GPU $(/opt/vc/bin/vcgencmd measure_temp)
#free -h
#df -h
systemd-analyze

sudo chmod +x temp.sh
./temp.sh

GoldManSex778

@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!

Efriim

@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.
and
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?

GoldManSex778

@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.

Brunnis

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.

GoldManSex778

@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.

Brunnis

@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: https://www.canakit.com/official-raspberry-pi-power-supply.html

They only seem to carry the universal one. There's also another one that looks like this here in the EU: https://www.dustinhome.se/product/5011117681/stromadapter

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

Efriim

@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.

@GoldManSex778
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+.

GoldManSex778

@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?

Efriim

@GoldManSex778
Yes it is something to understand the needed voltage steps as well as the added AVS over voltage. From my note taking:
The "over_voltage_avs=" will be used for arm frequencies in the range of 601-1200; the value assigned to over_voltage_avs is determined initially once at boot and is typically 31250(0.03125V) or 37500(0.0375V); giving the core voltage an amount equal to 1.23125V or 1.2375V respectively and any "over_voltage" is added on to those amounts, while "over_voltage_min" is added onto 1.2V until the AVS ignores it (possibly not exceeding 1.25V min).
The "over_voltage_avs_boost=" will be used for arm frequencies in the range of 1201-1600; the value assigned to the avs_boost is determined initially once at boot and is typically 143750(0.14375V) 150000(0.15V); giving the core voltage an amount equal to 1.34375V or 1.35V.
The determinants for the AVS values have been hard to comprehensively assign given their inconsistency with the other initialized config.txt settings; as for the assumed factor, it seems any of the arm and gpu core frequencies can have an effect, and further away from my understanding the OSC and PLL (phase locked loop) have a direct correlation.
As well the implicit incorrectness in my notes, for example using an arm_freq less than 600 was away from where I wanted to test, and overclocking any of the gpu cores could have had more special results for the AVS not actually recorded.
If the arm_freq is set to 1200 and the effective governor/scaler/forceturbo is actively using this mode, without over_voltage; the highest core/gpu_freq that can be used was around 530 at 1.2313V, this amount achieved graphical errors, the gpu doesn't like to get far past 500 while the gpu core doesn't go far beyond 600.
Combining the settings below alone would result in halted system because the core_freq requires a greater voltage than the AVS provided by the arm at 1200, 1.2313V. There is perhaps an exception if exists a way to make effective the AVS_boost without the arm exceeding 1200, or just add a over_volt=5 and the additional 0.125V will be enough for core_freq=600, 1.3563V

arm_freq=1200
gpu_freq=500
core_freq=600

If the arm_freq is normally overclocked 1400-1500 then the AVS_Boost (~0.15V+1.2V) will be added (~1.3500V)
The maximum core_freq was about on the mark of 608 with this voltage and 601 with the hinder avs_boost (1.3438V). These are maximums and I didn't prove any stability, only that core_freq=608 would not boot with less than 1.35V.
The maximum arm_freq achieved with 1.35V was 1556 where an over_voltage of 1 was needed to go higher.
EDIT
~~I found that core_freq=600 is stable~~ with over_voltage=0 and an avs_boost of 0x2191c (137500) + 1.2V = 1.3375V which is a lower voltage than I previously thought ( 1.34375V) by a 6250uV step.
The AVS is weird.
I guess it is worth noting that the AVS is dynamic across all cores, for example when a process uses all 4 cores it will use more voltage and give low-voltage warning in some scenarios. However I think the same AVS value will be shared regardless of the core.

I have a Flash Drive and a Logitech Nano Receiver and... ethernet. If I plug in my controller to charge I get undervolt, If I then unplug the Logitech receiver then the undervolt warnings will go away.

Efriim

I have this table I haven't updated it in a while the sdram voltages aren't really recommended.
https://drive.google.com/open?id=1Zlu-fv6NS9YB0YwETjZU1wtEOoEhZrYL
well none of it is really recommended, it is possibly difficult to read and get much useful information from.

As it was initially stated by quicksilver, and I could confirm the other day experiencing this; the over_voltage in excess will contribute to the undervoltage detected across the board. Though it is possible and even practical to undervolt combining the use of "over_voltage_min" and setting the cores to lower frequencies.
With only the setting arm_freq=1200. It was sufficient for all of the games I tried on psx and snes, while keeping a low enough temperature and voltage profile, not needing a fan or exceeding 1.2375V per core.

Still remains, it is sometimes an imperfect power supply coupling or too many peripherals.

GoldManSex778

@Efriim said in Opinion on overclock settings:

the highest core/gpu_freq that can be used was around 530 at 1.2313V, this amount achieved graphical errors, the gpu doesn't like to get far past 500 while the gpu core doesn't go far beyond 600.

That makes sense, I was getting crashes in quake 3 when I would take the gpu/core up to 500 without any over-volting, it could have also been exacerbated by the power supply issue.

Still remains, it is sometimes an imperfect power supply coupling or too many peripherals.

Does that happen when you connect everything to the pi istelf? Looking at the megapi case (that a cool case!) It looks like it powers the usb hub the same way as the nespi case. I can't remember how the power is handled (whether it comes straight from the power supply or from the pi via the poor wiring). The case may be powering the peripherals in a first-pass manner causing the current to the pi to drop.

I tested these settings for over 3 hours with no problems.

arm_freq=1450
gpu_freq=500
core_freq=500
sdram_freq=500
over_voltage=1
over_voltage_sdram=1

over_voltage=1 is sufficient as you predicted, I probably don't need the the over_voltage_sdram either (BTW you were right, I had it miss-labeled as you did lol). It made a pretty good improvement, prboom now runs Doom at 3x resolution, even Ninja Baseball Batman runs smoother now, which surprised me.

I tested arm_freq=1500 and got crashes on quake 3 after about an hour and a half, So I guess that is just a bit too high. Too bad, the 1500=500+500+500 would have satisfied my inner OCD.

Efriim

@GoldManSex778

Looking closely at the megapi board, the usb hubs appear to share a powered connection through the case as opposed to being more directly routed to the pi. Much too soon before, when I had been using over_voltage=1, having both my controller charging and the logitech receiver plugged in to these front ports did cause the power to drop low enough for warnings but not consistently leading me to think that it is the power supplies microusb connection.

I have disabled the swap space on all of my installations, I can't say if this is very important because I haven't operated much at all while it was enabled.

I'm wondering what make did your Pi come from? For example I have an element14 board.
Also the microsd is it UHS-1 or 3 or a kingston class(4) or (6). A slower microsd in theory could offer instability when computations exceed its limits.

I have $40 dollars that I have saved and want to spend on upgrading something on my pi.
A controller is likely. I was also looking into getting an rtc module but these take the gpio that the case is already using, I don't know if I could fit it. An official powersupply was a maybe, but I'm finding I can work with the one I have now. A smaller fan that will fit correctly but sanding the case a millimeter I think will work just as well. There was a link someone shared me, that was a fan module controller that worked with retroflag cases, to control the fan power.
Any other ideas? Controller recommends? What do you use?

Efriim

@GoldManSex778
over_voltage_sdram=1 can be discarded, as the default voltage for all the sdram components on the rpi3b+ are
over_voltage_sdram_p=1
over_voltage_sdram_i=2
over_voltage_sdram_c=2
where over_voltage_sdram=1 will be ignored and 2 will step up the over_voltage_sdram_p by 1 giving all the value of 2.
To lower the voltage below the default you have to use over_voltage_sdram_p_min=-1 and so forth.

I found a Sega controller.
Good reviews. I dont think I will be missing analog too much. 10ft usb.

Some of the console controllers can be had for the same price, I think I saw an XB1 official for $22. Which has me hesitant on whether I should get something like this instead.