Witht the new anomalies messages showing on the ADS-B home page, I am seeing a message that my RPi (B+ Model) CPU is running near 100%. Looking at the top command output, I see that Dump1090-Mut and the FA MLAT Client are taking up about 82% of CPU. Below is the top output. Should Dump1090-Mut and the FA MLAT Client be using this much CPU?
This my secondary RPi that has its antenna in the window. My primary RPi is an older B Model that runs regular Dump1090 and no MLAT, with the antenna in the attic. It sees about 300 more aircraft and about 100,000 more positions a day that the secondary B+ Model. The I have been thinking of upgrading the B Model to a spare B+ Model. However, after seeing how much the current B+ Model working with Dump1090-Mul and MLAT on fewer aircraft and positions, I am reluctant to upgrade it.
Thoughts?
Marty
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2564 pi 20 0 22284 13m 1944 R 46.9 3.0 523:54.28 dump1090-mutabi
2805 root 20 0 12748 9872 5556 R 36.0 2.2 290:53.88 fa-mlat-client
2316 root 20 0 45452 2976 2156 S 8.3 0.7 65:24.33 pfclient
2778 root 20 0 18900 8240 4820 R 4.8 1.8 31:15.73 piaware
7038 pi 20 0 4676 2488 2152 R 1.3 0.6 0:00.12 top
3 root 20 0 0 0 0 R 0.6 0.0 4:02.31 ksoftirqd/0
2803 root 20 0 2656 2136 1876 S 0.6 0.5 6:43.78 faup1090
7 root 20 0 0 0 0 S 0.3 0.0 4:10.59 rcu_preempt
6983 root 20 0 0 0 0 S 0.3 0.0 0:01.94 kworker/0:0
7012 pi 20 0 9436 3680 3068 S 0.3 0.8 0:00.11 sshd
The B+ is no faster than the old B, so that won’t help with the overloaded CPU. I don’t know if software speedups are on the way, but I upgraded to the Pi 2 to solve this problem. The Pi 2 is very much faster. It completely fixed this problem.
Yes that sounds about right, especially given your location. In busy US airspace with mostly Mode S only traffic, you are not going to fit much other than dump1090/piaware/mlat on a B/B+.
The mlat client could use some improvement, it doesn’t really need to be taking that much CPU, but there is some heavy lifting involved (it’d need a rewrite into C) and there is a relatively simple workaround (use a Pi 2 or move other stuff off the Pi) so it is a low priority.
All kidding aside, moving off of my B and onto a real machine (even though it’s a VM) has really improved the performance of piaware. I know there are other boards out there and I was actually going to look to see if the Intel Edison types of boards can be adapted for piaware. If I do pick one up to replace one of my Arduinos, I’ll try to get it to work to see if I can find a performance difference. They’re not a whole lot better (if at all) but I wonder if the x86 architecture would be more performance over a ARM.
Yes, the Chicago is a busy area. Looking at the FA statistics for US only users, I am 6th in the US. There is one other user ahead of me here in Chicago and one ahead of me who is just north of here in Madison WI. The other two top 5 US users are on the east coast.
Be aware that sometimes there are problems with VMs (vmware in particular seems to have trouble) where they can silently drop USB traffic. This isn’t a big deal for ADS-B, you just lose a few messages, but it’s disastrous for mlat.
With my MLAT now turned off, I was still getting the Anomalies message that the CPU was near 100%. When I checked the top output, now Dump0190-Mut is using around 75%.
Marty
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2564 pi 20 0 23452 13m 1944 R 74.3 3.0 1378:33 dump1090-mutabi
2316 root 20 0 45452 3220 2156 S 20.1 0.7 210:45.99 pfclient
8302 root 20 0 18900 8292 4920 S 1.6 1.9 17:07.28 piaware
8328 root 20 0 2656 2088 1840 S 1.3 0.5 9:40.36 faup1090
13371 pi 20 0 4676 2472 2136 R 1.0 0.6 0:00.85 top
3 root 20 0 0 0 0 S 0.3 0.0 9:19.33 ksoftirqd/0
7 root 20 0 0 0 0 S 0.3 0.0 10:04.64 rcu_preempt
43 root 20 0 0 0 0 S 0.3 0.0 0:02.83 jbd2/mmcblk0p6-
1747 root 20 0 0 0 0 S 0.3 0.0 3:26.28 RTW_CMD_THREAD
13348 root 20 0 0 0 0 S 0.3 0.0 0:00.36 kworker/0:0
1 root 20 0 2152 1308 1204 S 0.0 0.3 0:07.84 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.06 kthreadd
If this just started to happen, to help trouble shoot the issue, you might try swapping your SD cards between your two RPis to see what happens. Maybe your SD card or maybe even your RPi has a problem and is getting ready to die. Then of course it might be a power supply issue.
Most of the time I’ve seen that it’s because the dongle gain is set too high and dump1090 is spending a lot of time trying to decode loud noise.
Normal CPU use for dump1090-mutability with --oversample --phase-enhance is somewhere around 40-50% of a B/B+
For ADS-B, the tuner AGC is ineffective and basically works like a fixed gain setting of around ~52dB. It does not adjust to the incoming signal level.
Before I splash out on a Cray XC40 Have any of you guys chained a couple of Pis together to share the CPU load? I now have 2 B+ which are on the upper limit of CPU. I don’t think I can get a Pi 2 past the wife !!