Core 250 or 450MHz?

[Ergonomicmike]

Am playing w/ v0.5b6 on the couch. This probably isn't an issue, since it seems to work fine. But the Android app RasPi Check shows the core running at 250MHz, whereas Chris had a line in code setting it to 450. https://github.com/cyoung/stratux/commit/5aca8adea2b4f8c6fe7baf312088bafa152a73be Thought I would report it for completeness & will close this as soon as someone says it's not an issue.

[skypuppy]

Shouldn't it be 900?

On 01/26/2016 09:07 PM, Ergonomicmike wrote:

Am playing w/ v05b6 on the couch This probably isn't an issue, since it seems to work fine But the Android app RasPi Check shows the core running at 250MHz, whereas Chris had a line in code setting it to 450 https://githubcom/cyoung/stratux/commit/5aca8adea2b4f8c6fe7baf312088bafa152a73be Thought I would report it for completeness & will close this as soon as someone says it's not an issue

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/222.

[Ergonomicmike]

I've doing some research in the meantime. Core sets the freq of the GPU and also L2 cache. (UPDATE: That might not be true for the Pi 2. See comment below.) Should be a multiplier of the arm freq (900), so 450 sounds like the right target. 250 is the default. So either Raspi Check is reporting incorrectly or the setting of 450 in /boot/config.txt isn't taking. Am going to SSH in and start hacking.

[Ergonomicmike]

Okay, I added the line gpu_core=450 to /boot/config.txt and now RasPi Check shows a Core Freq of 450. (See http://elinux.org/RPi_config.txt - if I understand it correctly, gpu_freq is for the P 2.) If this is a commit that needs to be made, that exercise is left to the reader.

[Ergonomicmike]

More from the http://elinux.org/RPi_config.txt page:

gpu_freq Sets core_freq, h264_freq, isp_freq, v3d_freq together. Default 250

core_freq Frequency of GPU processor core in MHz. For models prior to the Pi2, this has an impact on ARM performance since it drives the L2 cache. The ARM on the Pi2 has a separate L2 cache. Default 250

That's confusing to me. Says that gpu_freq sets core, but then has a separate core_freq setting for the GPU? (UPDATE: I guess that the gpu freq is a universal setting - sets 3 in 1.)

And here it says that in the Pi 2, the core_freq does not control L2. (UPDATE: Whereas other sites, notably the official Pi blog, indicates that it does. I'm going to set both core_freq and gpu_freq to the same number.)

BTW, according to the built in raspi-config thingie, for the Medium Overclocking option of 900, 250, 450, the over volt should be "2."

We are running that clock (or 900, 450, 450). But I didn't see anything about overvolting in config.txt. If Stratux is not doing it, I bring it up in case there are reports of instability. (Didn't Chris used to have the CPU at 600MHz?)

[Ergonomicmike]

Curiouser and curiouser. Well, in the end, it might be that RaspPi Check is mis-reporting the "core" frequency. (The definition which seems to have changed with the Pi 2.) As a final sanity check, I used raspi-config to set an overclock of 1000 MHz arm, 500 core and 500 sdram. Then I looked at what it set in /config.txt. It had it as Chris had it. It didn't add a gpu_core switch. (FWIW, I'm going to drop down to 700, 350 and 350 to see what happens.)

[Ergonomicmike]

Huh -

root@raspberrypi:/boot# vcgencmd measure_clock core
frequency(1)=250000000

I notice that the OEM config.txt says that the standard clock freq is 700 MHz, whereas it was upped to 900 MHz with the Pi 2. That makes me wonder if we're using a pi build for an older system. So perhaps core_freq isn't being set?

UPDATE: I even set core_freq_min=400 (per https://www.raspberrypi.org/documentation/configuration/config-txt.md) but vcgencmd still reports a frequency of only 250 MHz.

[Ergonomicmike]

I'm closing this, 'cause it's not really an issue from an operational standpoint. (More like me obsessing.)

First, documentation on the Pi 2 (official and unofficial) about these settings is inconsistent. Things changed with the CPU used in the Pi 2, but it appears that the documentation has not caught up. And/or the version of the OS that Stratux uses does not comport with said documentation. (E.g. core_freq_min doesn't work; the OS says the default arm freq is 700 MHz, whereas the Pi 2's CPU has a designed clock of 900. )

Second, and perhaps part of first, the OS uses the "ondemand" governor. So trying to measure clock rates with a command line utility is problematic. I caught the clock at max once. But more typically, the clocks are loafing at idle. (At least they idle on my couch receiving 1090. I'll add to test CPU freq in flight on my Test Card for my next flight test with Stratux.) The ondemand doesn't put the core freq at half the arm freq at idle (e.g. 300/600). Apparently the 1:2 synching isn't important at idle.

Third, the settings in config.txt set maximum values. As best I can tell from the inconsistent documentation on the web, Chris has the correct values. So not an issue. Closed.

[cyoung]

The intention was to disable the "ondemand" governor/downclocking and have everything run at a stable clock rate. Haven't turned back to look at this yet, but if this is not the case I'd count it as an issue.

[Ergonomicmike]

Then from what I read, you will have to add force_turbo=1.

In addition to bypassing the governor, it sets a bit somewhere in the Pi and voids your warranty. (Even tho you might set max freqs equal to or less than normal clock.) There's a way around that (using raspi-config), but it sets overvoltage to 2, which I don't think is needed for the CPU in the Pi 2..

Frankly, I don't think you're going to want to bypass the governor, because, from http://elinux.org/RPiconfig#force_turbo_mode:

"force_turbo=1 disables dynamic clocking, so all frequencies and voltages stay high."

It wouldn't be so bad if it just locked the frequencies. But it moves voltages up too.

More voltage = more heat + less power saving.

I haven't measured the frequencies in flight, but I expect that, when needed, the Stratux runs balls out. (That's the nature of ondemand.)

Is anybody having a problem with the governor? If not, then I suggest leaving it as is. At least for now.

If yes, then an alternative to enabling turbo mode would be to use the built-in userspace governor (requires a recompile of the kernel) where you set your own triggers for what works best for Stratux.

[Ergonomicmike]

Or (duh on my part) you could change the governor to "Performance" governor. Runs balls out all the time. (I don't know what it does to voltage. Again, the new CPU shouldn't need overvolt to run at stock freqs.)

[Ergonomicmike]

If you want to test with Performance without recompiling to see what happens with overvolt,

echo performance > cpu0/cpufreq/scaling_governor

(From http://raspberrypi.stackexchange.com/questions/9034/how-to-change-the-default-governor)

And then

vcgencmd measure_volts core

[Ergonomicmike]

I tried it. (BTW, have to be at /sys/devices/system/cpu to change the governor.) Voltage goes to 1.3125, up from 1.2v. On my desk, CPU temp goes up 3 to 4 degrees F.

(BTW, the KMASHI didn't have enough power to drive the Stratux on Performance with two SDRs. I had to change to a 2A wall wart for this test.)

[cyoung]

I think for one of the next releases we'll set it to performance. Higher power consumption is the price we may have to pay for deterministic results.

[cyoung]

Would you like to test how "performance" works for you for each use?

Edit /etc/rc.local and add (before the exit 0 line):

 echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

[cyoung]

You can also use "powersave" instead of "performance" and it will not change depending on CPU demand. "powersave" should be good enough for stratux to run normally.

[Ergonomicmike]

Just saw the commit to v0.6r1. Was going to report that it's still on "ondemand." But you got it already.

[Ergonomicmike]

Hmmm... I copied the latest commit to init.d and then shutdown/ rebooted. Powersave is still not taking. Although I can manually change the governor to powersave with the echo command once running. The guy in this link says that the default governor has to be changed by recompiling the kernel. (I don't know if he's right. It's the only thing I can find in a cursory search.) http://raspberrypi.stackexchange.com/questions/9034/how-to-change-the-default-governor. Is the change working for you?

[cyoung]

The powersave change wasn't included in v0.6r1. It needs some testing before putting it on an image.

There is another init script somewhere that is changing it, will track it down.

[Ergonomicmike]

[UPDATE: NM. See next.] I found a workaround using a utility called cpufrequtils. Hacked my way thru it. Wrote about it in the reddit forum. Now seeing 600/250 and 1.2v. (I don't see a way to measure sdram clock.)

[Ergonomicmike]

Found the best solution. The echo line goes in the /etc/rc.local file

https://putokaz.wordpress.com/2015/03/01/overclocking-raspberry-pi-set-scaling_governor-on-raspbian-boot/

I reimaged, made the change, shutdown rebooted and confirmed it works.

[cyoung]

You might be on to something, perhaps this isn't a driver issue with the WiFi dongle. High network traffic happens roughly when high CPU load happens, so the CPU governor could kick up and cause a power issue.

[cyoung]

And the WiFi dongle was usually the first to die in a marginal power situation, too.

[Ergonomicmike]

Since I know how to repeatably cause a Wi-Fi lockup with my Nook HD+, I'll put that test back on my Test Card for the next flight to see if the governor and/or a new Anker battery fixed it. (Unfortunately, probably can't fly for a week.)