I do not fully understand the output of htop. I have 4 PID from airspy_adsb and the highest loaded one has ~85% CPU load. But when I check the cores no one is loaded more than 65%. Can one PID run on more than one core?
The cores are averaged over time.
Processes however can change the core that they are running on.
(Or rather they donāt really have a say in the matter, the scheduler can move them around more or less like it wants)
So the PID could have 100% and all the cores are at 25% because itās running equal amounts of time on each of the 4 cores.
But if this is the case the relevant number is the highest loaded core not the CPU load shown for the PID. So 65% load now with few aircraft only. I will let it run for at least a day to see whether I ever get some lost messages.
Not quite. The process canāt run on two cores at once so the 100 % on one process is still limiting.
I ran it for two days now. I get about a dozen of seconds at different times of day where I have entries like this:
Jan 26 18:47:23 piaware airspy_adsb[5330]: /!\ Lost 98304 samples /!\
Interestingly the number 98304 is always the same and I have up to 9 entries like this within the same second. But as my peak message rate is ~850/s I do not really understand the log message. It would take minimum 98304/850 =115 s to add such a huge number. Whatās the difference between a message and a sample?
A sample is on value from the analog to digital converter.
At -m 20 that converter runs at 20 MHz or 20 Megasamples per second (MSPS).
So losing 100 000 samples is rougly equivalent to 1/200th of a second of data that is transferred via USB.
It seems the main thread is the bottle neck and using less network connections is beneficial.
Iāve changed the install script to feed dump1090-fa via a push client and dump1090-fa distributes the data. This has improved my lost samples significantly.
I donāt feel like updating the manual howto right now though as for the piaware sd-card itās a little tricky.
If you run the package addon install i would recommend you remove the -l 30005:beast from your airspy-adsb options and make the net-bo-port option in the dump1090-fa config 30005.
That way dump1090-fa redistributes the messages and load on the main thread of airspy_adsb is reduced. (This problem could likely also be solved by improving the program, but i donāt have the source)
1 Like
Thanks for your useful answer. If this is the case I do not have a relevant problem with lost messages. I loose maybe a second per day due to some threads like logrotate who consume some CPU for fractions of a second. Who cares? For me with a peak message rate of ~850/s I am fine with an old cheap Rpi 3 without overclocking and still can use -m20 20 MHz airspy_adsb frequence.
Well, you will also lose MLAT for probably a minute until it is synchronized again.
Anyway you can try disabling bit packing, this also slightly reduces cpu load on the main thread (bottleneck).
Also bear in mind with the summer on the way the message count will rise and the problem will get worse.
The reconfiguration should help and itās quite easy actually. (Or you can just run my install script and readjust the gain/ sample rate in the config file (that will be overwritten)).
Did you lower the arm_freq to 800 like suggested in the quickstart? Because with -m20 i donāt think that is a good thing and you should rather just run the pi without a case or with a heatsink or fan and just use the default frequency.
Sure? How can I check how high the up-rate of MLAT is?
No. I do not overclock but also I do not āunderclockā. When I read this quickstart I understood that itās supposed to overclock so I left everything default except disabling power saving.
You canāt. I mean you can check your MLAT numbers i guess, but thatās not really a good metric.
Iām also not sure how long the interruption is, could be less than a minute.
Yeah the quickstart is concerned with the pi overheating when permanently at default frequency, it therefore suggests underclocking it. Anyway with a good power supply and some ventilation the default frequency without ondemand frequency control should work just fine.