Yellow/Gold warning square in the top right hand corner

RetroResolution

@Riverstorm Hi, thanks, glad you found the guide useful.

Re: avoid_warnings

As defined in the thread:

avoid_warnings=1 removes the warning overlay.
avoid_warnings=2 additionally allows turbo when low-voltage is present.

I believe that when they speak of 'turbo' they are referring to the overclock setting with this name in the raspi-config menu (you won't see this on a Pi 3 as currently overclocking isn't officially supported).

That being the case, avoid_warnings=2 allows overclocking to still work even if the Pi detects that not enough voltage is available (by default an undervolt would switch off overclocking)

Hope this helps!

Riverstorm

Thanks Retro, yes that helps, how does the governor tie into all of it? The governor dictates when the overclock settings kick into play depending on the governor setting such as "on-demand", "performance", etc. or how does that part work?

RetroResolution

@Riverstorm hi,

I don't recall the exact specifics, but my understanding is that the governor is a kernel-level programme that monitors system voltage and temperature, and cpu load, and will dynamically adjust CPU speed.

On a pi 3, for example, the CPU is clocked by default at 1200mhz, but when not under load the governor decreases this to 600mhz. This lower value can be set in the /boot/config.txt file, along with a host of other values (voltages and clock speeds for all manner of components in the Broadcom SoC).

Whether or not overclocking has been applied, under load the CPU will run at its maximum speed (1200mhz default, or whatever value you specify if overclocked), unless the specified maximum temperature is reached (80 degrees Celsius default), at which point the governor attempts to maintain the fastest CPU speed it can whilst keeping the temperature below the threshold.

In practice, once thermal regulation forces the CPU to underclock, it won't go back to full speed until the CPU load has dropped for a while - I don't know the exact algorithm, but I've seen the CPU underclock to 600mhz when running a 45 minute compilation of FFmpeg, for example, and stay at this low speed even when the CPU load and temp have dropped - perhaps the process which was running when the governor scales back the CPU speed has to finish before 'normal' operation resumes?

N.b. I think the governor controls speeds of other components besides the cpu, but haven't got my notes to hand to confirm.

Happy to be corrected on the above, as a lot of this info comes from my observations, rather than direct knowledge of the hardware and kernel itself.

RetroResolution

@RetroResolution forgot to say, on a pi 3 especially, I definitely would never switch off the governor (think this is is the 'performance' setting - e.g. the mode where the CPU is always running at whatever clock speed has been specified). Burning out the CPU by running it hard looks like a real possibility - it quickly hits 80 degrees Celsius during stress tests and multi-core compile/make operations. Without the governor controlling things, the temperature would keep climbing.

RetroResolution

@RetroResolution and more... I tend to specify dual-core operation for long-running CPU intensive operations, such as source code compilation and video transcoding with ffmpeg - on my system the temp settles around 75 degrees Celsius, with two cores running 100% - no point in trying three or four cores as the thermal regulation simply underclocks aggressively, leading to most of the operation running at 600mhz. It's a balancing act...

Riverstorm

@RetroResolution said in Yellow/Gold warning square in the top right hand corner:

on my system the temp settles around 75 degrees Celsius, with two cores running 100% - no point in trying three or four cores as the thermal regulation simply underclocks aggressively, leading to most of the operation running at 600mhz. It's a balancing act...

That's an interesting thought that it might need to complete it's current task before resuming normal speed after a downclock.

That's some good information I appreciate you sharing. I don't quite understand what you mean. Why not utilize more cores when the governor is at its default "on-demand" setting? If you keep it under the governor threshold (95% I think?) then it doesn't need to run tubro/overclock and would run cooler?

I think @Buzz setup a great optimization. It's a setting to switch to "performance" only while the game is running then back to it's previous setting on game exit. A fabulous setting as it seems emulators (even intensive ones or I should say taxing ones like the N64) constantly downclock to 600 Mhz (using
Watch through Putty) when set to "on-demand" vs "performance". Love this setting. :)

RetroResolution

@Riverstorm in all my tests and real world experience, with the governor set at default behaviour (I'm not overriding the 'performance' setting at all), when a process runs the CPU hard the clock speed increases. This inevitably increases the temperature. Whilst the governor does attempt to balance the CPU speed to go as fast as possible whilst staying below the temperature threshold, for whatever reason once it really has to back off the speed to drop the temperature it doesn't behave quite as expected.

Even when the temperature and cpu load fall back, whilst the original process keeps running the system never seems to get back to even the default 1200mhz; I've often seen it drop to 600mhz and stay there long after the temperature drops below 80 degrees. Once the original process ends, normal, expected, operation resumes. This is why I specify dual-core operation when I can.

For what it's worth, all the RetroPie emulators I use only utilise a single core, which even at a sustained 100% won't get the chip hot enough for thermal regulation to occur (VCS, Megadrive (Picodrive), SNES, Spectrum (Fuse), 32X (Picodrive), PlayStation, N64, Atari ST, Atari 800)

Thus, for emulator usage I'm not specifying how many cores as they only use one regardless - they just weren't written with parallelism in mind; believe me, multicore coding is hard even in languages and IDEs with built in support, such as C#, let alone C and assembler.

RetroResolution

@Riverstorm I also monitor emulator performance via PuTTy - generally the CPU runs at full overclock; exceptions are usually if a game is at a menu screen (most emulators), or on the PlayStation, if fmv is being played. I have a stack of CPU load and temp readings somewhere from tests I made!

Are you using Watch to getting a fluid reading of CPU speed, rather than a single snapshot? E.g.

watch -n 1 vcgencmd measure_clock arm

Riverstorm

@RetroResolution
We might be saying the same thing in some parts.

with the governor set at default behaviour

I think it's default is "on-demand" and I thought I read that turbo/overclock starts only when the CPU is a sustained a 95% load or more for a specified amount of time.

Once the original process ends, normal, expected, operation resumes. This is why I specify dual-core operation when I can.

That's still my question, if you you can multi-thread and you're using 2 cores, why not 3 and 4 to distribute the load even more. My thought being if you keep the cores under 95% they don't need to overclock which in turn runs cooler as overclock is dictated by the governor settings and those parameters?

Thus, for emulator usage I'm not specifying how many cores as they only use one regardless

I don't think you get a choice here? Most of the emulators in RetroPie are coded single core anyway so it don't matter what you specify? I can get my chip quite hot just running RetroPie. I hit 70C easy with no heatsink or fans so I am dang close to tripping thermal protection. Actually the fan cools it more than the heatsink.

Are you using Watch to getting a fluid reading of CPU speed, rather than a single snapshot? E.g.
watch -n 1 vcgencmd measure_clock arm

Just a snapshot with this script using Watch. But even with just a snapshot and the CPU is set to default "on-demand" I still see it bounce like a yo-yo in N64 so it's being dynamic for sure.

#!/bin/bash
cpuSpeed0=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)
cpuSpeed1=$(($cpuSpeed0/1000))

cpuTemp0=$(cat /sys/class/thermal/thermal_zone0/temp)
cpuTemp1=$(($cpuTemp0/1000))
cpuTemp2=$(($cpuTemp0/100))
cpuTempM=$(($cpuTemp2 % $cpuTemp1))

gpuTemp0=$(/opt/vc/bin/vcgencmd measure_temp)
gpuTemp0=${gpuTemp0//\'/°}
gpuTemp0=${gpuTemp0//temp=/}

echo
echo CPU Speed: $cpuSpeed1" MHz"
echo
echo CPU Temp: $cpuTemp1"."$cpuTempM"°C"
echo GPU Temp: $gpuTemp0

RetroResolution

@Riverstorm totally agree with you, the RetroPie emulators are mostly (maybe all?) single core.

I wasn't aware of BuZz's'performance' mode optimisation in RetroPie, so I'll definitely be checking that out.

The multicore setting I use for compilation, ffmpeg transcoding etc is purely a result of me trying to find a way around the system aggressively underclocking when it gets too hot. I don't know why the governor doesn't 'recover' until the process ends, it's just my observation and my workaround. For RetroPie usage it's never an issue anyway.

I wrote a series of guides on overclocking, stress testing, CPU, memory, and SD card testing, for pi 2, and applied it all to the pi 3 as soon as it came out. I'm just relating what I've seen - as I say, I'd love to know more, but it have no idea who wrote the governor in the o/s kernel.

Part 1: Overclocking the Raspberry Pi
http://retroresolution.com/2015/11/21/overclocking-and-stability-testing-the-raspberry-pi-2-part-1

Part 2: Stress testing the CPU with mprime
http://retroresolution.com/2015/11/27/overclocking-and-stability-testing-the-raspberry-pi-2-part-2-mprime

Part 3: Stress testing the RAM with Memtester
http://retroresolution.com/2015/11/28/overclocking-and-stability-testing-the-raspberry-pi-2-part-3-ram-check-with-memtester

Part 4: Stress testing the SD card storage with the Stability Test Script
http://retroresolution.com/2015/11/29/overclocking-and-stability-testing-the-raspberry-pi-2-part-4-sd-storage-testing/

Overclocking the Raspberry Pi 3: Thermal Limits and Optimising for Single vs Multicore Performance
http://retroresolution.com/2016/03/24/overclocking-the-raspberry-pi-3-pragmatism-and-optimising-for-single-vs-multicore-performance/

RetroResolution

@RetroResolution re: distributing the load across all cores, your observation is logical, but from thermal standpoint it doesn't help, as on the Pi the cores are all part of the same chip - in contrast to machines with multiple, separate physical cpus.

In fact, there's overhead in marshalling data etc across threads, which would cause more work, thus more heat (albeit a negligible amount).

Riverstorm

@RetroResolution said in [Yellow/Gold warning square in the top right hand corner]

I appreciate the links as it's nice to learn more. I will read through them here some time this week.

totally agree with you, the RetroPie emulators are mostly (maybe all?) single core.

I think so but Buzz or another core guy could confirm it.

I wasn't aware of BuZz's'performance' mode optimisation in RetroPie, so I'll definitely be checking that out.

Yeah check here. It's in the Configuration Editor settings. That feature is great. For me it's the coolest thing since sliced bread. ;)

https://github.com/retropie/retropie-setup/wiki/runcommand

RetroResolution

@Riverstorm cool, thanks for the link - I hope it means I can eke out a little more from the n64 emulator!

RetroResolution

@RetroResolution really must get on with writing up the guide on enabling the retroarch real-time audio-video recording feature - been an enjoyable chat though, thanks.

Riverstorm

@RetroResolution said in Yellow/Gold warning square in the top right hand corner:

@RetroResolution really must get on with writing up the guide on enabling the retroarch real-time audio-video recording feature - been an enjoyable chat though, thanks.

I would hope to know more of how the governor works at some point. I have some new information to ponder. I had no idea it tries to maintain the fastest possible speed while staying under the thermal threshold once turbo kicks in and the thermal threshold is tripped. I always thought it just downclocked to 600 but being dynamic makes more sense and much better utilization. Thanks Retro, looking forward to the new guide. I appreciate you chatting and sharing the information. I learned something today and it's a Monday! ;)