Higher CPU utilization from 27% to 65% between 6a04c45 and cce47b6 on RPi4B+

[dwrobel]

In response to #8 (comment) I updated the package in fedora from 6a04c45 to cce47b6. I'm running rtl-wmbus alongside with wmbusmeters on RPi4B+ and noticed a substantial increase in CPU utilization between those two revisions:

6a04c4548245c4f6adaad6348ee4d2deef825d63 27%
cce47b67b7d84ca7ef685c7e0fbd853114f3f605 65%

Here is the CPU utilization during git bisect:

d603a3b4ce34f68068a305a423384a23280a7411 68%
6d92d1b3f150e0b609f7505e9135495fabb274fc 29%
8ac790dc16eb20ed301873c018e54623a44b4a5e 75%
a517da71d12e2d548e93117f828356f4fe49bc5a 29%
8bec4a2b0860d0adad3183367fdf1be99e017c65 47%

Here is the culprit (8bec4a2):

$ git bisect bad
8bec4a2b0860d0adad3183367fdf1be99e017c65 is the first bad commit
commit 8bec4a2b0860d0adad3183367fdf1be99e017c65
Author: Xael South <xael.south@yandex.com>
Date:   Tue Feb 2 17:29:08 2021 +0000

    C1 mode improvements; S1 mode implemented

 README.md                                          |   8 +
 ...bp_iir_cheb1_400kHz_90kHz_98kHz_102kHz_110kHz.m |  29 ----
 filter/lp_fir_butter_800kHz_100kHz_10kHz.m         |  15 --
 rtl_wmbus.c                                        | 169 ++++++++++++++++-----
 t1_c1_packet_decoder.h                             | 152 +++++++++---------
 5 files changed, 209 insertions(+), 164 deletions(-)
 delete mode 100644 filter/bp_iir_cheb1_400kHz_90kHz_98kHz_102kHz_110kHz.m
 delete mode 100644 filter/lp_fir_butter_800kHz_100kHz_10kHz.m

For the record the git bisect log:

$ git bisect log
git bisect start
# bad: [cce47b67b7d84ca7ef685c7e0fbd853114f3f605] Support MinGW and Win
git bisect bad cce47b67b7d84ca7ef685c7e0fbd853114f3f605
# good: [6a04c4548245c4f6adaad6348ee4d2deef825d63] Mode C1 datagram type B is supported now
git bisect good 6a04c4548245c4f6adaad6348ee4d2deef825d63
# bad: [d603a3b4ce34f68068a305a423384a23280a7411] Add information about column meanings.
git bisect bad d603a3b4ce34f68068a305a423384a23280a7411
# good: [6d92d1b3f150e0b609f7505e9135495fabb274fc] rx_sdr
git bisect good 6d92d1b3f150e0b609f7505e9135495fabb274fc
# bad: [8ac790dc16eb20ed301873c018e54623a44b4a5e] C1 receiver with better filtering
git bisect bad 8ac790dc16eb20ed301873c018e54623a44b4a5e
# good: [a517da71d12e2d548e93117f828356f4fe49bc5a] C1 mode improvements; S1 mode implemented
git bisect good a517da71d12e2d548e93117f828356f4fe49bc5a
# bad: [8bec4a2b0860d0adad3183367fdf1be99e017c65] C1 mode improvements; S1 mode implemented
git bisect bad 8bec4a2b0860d0adad3183367fdf1be99e017c65
# first bad commit: [8bec4a2b0860d0adad3183367fdf1be99e017c65] C1 mode improvements; S1 mode implemented

Is this increase in CPU utilization fully expected? If so, please close this issue, otherwise maybe it would be possible to reduce the CPU usage.

FYI, I've used the old version for quite a long time and it worked flawlessly for me, so maybe it's possible to add some command line option which will reduce the number of computations and still keep the filtering quality on the satisfactory level with the old CPU utilization?

[xaelsouth]

Hello Damian, many thanks to you - as a tormented Subversion user now I know what git bisect is and for what it is good. :-) To your question about performance: 1) the FIR filter for the T1/C1 mode is now a little bit longer resulting in slightly higher CPU utilization (older FIR filter was incorrectly designed regarding the stop band frequency - it's mentioned in the README). Here is nothing what I can do for better performance. 2) i have implemented S1 mode that effectively doubles the CPU utilization. Here I could add an option to switch S1 off and an another option to switch T1/C1 modes off. 3) the "run length method", which is running in parallel to the old time 2 method, is unfortunately not for free, but shows (at least for me) reduced CPU utilization. What _you_ could do here:     a) to switch the run length method off by adding "-r 0" to the command line     b) or to switch the time 2 method off by adding "-t 0" to the command line     c) or add "-a" to the command line for using inaccurate atan version - you should test that a little bit carefully.     d) you can freely combine a) and c) or b) and c).         I would definitely try with b) and c) first. If you have problems with receiving datagrams then try with b) only. Let me know if you was successful with that. Xael

[dwrobel]

Thank you for the comprehensive explanation.

ad. 3) Here is the result of my experiments:

3) option	rtl_wmbus option	CPU usage [%]	Comments
a)	-r 0	63	Rejected due to negligible CPU utilization drop
b)	-t 0	57	Unusable due to observed CRC errors
c)	-a	50	Works properly
b) and c)	-a -t 0	40	Unusable due to observed CRC errors

Based on above the only option which works is p. 3) option c) thanks to this the CPU utilization dropped from initial 65% to 50%.

If you think it might be valuable to test anything from other points 1) and 2), please let me know I'm open to your suggestion.

[xaelsouth]

Hello Damian,

thanks for testing. You could go well with the "-a" option if you don't observe any CRC errors or if CRC errors are rare enough.

Anyway, for rtl_wmbus I have implemented a new command line option: use "-p S" to turn S1 mode off (I guess you don't need S1 at all) or use "-p T" to turn T1/C1 mode off . CPU utilization should drop to a half of the original one after that.

[dwrobel]

Great, I'll give it a try.

[anonymous-one]

Was running a year+ old build of wmbusmeters and decided to roll the latest today and noticed my load jump after upgrading everything related... Luckily found this thread and back down we go.

Thanks guys!

[xaelsouth]

Seems not to be a issue as nobody complains anymore ;P