Please correct me if i am not thinking straight. A CPU load of ~15% is not that high is it? Mine is running about twice that since the “update”. Also, with a Pi 3 B+, isn’t temperature more of an issue? If I read some documentation correctly, hitting above 60.0 C causes a “soft limit”, which in turn reduces the frequency from 1.4 mHz to 1.2 mHz until the temp drops below 60 C. Thanks!
–Mark
As long as ADS-B tracking is the only thing the RPi has to do…
However i would also be concerned if my CPU utilization for a single thread jumps from below 20 to over 50% in usage
Sure:
There appears to have been more than one ‘event’ w.r.t. updates and performance as far as the radio CPU utilization goes:
any ideas on the February bump? I see similar ‘jumps’ in the Pi CPU usage as well. I’m running on a Pi Zero W, so any reduction in load is much appreciated. Trying a rebuild of the librtlsdr to see how that impacts things.
Workaround is committed to the dev branch (Use a bounce buffer for rtlsdr on ARM to work around zero-copy problems. · flightaware/dump1090@653ad61 · GitHub); this will be in 3.8.2 once it’s released.
Unfortunately I couldn’t find a practical way to work out whether zerocopy is in use or not and only conditionally enable the workaround, so all ARM builds will pay the (small) extra CPU cost to do an extra copy, even if it’s not necessary.
(Please do not blindly use the dev branch unless you know what you’re getting into; it is a moving target at the moment)
What did you change on your install at the time?
It’s perhaps a change in CPU frequency control, given that it looks like everything “increased” proportionally (which could be explained by the CPU being underclocked)
It was probably a set of updates for the OS (I tend to update at least every other week)
Its a stock install of Buster on a Pi Zero W. No over/under clocking, no special settings. Unless something changed in how the base OS is dealing with the CPU, which I’ve not gone out to investigate.
Result of a rebuilt rtl-sdr library:
This is what I was suggesting happened.
I’m still not sure what the grave concern is - I realize some are outdoors in heat, etc, but here is my Pi4 rig and how it runs - zero issues for months on end. There is a lot left in the tank on most of these boards…had nobody looked at their graph, none would be the wiser (including me). There are already several methods posted here now how to fix if it’s something anyone is losing sleep over.
And the RockPi4 running Dump1090/Airspy, Dump978 and GPS:
I agree if the device is doing the ADS-B tracking only. Then it should not matter. But there are others which use the Raspberry also for other things, this can be impacted.
My device is also outdoor, doing tracking only. With the 5.x kernel the temperature is approx 5°C higher due to the system load
Just did a test after i downgraded the kernel to the last 4.xx version
Now my device is using 5.4.40-v7+ and the CPU load for dump1090-fa is still in the normal level from before.
Maybe a higher version causes that increase in CPU load
Some people run the pi zero, if you have maybe more than one feed client and enough planes, this problem can push you over the edge.
You’re right, running an airspy is much more taxing on an RPi and it also works.
But why have extra CPU usage? 
Not sure why you flagged me, Foxhunter. I’m still on 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 with dump1090-fa running around 13% CPU. I restored from backup before others pinned down the exact revision to roll back to.
For my setup, the Pi is mounted in our garage and it’s summer here and warm. I wanted to reduce the heat load. Others may not have that consideration and can just wait out a fix. I didn’t feel that waiting was right for me.
I flagged you to make you aware that it is also working until kernel 5.40 where you stated i am on 4.19.97.
Not very surprising but i installed today a brand new Raspberry 4B
After running all existing upgrades to Raspberry OS i started the install of all feeders and dump1090-fa
Same issue as almost all: CPU load twice as high as it should be.
Moved down to Kernel 5.4.40 and CPU back to normal.
Just for the documentation…
Try another update.
A new kernel came out today.
Linux xXxX 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l GNU/Linux
To date, I haven’t seen a commit in the stable linux branch that has anything to do with zero_copy since the last change 6 months ago (5.4.42) through kernel 5.9.rc3. At least for our realm and the Raspberry firmware push is about 5-6 months lagging from bleeding-edge stable. In short, don’t expect a kernel bump to do anything unless there is a libusb update that gets pushed in (haven’t seen anything on that side either…yet). OBJ sidestepped the issue in the FA dev branch with an extra oldskool malloc/memcopy that will more than likely be part of the next FA release. Buffers suck.
Both of my devices were upgraded, both with the same high CPU load as result. So i rolled back to the last working version.
Since I’m not (yet) driven to figuring out how to compile/link my own updated FA version with the workaround development code by @obj, I have two general questions:
Cheers,
Andreas / VA2WBT
I mailed the ARM engineer responsible for the kernel patch but I haven’t heard back. I might see if the raspberry pi kernel folks are interested.
Not sure at this stage.
