Red Brick Image 1.12 - Open HAB 2 is extremely slow - timeouts

[peter_tau]

Hi,

 

I recently flashed the new red brick image 1.12 and started the red brick. After activating Open HAB via Brick Viewer, I noticed that Open HAB was starting very slowly. It took several minutes until the system was up and running. It also took quite a time to run through the initial setup of Open HAB 2.3.0. I installed a working configuration of items/rules/sitemap of a particular Tinkerforge setup moved from another site that also runs Open HAB 2.3.0. So I knew that this configuration is all right. However, Open HAB is such slow that the sitemap did not show any values.

 

After a reboot of the red brick and a restart of the separate Tinkerforge hardware, the result was better: The Tinkerforge hardware was initialized from the red brick, I could watch how the LCD content was painted one after another, but nevertheless it is still very slow.

 

Does anybody else have these issues with a fresh install of Image 1.12? Do you know any counter-measures to speed up?

 

I realized that the brickd consumes permanently 30% CPU time, while another red brick based on a much earlier image has a brickd at around 12% as the strongest process.

 

Best regards,

Peter

[borg]

With RED Brick image version 1.10 we updated the Linux kernel as well as OpenHAB to the newest version.

 

Unfortunately the scheduling in the Linux kernel got less efficient for our single core processor (that is what you see with the 30% cpu time taken by brickd) and at the same time the new OpenHAB version is slower...

 

That probably explains why everything is a bit slower, however it should work in principle and the site-map should show up etc.

 

With the new image we also introduced support for the cpu-scaling governor. By default it is configured as "ondemand", which means that the cpu is scaled down to 432 MHz and only increased to the full 1GHz if necessary.

 

You can change it to always use the full 1GHz with

sudo cpufreq-set -g performance

 

Does that help for your use case?

[peter_tau]

Thank you very much for your comment. Clearly, switching between 432 MHz and 1 GHz would increase processor speed by more than a factor of 2.

 

However, the described issue does not concern an optimization problem where a factor 2 gives quite a boost. When I talk about of slowdown, you might assume a required factor of much more than 10, probably factor 100, to come into acceptable regions. The speed of the system is such slow that OpenHAB 2 is definitely not running, even with a simple configuration of four sensors displaying their measurement values on an LCD (Weatherstation).

 

At present, I would like to know whether anybody else succeeded in running OpenHAB 2.2.0/2.3.0 on a Red Brick taking Image 1.11 and 1.12 as a basis? For testing purposes, I installed the items/rule/sitemap example from the Weatherstation kit. The system is far too slow that it works.

 

It took me a while to re-test the setup with cpufreq-set -g performance as the Ethernet PoE Master Extension connected to the red brick lost its configuration after shutting down the red brick last time. The Brick Viewer showed the red brick, but no interface at all. I needed to shutdown the red brick again and redo it. After another start, the Ethernet PoE Master Extension was visible again. However, I needed to manually connect again. Very strange.

 

I speeded up the CPU with the given command. Even with a factor 2, everything is much too slow... Does not work at all.

 

Originally, I operated the red brick with power obtained from the Ethernet PoE Master Extension. I realized that the Ethernet PoE Master Extension got extremely hot. Right now, I ensure that no power comes across the Ethernet cable and I power the red brick directly. Could the excessive heat be a source of these problems?

 

At present, I would be glad to find out whether red brick images 1.11/1.12 with Open HAB can be considered as broken or whether the behavior of my red brick is unexpected?

 

Thank you very much for your support.

[borg]

The governor will automatically scale between 432 MHz and 1 GHz depending on the load, so it should run with 1 GHz even if the governor is configured as "on demand". The idea was that maybe the scaling doesn't work properly with OpenHAB.

 

I will put it on the todo list to test it again with the newest RED Brick image and OpenHAB version to see if it is so slow for us too. But it will be a few days until i can work on it.

[peter_tau]

THank you very much for your support.

[iia]

Hi @peter_tau,

 

I did a simple test with 1.12 image on the RED Brick. The hardware setup looked like:

 

                Humidity Bricklet

                        |

                        |

                        |

                        v

|RED Brick|==>|Master Brick|<---Temperature Bricklet

                        ^

                        |

                        |

                        |

              Ambient Light Bricklet

 

Items file:

Number TF_Temperature   "Temperature [%.1f °C]" { tinkerforge="uid=zFd" }
Number TF_Humidity      "Humidity [%.1f %%RH]"  { tinkerforge="uid=qTQ" }
Number TF_AmbientLight  "Luminance [%.0f lx]"   { tinkerforge="uid=uKN" }

 

Sitemap file:

sitemap test label="Test: OpenHAB 2 @ RED Brick"
{
    Frame {
        Text item=TF_Temperature
        Text item=TF_Humidity
        Text item=TF_AmbientLight
    }
}

 

With this setup I got the following timing:

 

• The setup showing up on Brickv after a reboot: 1.5 minutes
   
  
• The sitemap being available and functional since reboot: 9 - 10 minutes
  

 

Once the sitemap is up and running then everything goes quite smoothly without much lag and is definitely usable.

 

OpenHAB 2 is known to be slow, very resource hungry and not suitable for resource constrained systems. Some discussions on this topic:

 

1. https://github.com/openhab/openhabian/issues/171

2. https://github.com/openhab/openhab-distro/issues/10

 

When OpenHAB is run for the very first time it will take even longer to finish the setup. But subsequent startups are supposed to take less time than that.

 

Now about if you can do something to improve the situation. You can try to specify only the UIs and the setup you need in the config file:

 

/etc/openhab2/services/addons.cfg

 

For example only enable Basic UI. Reboot the system after changing this config file.

 

Can you provide me with your .items, .rules, .sitemaps files and also the three OpenHAB2 log files located at:

 

/var/log/openhab2 ?

 

Cheers.

[theo]

👍

[peter_tau]

Dear @iia,

 

I used the configuratio example from @theo which you will find at:

https://github.com/theoweiss/openhab-tinkerforge-configuration-examples/tree/master/weatherstation

 

However, the weather station was not neither directly connected to the red brick nor via USB, but over a WiFi connection established by a WiFi Master Extension connected to the weather station.

 

In my setup, after the first run of OpenHAB 2 which took about as long as described in your post, the system was extremely slow so that I could see second after second how the LCD was updated.

 

After a reboot, the system was still quite slow but at least usable with the weather station. However, this situation did not remain for long. After some hours, the red brick was still responding but the weather station was stuck.

 

Due to these severe performance issues, I already moved OpenHAB 2 to a more powerful hardware. Now I am experiencing long-term performance problems (single rules stop working) which seem to be related to threads that are not ended correctly. But this is an issue for a different forum.

 

Best regards,

Peter