@wborn Thanks for your advise - I have now pinned the java engine to the big cores. Still using knx V1 for now. Let’s see what happens during the next 24 hrs.
Thanks for your help
Stefan
@wborn Thanks for your advise - I have now pinned the java engine to the big cores. Still using knx V1 for now. Let’s see what happens during the next 24 hrs.
Thanks for your help
Stefan
@wborn Running stable so far. Looks good. Pinning the java engine helped.
I wait another couple of days, then I plan to go back to knx V2
Thanks!
Stefan
I am running again on Ubuntu 18.04 LTS with OH 2.3 and knx V2.
I have pinned the java engine to the big cores.
Looks good and stable. I think we can close this case.
I am disappointed though about the poor HW, but that’s a different story.
That’s very good news @boxerfahrer!
There should at least have been a software fix for the default Java VM that’s part of the ODROID Ubuntu distribution. E.g. this CPU pinning approach or maybe compiling it with fewer optimizations as is suggested in the ODROID forum thread. A generic fix in the Linux kernel might be even better!
Hi
I tried to follow these instructions, but got a warning about not having “Service lacks both ExecStart= and ExecStop= setting. Refusing.”
Can you shed any light on this?
(I’m not a programmer or coder, so I’m really out of my comfort zone)
Any assistance would be welcomed.
Cheers,
Stuart
cpuset.service - Setup CPU groups
Loaded: error (Reason: Invalid argument)
Active: inactive (dead)
Aug 18 10:25:05 ODroid systemd[1]: [/etc/systemd/system/cpuset.service:10] Failed to parse service type, ignoring: oneshot ExecStart=/bin/true
Aug 18 10:25:05 ODroid systemd[1]: cpuset.service: Service lacks both ExecStart= and ExecStop= setting. Refusing.
Aug 18 10:25:05 ODroid systemd[1]: cpuset.service: Cannot add dependency job, ignoring: Unit cpuset.service is not loaded properly: Invalid argument
@MDAR
I’ll reply here as you sent me a PM, that way others can find the info as well. I do not have an ARM with big little cores so I can not help, other than to pass on some links I came across…
https://forum.odroid.com/viewtopic.php?f=93&t=29008&p=229954&hilit=zulu#p229954
User posted that they followed the guide in the Feb 2017 Odroid Mag (I think it is page 12 and this link will take you there)
https://magazine.odroid.com/wp-content/uploads/ODROID-Magazine-201702.pdf#page=12
The forum linked above is a conversation between the editor of the mag and an openhab user. Thankfully I found this info whilst trying to choose which ARM board to use, so I purchased the Odroid C2 instead and have a rock solid little setup now that has been running for over a week.
https://magazine.odroid.com/wp-content/uploads/ODROID-Magazine-201702.pdf#page=12 1
Perhaps the magic scheduler is the root cause here?
The official 3.10 kernel comes with a “magic” scheduler from Samsung which knows the processor’s
true power,
Hi all
I’ve finally found the time and head space to try to pin the Java processes to the big core…
I followed the instructions to the letter and now I can see that the taskset -p result has changed from ff to f0 so I have to assume that it has worked.
taskset -pc <PID>
Is a little easier to understand
I’ll keep an eye on it and report back …
Thanks for all the assistance and guidance
Hi
I think I’ve found a much easier way to pin tasks to a particular range of CPU cores.
As part of following the various instructions, I saw a reference to the taskset utility.
http://manpages.ubuntu.com/manpages/cosmic/en/man1/taskset.1.html
The taskset command is part of the util-linux package and is available from
https://www.kernel.org/pub/linux/utils/util-linux/apt-get install util-linux
By entering the following commands, I could adjust which CPU cores any process and it’s children were using
pidof java
Then enter the returned PID into…
taskset -pca {PID}
For example
taskset -pca 1024
To set which CPU cores are to be used is simply a matter of adding the -c set string.
So to set the process (and it’s children) to cores 0 to 3 would be
taskset -pca 0-3 1024
Not being a programmer, I needed to experiment a little, but eventually discovered that if I added the following line into /usr/lib/systemd/system/openhab2.service
After the ExecStart line which starts Karaf
ExecStartPost=/usr/bin/taskset -pca 4-7 $MAINPID
OpenHab2’s Java process is pinned to whichever CPU cores I want, in this case 4-7 (which I think are the Big cores).
Assigning to 4-7 returns the same f0 from taskset -p {PID} as the more long winded instructions, so should I assume these are the Big cores?
For those of the same programming skills as I, please don’t forget to run the following commands
systemctl daemon-reload
systemctl restart openhab2
Dear all,
I had the same problem and found this thread. Digging further I stumbled over a different way to pin the process to cores 4 to 7:
Just add the line
CPUAffinity=4,5,6,7
to the
[Services]
section of your openhab2.service file. Systemd will then take care of pinning the process to the named cores.
After restarting openhab using
systemctl daemon-reload
systemctl restart openhab2
you can check CPU binding in the /proc
fileystem.
ps auxww | grep java
gives you all java processes on your system together with their pid (second column). In my case it is 6616
currently.
With
grep -i cpu /proc/6616/status
(replace 6616 by the PID you found for your java process) you should see the following output:
Cpus_allowed: f0
Cpus_allowed_list: 4-7
A process without CPU affinity would show
Cpus_allowed: ff
Cpus_allowed_list: 0-7
instead, so if you still see that output something went wrong.
The process runs stable for more than 12 hours now, while it crashed every couple of minutes before, so CPU-pinning really brings a great improvement.
Hope that helps
Wolfgang
Short notice: updating to openhab 2.4 seems to overwrite the openhab2.service file, so afterwards you will have to add the setting again.
Yours
Wolfgang
Thanks for the info and the update. Now you have had it running for a while, would you recommend the big.little range of arm processors with Openhab now you have used them for a while?
Recently Odroid released details of a new model, the N2 which also uses the big.little cores and it can be ordered with 4gb of ram which sounds great…
https://forum.odroid.com/viewtopic.php?f=176&t=33781
Considering one of those if they get good Kodi support, or if not the bigger H2 x86 based that could then double as a NAS and OH server in the one box using snapraid.
I see the odroid as a very good fit for openHAB, as it is powerful enough to run openHAB, influx (in my case) and grafana also for setups with a lot of items (about 300 in my config). I also have nextcloud running on the same box without any problem or computing power shortage. And you get all of this for less then 10W energy consumption (including the SSD drive). So I totally recommend that config.
I’m now deploying the ODroid C2, which seems to be little more stable than the UX4.
The C2 only has big cores so doesn’t need any pinning.
My theory was that if I’m only running openHAB2 in the UX4 and having to pin it to the big cores, I might as well just use a machine that only has big cores.
I haven’t moved my home (deliberately overloaded) openHAB2 configuration to a C2, it’s a task I’m not looking forward to.
The client’s I’ve given C2 units to haven’t reported any issues.
FYI, I sell Velbus hardware and give customers an SBC to keep the system time updated.
It’s then totally their choice as to which UI they run.
So far everyone seems very happy with openHAB2.
Here’s a small improvement to keep openhab from wiping out your changes in the openhab2.service file.
run
sudo systemctl edit openhab2.service
and put the modifications in that file. If you get an error about ‘edit’ command not beeing known. Then create the file /etc/systemd/system/openhab.service.d/override.conf yourself and reload daemon and restart. If you run systemctl status you see that it now uses a drop-in.
BTW: If you’re already on OH3 change openhab2.service to openhab.service but the rest stays the same. Unfortunately a change of the service file name (which normally doesn’t happen) will not prevent you from loosing the drop-in file as well.