The output of the kernel version might be good to know:
uname -a
It’s one process using multiple threads.
The sum of the threads is 126%, the thread with the highest usage (relevant) is at 84%.
The CPU usage on your screenshot seems quite high for the XU4 with those settings, don’t you agree @prog?
Or is it maybe that the governor isn’t going to max frequency?
Linux peup.local **3.10.105-138** #1 SMP PREEMPT Fri Apr 7 12:40:29 UTC 2017 armv7l armv7l armv7l GNU/Linux
Note that only the “little” cores of the big.LITTLE architecture are tickled.
uname -a
Linux odroidxu4 4.14.150-odroidxu4 #2 SMP PREEMPT Mon Oct 28 08:07:45 CET 2019 armv7l GNU/Linux
Thanks
I’m actually not too sure about that, aren’t the little cores the lower numbered ones (that’s how it works on the N2).
Something is going to high usage on core 8, if it’s a big core it would indicate quite a heavy load for those settings.
I’m have no clue why this high CPU usage for those 2 users might be happening, but even i’m at a loss at how i would go about debugging this. (i wouldn’t expect an end-user to be able to debug this is what i’m saying)
I guess you would suggest trying an XU4 image that uses kernel 3.10 considering at least one of them is using 4.14?
The XU4 should be able to cope with -e 6 easily, wouldn’t you say?
What kind of load does that produce for you?
Could you two post a htop screenshot please?
(sudo apt install htop; hash -r; htop)
I’m curious if it’s running on the little or big cores.
But there’s a rule that says “all Linux users are big boys”… 
I’ve been a nix user for as long as I can remember, but when something changes from one version of a program to another with no other changes on my end, it makes it hard to troubleshoot when the only change was the airspy software. Just not sure were to look at what changes you made to “optimize and improve it” broke it with at least two of us running XU4’s.
No worries. You already found the problem. I suspect the kernel you are using is not switching to the big cores when needed. Plus, there could be some clocking problem as well. You can find that once the big cores are used at their nominal speed. When idling, they stay at 600 MHz.
Try this:
sudo taskset -cp 4-7 $(pgrep airspy)
It should make it run on the big cores.
(can be added to the service to automate it, i’ll check back later)
I was just about to try that and I did, it doesn’t seem to be responding to the change in affinity. It keeps running on a .LITTLE
sudo taskset -cp 4-7 $(pgrep airspy)
pid 28265’s current affinity list: 0-7
pid 28265’s new affinity list: 4-7
If I restart the airspy_adsb then it does start on the big. then moves to .LITTLE
If you can run one of the 3.10.* kernels, it would solve many problems.
I am reading that there appears to be an issue with 4.14 and HMP.
I see another problem: All the cores are marked .LITTLE
Forgot that you need to do all the threads with -a, this should work now:
sudo taskset -acp 4-7 $(pgrep airspy)
Oh and please show:
which taskset
I’ve included an affinity control into /etc/default/airspy_adsb
You’ll need to run the install script and reconfigure via the config file.
I’ve knocked it offline for now, by accident 
so I’ll have to manually get to it and fix it back up as SSH isn’t letting me log in now, so I’ll have to bring it into the office and put a monitor and keybord on it.
Thanks wiedehopf, appreciate your suggestions.
:~$ which taskset
/usr/bin/taskset
I first ran sudo taskset -acp 4-7 $(pgrep airspy) - this caused my SSH connection to drop for some reason so rebooted and ran your installation script and edited new config option to “4-7” with -e 3 also set. airspy_adsb now running approx 41% with no dropped samples.
My Xu4 is CPU configured to run minimum 1500 maximum 2000 - performance mode.
Thanks for your assistance. 
I would suggest to open another thread to troubleshot your CPU. It doesn’t do what you think it does.
Anyway it might not be capable anyway of 2GHz:
https://wiki.odroid.com/odroid-n2/application_note/software/set_cpu_freq
In case of A73 1.9GHz, only 80% amount of ODROID-N2 test samples are successful for heavy load tests, and over 70% samples have booting issues with 2.0GHz option.
The option -e 3 is fairly low, hence the low CPU usage.
Ok, i have no clue what the problem with that command is, it worked fine for me.
But it seems to have dropped SSH for the other guy as well.
As Sonic already remarked, now that it’s running stable, crank it up to -e 7 or higher, depending on what you want
(don’t forget to set -w 3 to clean up the bogus stuff)
