Raspberry Pi Forums

A small, affordable computer with free resources to help people learn, make things, and have fun
https://www.raspberrypi.org/forums/

Common firmware testing

https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=267576

Page 3 of 3

Re: Common firmware testing

Posted: Thu Apr 16, 2020 11:51 am
by dom
Common firmware is now on the master branch of rpi-update. next branch is still being used for 5.4 kernel testing.

Re: Common firmware testing

Posted: Fri Apr 17, 2020 11:46 am
by Realizator
We noticed a dramatic performance drop while H264 decode/encode with the new firmware on RPi 4.
For example, on old firmware we were able to do a real-time transcoding: we receive H264 1280x720@30 FPS with 7 Mbit bitrate stream over network, decode it and encode to 3 Mbit (aim is to decrease a bitrate, and changhe high h264 profile to base h264 profile for viewing this stream in a browser). There is no camera access functions here.
On the previous firmware:
1. We were able to do it in a real time without any issues. The same FPS, extremely low latency.
2. With the new firmware we can encode 640x480 output from 1280x720 input (instead of 1280x720 we need) without frames drop in output stream. With 1280x720 output we got a low FPS, and video latency increases over time. Any ideas?

p.s. we use C code and MMAL, this solution works for us for a last couple of years. Decoder output is connected to the encoder input in MMAL.

Re: Common firmware testing

Posted: Fri Apr 17, 2020 11:56 am
by dom
@Realizator
When running your test what is the output of

Code: Select all

vcgencmd measure_clock core
vcgencmd measure_clock h264
with the good and bad firmwares (run a few times each).

Does enabling the performance governor help?

Code: Select all

echo performance | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Re: Common firmware testing

Posted: Fri Apr 17, 2020 1:38 pm
by Realizator
With the new firmware:

Code: Select all

root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=200008304
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=199995120
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=200008304
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=199995120
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=200008304
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=199995120

Code: Select all

root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=499987808
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=500000992
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=499987808
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=500000992
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=499987808
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=500000992
As for the performance governor:

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
For the tests on old firmware we need some time to roll back several updates we did. After that I can share our results.

Last notice: while transcode we also did a decode to show video on HDMI. On the latest firmware, if we turn off decode and HDMI showing, transcode performance returns to normal. But with the previous firmware decode and HDMI showing not affects on this.

Re: Common firmware testing

Posted: Fri Apr 17, 2020 1:59 pm
by Realizator
...and the tests for the old firmware:

Code: Select all

root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=200008304
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=199995120
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=199995120
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=199995120
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=199995120
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=200008304
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=199995120
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=199995120
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=200008304
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=199995120
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=199995120

Code: Select all

root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=500000992
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=500000992
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=500000992
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=500000992
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=500000992
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=500000992
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=500000992
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=500000992
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=500000992
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=500000992
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=500000992

Re: Common firmware testing

Posted: Fri Apr 17, 2020 2:54 pm
by dom
Realizator wrote: ↑
Fri Apr 17, 2020 11:46 am
 We noticed a dramatic performance drop while H264 decode/encode with the new firmware on RPi 4.
Hmmm. Common firmware only affects Pi0-3. Pi4 firmware was unchanged by this switch.
Can you identify the exact rpi-update that causes the regression?

To start with can you switch to master branch of rpi-update? That contains common firmware (now) but won't have the 5.4 kernel of "next" branch. Is that good or bad?

Re: Common firmware testing

Posted: Fri Apr 17, 2020 3:13 pm
by no3rpi
Realizator wrote: With the new firmware:

Code: Select all

root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=200008304
root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=199995120
....

Code: Select all

root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=499987808
root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=500000992
...
.....
Excuse my intervention but your h264 freq look low; is your RPI on stand by when you run the command ?
On my LibreElec it looks like this with performance governor:

Code: Select all

LibreELEC:~ # vcgencmd measure_clock h264
frequency(28)=500000992
LibreELEC:~ # vcgencmd measure_clock core
frequency(1)=500000992

Re: Common firmware testing

Posted: Fri Apr 17, 2020 3:18 pm
by Realizator
We have a stable behavior with this:

Code: Select all

root@cosmostreamer:/# vcgencmd version
Sep 24 2019 17:36:31
Copyright (c) 2012 Broadcom
version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (clean) (release) (start_x)

root@cosmostreamer:/boot# uname -a
Linux cosmostreamer 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux
and described unstable with this:

Code: Select all

root@raspberrypi:~# vcgencmd version
Apr 15 2020 11:42:37
Copyright (c) 2012 Broadcom
version 1103ec16df2571274600b377411499bf5aed6d0d (clean) (release) (start_x)

root@raspberrypi:~# uname -a
Linux raspberrypi 4.19.114-v7+ #1303 SMP Tue Apr 7 15:44:16 BST 2020 armv7l GNU/Linux

Re: Common firmware testing

Posted: Fri Apr 17, 2020 3:32 pm
by Realizator
no3rpi wrote: ↑
Fri Apr 17, 2020 3:13 pm
 Excuse my intervention but your h264 freq look low; is your RPI on stand by when you run the command ?
This system works without GUI as embedded device, and main load is h264 encode/decode. May be this is a reason of this low core frequency.

Re: Common firmware testing

Posted: Fri Apr 17, 2020 3:37 pm
by no3rpi
Realizator wrote: This system works without GUI as embedded device, and main load is h264 encode/decode. May be this is a reason of this low core frequency.
Still on your old test firmware, h264 freq it is high compared with test on new firmware.

Re: Common firmware testing

Posted: Fri Apr 17, 2020 3:42 pm
by Realizator
no3rpi wrote: ↑
Fri Apr 17, 2020 3:37 pm
Realizator wrote: This system works without GUI as embedded device, and main load is h264 encode/decode. May be this is a reason of this low core frequency.
Still on your old test firmware, h264 freq it is high compared with test on new firmware.
Hmmm... You a right. The frequencies are vice-versa for h264 and core...
With old firmware we have 500 MHz for H264 and 200 MHz for Core. With new we have 200 MHz for H264 and 500 MHz for Core.

Re: Common firmware testing

Posted: Fri Apr 17, 2020 3:58 pm
by Realizator
Ok, we dig this out and try to set frequency manually, using config.txt.
"h264_freq=500" does not change anything.
But with "gpu_freq=600" we have:

Code: Select all

root@cosmostreamer:~# vcgencmd measure_clock h264
frequency(28)=240007328

root@cosmostreamer:~# vcgencmd measure_clock core
frequency(1)=500000992
We see that H264 freq now 240 MHz instead of 200 MHz.

And everything works fine now! That is all transcode + decode for HDMI works as on older firmware.
We don't like to override defaults for GPU frequency on production. @dom, waiting for your ideas and suggestion on this.

Re: Common firmware testing

Posted: Fri Apr 17, 2020 4:06 pm
by no3rpi
Maybe you have also other parameters set that are not default and under-clock your rpi; try this script and see all:

Code: Select all

#!/bin/bash
# This bash script outputs the status of your Pi and checks whether you are being throttled for undervoltage and gives you your temperature
# Article and discussion at https://jamesachambers.com/measure-raspberry-pi-undervoltage-true-clock-speeds/
# Author James A Chambers 6-6-17

# Output current configuration
vcgencmd get_config int | egrep "(arm|core|gpu|sdram)_freq|over_volt"

# Measure clock speeds
for src in arm core h264 isp v3d; do echo -e "$src:\t$(vcgencmd measure_clock $src)"; done

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

# Measure Temperature
vcgencmd measure_temp

# See if we are being throttled
throttled="$(vcgencmd get_throttled)"
echo -e "$throttled"
if [[ $throttled != "throttled=0x0" ]]; then
    echo "WARNING:  You are being throttled.  This is likely because you are undervoltage.  Please connect your PI to a better power supply!"
fi

Re: Common firmware testing

Posted: Fri Apr 17, 2020 5:01 pm
by Realizator
no3rpi wrote: ↑
Fri Apr 17, 2020 4:06 pm
 Maybe you have also other parameters set that are not default and under-clock your rpi; try this script and see all:
no3rpi, thank you for your advice!
You see, we always got for old and new firmware:

Code: Select all

root@cosmostreamer:~# vcgencmd get_throttled
throttled=0x50005
Tested with several power sources, including 5v 6A. But we use power over pins (not by USB), as USB is used for the special external camera (camera is working as a USB host). If we power Pi4 over USB, we have throttled=0x0 (for both old and new firmware). AFAIK power control works for USB power only.
That is, current status:
- on previous firmware we have 500 MHz on h264, despite on power over GPIO pins
- on a new firmware we have 240 MHz maximum, only by setting "gpu_freq=600" in confog.txt. And just 200 MHz by default.

Re: Common firmware testing

Posted: Fri Apr 17, 2020 5:12 pm
by dickon
Are you using both 5V pins (and two grounds) as power inputs, or just one? I'm fairly sure -- as in, I'm sure I've seen something to this effect around here before -- that one is not quite enough, especially if the conductors are thin. You get enough of a voltage drop to cause trouble.

No idea why that would trigger on a later firmware, though.

Re: Common firmware testing

Posted: Fri Apr 17, 2020 5:17 pm
by Realizator
dickon wrote: ↑
Fri Apr 17, 2020 5:12 pm
 Are you using both 5V pins (and two grounds) as power inputs, or just one? I'm fairly sure -- as in, I'm sure I've seen something to this effect around here before -- that one is not quite enough, especially if the conductors are thin. You get enough of a voltage drop to cause trouble.

No idea why that would trigger on a later firmware, though.
I understand this, and will try to use a couple of pins. But we use exactly the same hardware and power cable connections, just changing a micro SD card. And got high h264 frequency in the first case, and low in the second...

Re: Common firmware testing

Posted: Fri Apr 17, 2020 5:23 pm
by dickon
It's an odd one, certainly. Might be worth -- carefully -- measuring the voltage on the running boards under both firmware revisions to see if there's a difference, and if it really is undervolting.
All times are UTC
Page 3 of 3
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/