Opinion on overclock settings

Dwarfboysim

@shavecat how does the large double fan fix down does it have adhesive strips? How much noise does it make and can it fit in an official Pi 3 case or is there a case more suited to it?

shavecat

@Dwarfboysim
the double fans (i cut them on the middle really gently) and put them inside...
i just order that.
https://www.ebay.com/itm/NESPi-Case-for-Raspberry-Pi-3-Retropie-Nintendo-NES-SNES-N64-Sega-PS1/202048309281?hash=item2f0b048821:g:a14AAOSwE8daUFeM
before that just had something printed on 3d .
i will let u know when i will get that one if i remember :)
and got a small fan from pc and just add on it (on the case made holes and on it the fan) dont really think u need that ... it was just to check :)

Efriim

@shavecat
I combined our two overclock models... I don't know.
I kept gpu_mem=512, ES crashed at 256. ES was set to use 120 and now to 140.

I use the Switch theme.

I got force turbo to work again, it must have been my configuration because I was experimenting a lot and it sets all the clocks to the max frequencies set.

I don't know about the PSP game halting, if you change buffer mode back and forth in the middle of a game, I guess can lead to bad pages that you need to emulator reset to clear.

Last night, I set up openmsx to use a gamepad, half satisfied that I can play metal gear 2 now.
This morning I tried to get better latency responsiveness in retroarch, for playing rhythm games/super mario world..
Anyway what was I getting to? I don't think I want to watch quake III play for an hour, if you get force_turbo to work, it will set all your clocks to max and that should be a near equivalent test.

Spread32 Download
Here is a tiny spreadsheet program for compiling data.

quicksilver

@Efriim said in Opinion on overclock settings:

Anyway what was I getting to? I don't think I want to watch quake III play for an hour, if you get force_turbo to work, it will set all your clocks to max and that should be a near equivalent test.

Not even close! Your pi runs at max frequency while playing games even with force_turbo off. All force turbo does is set your pis GPU/CPU to max frequency when idle as well by overriding the CPU governor. By your logic you could stress test your pi running Gameboy games. This obviously will not work. Just being set to max frequency is not a proper test if the pi isnt under full load. Proper stress testing is very important and does take time. You don't have to sit and watch it for hours, set up a test and do something else while it's running. In the end you'll have to decide if a stable overclock is something you care about.

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?