CPU wb-mqtt-serial wb-rules

Уважаемая команда WB.Нужно ваше экспертное мнение

Насколько типчна утилизация для WB8 load average: 1.72, 1.74, 1.79

при grep -c ‘“slave_id”’ /etc/wb-mqtt-serial.conf
39

top

top - 15:03:58 up 23:44, 1 user, load average: 1.72, 1.74, 1.79
Tasks: 160 total, 1 running, 159 sleeping, 0 stopped, 0 zombie
%Cpu(s): 15.7 us, 11.2 sy, 0.0 ni, 68.5 id, 0.0 wa, 3.9 hi, 0.8 si, 0.0 st
MiB Mem : 3931.2 total, 2128.9 free, 506.9 used, 1295.4 buff/cache
MiB Swap: 256.0 total, 256.0 free, 0.0 used. 3277.6 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND

772504 root 20 0 850240 28248 14464 S 32.1 0.7 11:29.87 wb-mqtt-serial
2046 root 20 0 2655312 46432 19456 S 26.5 1.2 375:25.04 wb-rules
1991 root 20 0 460580 18796 8576 S 12.3 0.5 179:37.31 main
1856 mosquit+ 20 0 21168 14460 6400 S 5.6 0.4 60:51.33 mosquitto
4504 root 20 0 189136 32616 8832 S 4.3 0.8 71:46.31 python3
4516 www-data 20 0 210060 15468 6016 S 2.3 0.4 8:16.48 nginx
779750 root 20 0 0 0 0 I 2.0 0.0 0:07.77 kworker/u8:3-events_unbound
73 root rt 0 0 0 0 S 1.3 0.0 17:00.72 sugov:0
507 root 20 0 256208 16640 13312 S 1.3 0.4 18:44.87 NetworkManager
1588 root 20 0 34108 18048 10496 S 1.3 0.4 18:36.44 python3
770710 root 20 0 0 0 0 I 1.3 0.0 0:19.95 kworker/u8:0-events_unbound
315 message+ 20 0 8400 4096 3072 S 1.0 0.1 15:25.79 dbus-daemon

Добрый день.

Треть одного ядра для wb-mqtt-serial - вполне допустимо.

Тут еще (больше) зависит от количества (частоты) публикаций.
То есть - постоянную нагрузку можно получить или опросом шин по классическому modbus или если используется быстрый - то нагрузка будет минимальной если событий не происходит. Если они есть - то от их количества.

Быстрый modbus возможен на скоростях отличных от 115200? Может и на 9600 работать? Есть ли способ проверить или устройства от wirenboard работают на быстром по -умолчанию и управление этим параметром недоступно пользователю?.Вопрос связан с тем что где-то в параметрах шаблона устройства есть чтение по быстрому а где-то в порядке очереди, например UPS v3

И еще момент, пытаясь снизить частоту поступления данных, например для датчика шума, это правильный путь перейти на увеличиный интервал опроса параметра шиной? Или тут иной смысл?

Вполне. То есть на любой с учетом описанного

Доступно, но редактированием шаблона.

Да, в той же статье описано:

Драйвер будет все равно утилизировать шину на 100%. Очередь запросов динамическая и регистры (остальные) просто будут опрашиваться чаще.

Да, смысл - чтобы регистр опросился не реже чем указано.