Opinion on overclock settings

Efriim

@quicksilver
There is more data from the sdram and gpu for it to be a stress test. Given that most crashes are memory leaks, will sequential inconsistencies occur because of the timings, regardless of the raw data or temperature? I don't know, but I do know I can get to crashes while in force_turbo that I won't get to without.

EDIT: Though it is surprisingly easy to set up QIII, and at least I'm not in a middle of a game when I'm testing and it crashes, even if I'm not really playing it can be kind of demoralizing. I look at QIII and I feel less demoralized when it crashes.

quicksilver

@Efriim said in Opinion on overclock settings:

even if you're not really playing it can be kind of demoralizing

Haha that I can agree with. Just remember to test one component at a time so you know what it is that made the test fail.

Efriim

@quicksilver You're absolutely right though, I think you would reach a system halt quicker under a heavy load, so maybe force_turbo it is not comparable. I have to test it. Also do you know if the force_turbo setting actually changes the CPU governor or if it just removes min_freq? or handles things it's own way; can its active part be changed during uptime?

quicksilver

@Efriim force_turbo makes it so there is no CPU governor. You're just running max frequency all the time, pretty pointless and uses more power, makes more heat, and wear and tear. Better to just use the performance mode for the CPU governor.

Efriim

@quicksilver That makes sense.

What do you think of this post by the crudster? I think I want to borrow the sdcard deadline scheduler, but do you think it will improve stability? Use scenario if someone connected to my network and tried to pull a file from my retropie while an emulation is running, or if I tried to push a file, will it not 9/10 times crash my system?

quicksilver

@Efriim tbh I don't know much about what he's doing there. It's a 3 year old post, so how much of that is relevant now, I can't say.

Efriim

I said I combined them, here is what I got now. Did a preliminary QIII test for about an hour with only the ARM and Overvoltage. Followed by about a half hour test with the following and zero crashes.

RPI3B+ RetroPie4.4

#hdmi_drive=2
#hdmi_force_edid_audio=1
disable_overscan=1
disable_splash=1

#force_turbo=1
#boot_delay=2
#temp_limit=70
#temp_soft_limit=70

arm_freq=1575
#gpu_freq=300 #will take on the highest value, this being v3d below
#h264_freq=300
#isp_freq=300
v3d_freq=525
core_freq=600
sdram_freq=450
#sdram_schmoo=0x02000020
#sdram_over_voltage_p=1
#sdram_over_voltage_i=2
#sdram_over_voltage_c=2
over_voltage=2

#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
dtparam=audio=on

gpu_mem=512

I adopted 525 for the v3d, and 600 for the core, h264 and isp can remain at default (adopts the highest value out of gpu/v3d/h264/isp giving all values an umbrella effect?). I lowered the ARM to 1575 after trying everything at 1600 with no marked success.
The rpi3b+ has lpddr2 which has defaults of 1.2V with 400MHz I/O bus clock (800MHz DDR).
I wouldn't know the technical specification or overhead of RPI3 SDRAM.
for id in core sdram_c sdram_i sdram_p ; do echo -e "$id:\t$(vcgencmd measure_volts $id)"; done

sdram_c: volt=1.2500V
sdram_i: volt=1.2500V
sdram_p: volt=1.2250V

These being the default voltages from my CLI.
Setting sdram clock to 450 (DDR 900MHz) with the extra .025V phy and .05V controller and I/O.
I think that would default to:
over_voltage_sdram_p=1
over_voltage_sdram_i=2
over_voltage_sdram_c=2

Will try a memtest and some more thorough tests if I can find any, I may try to improve the sdram speed if I find I need to for any emulation.

I worked backwards, I used arbitrary applied methods (multiples of 75), but I got this far. Thanks for the test run-through, I wouldn't have made any progress without anyone's help here.

EDIT: ;
for id in core sdram_c sdram_i sdram_p ; do echo -e "$id:\t$(vcgencmd measure_volts $id)"; done

#Different overvolt values set with force_turbo=1 & core_freq=600 & core_freq=400 per

over_voltage=0
over_voltage=1
over_voltage=2
over_voltage=3

Returns
The values below reflect a default config with over_voltage and force_turbo, on the right is a pwm_PLL* voltage regulation that was triggered by setting "core_freq=600"

core:   volt=1.3375V   over_voltage=0   #core:   volt=1.3438V-skewed value  
core:   volt=1.3625V   over_voltage=1   #core:   volt=1.3688V-skewed value
core:   volt=1.3875V   over_voltage=2   #core:   volt=1.3938V-clamped value.
core:   volt=1.3938V   over_voltage=3 or greater

Respectively
Setting the core_freq=595 a multiple of the 19.2MHz PLL clock; Would maintain a regular voltage 1.3875 on a cold boot, however on a reset this voltage would get bumped up and I cant yet explain that.

Meaning, over_voltage=3 or greater, appears to be clamped to 1.3938V
disabling force_turbo will let it preside at core: 1.2000V idle.

Now considering invoking minimum values, but contemplating also the CPU/GPU scaler governors exact functions.

Efriim

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.

sdram_over_voltage=
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)

Efriim

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.
Changes:

#This is derived from the LPDDR2E* clock 533.3‾ and hasn't achieved stability.
#sdram_freq=533
#PLL 19.2*31=595.2 rounded and used an odd multiplier but I got an interesting result
core_freq=595
over_voltage=2
#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
***additional

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

Efriim

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.

Efriim

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

force_turbo=1
boot_delay=2
arm_freq=1565
gpu_freq=500
core_freq=566
sdram_freq=450
over_voltage=2

Pretty freakin' stable.

Efriim

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

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!