Opinion on overclock settings
-
@shavecat judging by your recent posts you have had a lot of instability lately. Force_turbo simply disables the CPU governor and makes your pi operate at full speed even when idle. If this is freezing your pi then your overclock is unstable. If you aren't careful you are going to corrupt your SD card or it may be happening already.
@Efriim with current firmware the sdram_schmo setting is automatically changed when you overclock sdram over 500mhz. So really isn't any reason to use that setting anymore unless you really have a good reason.
Over_voltage and over_voltage_sdram are separate settings.
-
@Efriim yes if you actively monitor the CPU freq you will see that there are slight fluctuations. V3d, isp and h264 freq might return a 0 value if they aren't being used (for emulation isp and h264 aren't needed. Though h264 might be needed if you are also running Kodi)
-
@shavecat what model Pi are u running these settings on and do you have any heat sinks and fans?
-
@Dwarfboysim
pi B+ all the settings are on no freeze for my side.
and yep i have this heatstink with fans on it and a big fan on it for any way ...
dont get heat more then 44/45 deg'.
https://www.ebay.com/itm/Double-Cooling-Fans-with-Heatsink-Cooler-For-Raspberry-pi3-B-Plus-pi3-B/192690471027?hash=item2cdd3f4073:m:mSY14x0VBuJkEiMWH_iVkZQ&frcectupt=true
@quicksilver
and yes i u right i did try lots of time with the overcook until i got it right
sdram_schmo thanks :) -
This post is deleted! -
Checking my /var/log/kern.log I have a few warnings
WARN::dwc_otg_hcd_init:1046: FIQ DMA bounce buffers: virt = 0xaf914000 dma = 0xef914000 len=9024 WARN::hcd_init_fiq:459: FIQ on core 1 at 0x805ea470 WARN::hcd_init_fiq:460: FIQ ASM at 0x805ea7d8 length 36 WARN::hcd_init_fiq:486: MPHI regs_base at 0xf0006000 snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned. random: 7 urandom warning(s) missed due to ratelimitingI don't know what any of this means.
I think the FIQ is USB, it could be my case, or the memory card.
I don't know what ratelimiting is.
The bcm2835 is probably normal. -
@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?
-
@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 :) -
@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. -
@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.
-
@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.
-
@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.
-
@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?
-
@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.
-
@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?
-
@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.
-
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=512I 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)"; donesdram_c: volt=1.2500V
sdram_i: volt=1.2500V
sdram_p: volt=1.2250VThese 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=2Will 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=3Returns
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 greaterRespectively
Setting thecore_freq=595a 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.
-
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 isMy 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.
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 furtherFurther 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
***additionalMy 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.
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.