hello, i built a reciever using an orange pi zero with 256mb of RAM. the board mounts an Alwinner H2+ quad core cpu. I noticed that the process started by dump1090-fa insanely overloads the CPU causing the temperatures to grow up (Orange pi zero have some thermal problems, and this continuos overload is not good!). How i can solve this problem? i attach some photos of the process and dump-1090 settings:
Itās not tied to one core, but the 68% CPU number is expressed as a percentage of a single CPU, not as a percentage of the whole system.
The summary lines at the very top show the overall system use (75% idle)
If you want to show process CPU use as a percentage of the whole system, turn off āIrix modeā (capital I in top)
Or you can see a per-CPU breakdown by hitting ā1ā
I happen to run exactly the same Orange PI Zeros with my trackers and I do not observe such a high CPU load.
Whats the temperature that your OPI is running on low and high load?
My OPIs are normally in the 30-70 Celsius rangeā¦
In addition to the first post I noticed similar behavior of a dump1090-fa on Opi PC (H3; 1GB RAM; Linux OrangePI 3.4.39 #1 SMP PREEMPT Mon Oct 12 12:02:29 CEST 2015 armv7l armv7l armv7l GNU/Linux;Ubuntu 15.04 Vivid Vervet; Piaware 3.5.0 add-on, dump1090-fa included)
Until yesterday it worked fine except that CPU load was around 40%-48% (with temp 55-60degC) so it seemed normally but little odd because on another OpiOne (H3 512MB RAM) CPU load is 20-28%, and on other RPi (1GB RAM) is also 20-28% all 3 are getting similar count of planes so there is no significant difference in environment.
Yesterday there was a drop in planes and no planes on Skyviewat all. Piaware logged loss of connection to dump1090-fa. Checking the working processes revealed that dump109-fa was overloading CPU reaching 100-104% the CPU with temp respectively reached 75-76deg C. After stopping piaware and restarting dump1090-fa interactively it worked for a while with CPU load reaching 50-60% and plane/flight data scrolled on the screen. Then stopped with āsegmentation faultā message probably due to high temp reaching fast the limit of CPU and/or RAM.
Does anybody have idea why dump1090-fa on this particular installation loads CPU twice than on others?
Seems the reason would have been loose usb connection to the dongle. Today it is no longer possible to start dump1090-fa. It gives following: ------------- rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000) Found Rafael Micro R820T tuner rtlsdr: tuner gain set to 49.6 dB cb transfer status: 1, cancelingā¦ cb transfer status: 1, cancelingā¦ Mon Jun 4 15:41:58 2018 EEST No data received from the SDR for a long time, it may have wedged ------------------- CPU hitting 100% and temp reached 78degC in 30 sec.
All is working as before but question still stays
Why this dump1090-fa here is loading CPU twice than on other setups ~~ 40% vs 20%
Any idea where to dig?
So in addition to above posts and after month of close eye on behavior of both setups and some experiments it is almost clear that Opi PC (H3; 1GB RAM; with Ubuntu 15.04 Vivid was overloaded and overheated because of Ubuntu 15.04 with combination with debian packaged dump1090-fa. Its CPU load was around 40%-48% (with temp 55-60degC). Iām speaking for this particular version of Ubuntu for OpiPC. I never checked with other versions.
Second setup with OpiOne (H3 512MB RAM) runs Gentoo linux where piaware package plus dump1090 were compiled native from source then configured and made to work as deb package. Its CPU load never reached 30% and temp kept bellow 55 degC when it was put in place of above described OpiPC even with modeac enabled (which adds several percents to CPU load.
These are preliminary conclusions, I will continue to gather data and will share results
Start experimenting. Setup is Opi PC (H3; 1GB RAM Gentoo linux Kernel 4.13.0-rc4
Today noticed following.
SD card is with U-boot 2016.05 so I decided to install most recent U-boot. Got one patched for OpiPC ver 2018.03-rc2. All went well but after reboot I noticed that CPU load jumped to 60% so I reverted to 2016.05 version.
Here is grep from dump1090 log:
ā¦
CPU load: 28.3%
CPU load: 28.3%
CPU load: 28.4%
CPU load: 28.7%
CPU load: 27.5%
CPU load: 27.5%
CPU load: 27.2%
CPU load: 27.4%
CPU load: 27.2%
CPU load: 27.1%
CPU load: 27.3%
CPU load: 0.0% >reboot with U-boot 2018.03-rc2 CPU load: 60.4% CPU load: 60.4% CPU load: 60.3% CPU load: 59.6% CPU load: 60.2%
CPU load: 26.0% >back with old U-boot 2016.05
CPU load: 26.2%
CPU load: 26.2%
CPU load: 26.0%
CPU load: 25.8%
CPU load: 25.9%
It is not clear for me why U-boot had such influence on CPU load, as it is executing only on boot and after that Linux takes over. One explanation which comes to me could be that it is something related to initializing CPU frequencies settings on boot.
I noticed that with top. One dump1090 instance with 60%-65% load. Tend to think that is because of u-boot. Compared .config files (diff-ed it) used in compilation of both u-boots and difference is in frequencies settings of DRAM and CPU. Hypothesis is that U-boot initialize hardware with not quite correct values and then transfer it to Linux and step down. So linux kernel has to work with what u-boot handed to it which in turn reflects in CPU load.
May be Iām wrong but this is one explanation.
Now Iām going to compile and test with several u-boot versions to see the difference. All the rest will be intact - hardware and soft (piaware, dump, kernel etc) only u-boot wil be replaced.
