Raspberry Pi 3 B -> RTL_TCP -> Overrun?

[robman501a]

Any idea what this means? I've got Go installed by using sudo apt-get install golang and I've added this export PATH=$PATH:/home/pi/go/bin to the /home/pi/.profile file.

[bemasher]

Huh, that's a new one. I've never seen rtl_tcp return buffer overrun messages like that. What is the output of go version?

It is pretty likely that the go toolchain provided by raspbian's package manager is out of date, there were some significant performance improvements on arm in go around 1.9-1.11. I would recommend installing a binary distribution of the go toolchain for arm:

https://golang.org/dl/ https://golang.org/doc/install

[courtarro]

I'm running into this myself. I'm running rtlamr on an RPi 3B. It's running the latest Raspbian and the go version is go version go1.11.6 linux/arm, installed from the golang-go package. The symptom I'm seeing is that rtlamr is using a relatively low amount of CPU (about 25% spread across all 4 cores), yet it's unable to keep up with the packet stream coming from rtl_tcp on localhost.

Unfortunately I haven't had time to learn any real amount of go yet. Is there a simple profiling debug step I can take to get a sense of what might be causing inefficiencies in the parsing?

I've been using rtl_433 for a number of other monitoring projects, and it barely uses any CPU while supporting a large number of protocols. However, rtlamr does a much better job finding packets over the air that rtl_433 misses with its ERT parser (actually the bursts often aren't detected at all, so they don't even make it to the ERT parsing step). So I'd love to get rtlamr working on these less powerful CPUs.

[bemasher]

See my response in https://github.com/bemasher/rtlamr/issues/130#issuecomment-560185706

If we can't rule out that the old go toolchain as the source of the problem, there's not much more help I can offer. I have been running this setup on an RPi 3B with Arch for a year or so now without issue.

[courtarro]

I found a way to make it work but I ended up changing two variables at once: I upgraded go and quit using -msgtype=all. With the latest go I still have the problem, so I think it's worth investigating, but limiting the msgtype option resolves the issue.

In case it's worth trying to solve the -msgtype=all situation, here's the info: I installed the latest go release from the binaries. The go version is now go version go1.14.2 linux/arm. I don't actually get buffer errors from rtlamr, but instead I get new buffers allocated in rtl_tcp, which I believe means that it's having to hold onto packets that aren't being accepted:

client accepted! localhost 32950
Allocating 15 zero-copy buffers
set freq 912600155
set sample rate 2359296
set gain mode 0
ll+, now 1
ll+, now 2
ll+, now 3
ll-, now 0
ll+, now 1
ll+, now 2
ll+, now 3
ll+, now 4
ll+, now 5
ll+, now 6
ll+, now 7
ll+, now 8
ll+, now 9
ll+, now 10
ll+, now 11
...
ll+, now 496
ll+, now 497
ll+, now 498
ll+, now 499
ll+, now 500
ll+, now 501
ll+, now 502
ll-, now 0
ll+, now 1
ll+, now 2
ll+, now 3
ll+, now 4
ll+, now 5
ll+, now 6
ll+, now 7

...and rtlamr never finds anything. Here's what it looks like in htop:

  1  [|||||||                            16.4%]   Tasks: 33, 19 thr; 2 running
  2  [|||||||                            16.2%]   Load average: 0.85 0.72 0.77 
  3  [|||||||||                          20.1%]   Uptime: 01:09:44
  4  [|||||||                            14.5%]
  Mem[|||||||||||||||||||||||||||||||208M/926M]
  Swp[                               0K/100.0M]

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
 1702 pi         20   0  859M 10540  3460 S 64.5  1.1  1:23.73 rtlamr -format=json
 1704 pi         20   0  859M 10540  3460 S 18.2  1.1  0:10.06 rtlamr -format=json
 1711 pi         20   0  859M 10540  3460 S 15.5  1.1  0:16.51 rtlamr -format=json
 1710 pi         20   0  859M 10540  3460 S 13.4  1.1  0:13.06 rtlamr -format=json
 1705 pi         20   0  859M 10540  3460 S 12.8  1.1  0:14.74 rtlamr -format=json
 1647 pi         20   0  160M  130M  1920 S  6.1 14.1  0:11.02 rtl_tcp
 1703 pi         20   0  859M 10540  3460 R  4.7  1.1  0:06.75 rtlamr -format=json
 1715 pi         20   0  8116  2812  2300 R  2.7  0.3  0:00.39 htop
 1708 pi         20   0  160M  130M  1920 S  2.7 14.1  0:03.31 rtl_tcp
 1679 pi         20   0 12236  3412  2624 S  0.7  0.4  0:00.25 sshd: pi@pts/2
 1713 pi         20   0  859M 10540  3460 S  0.0  1.1  0:07.33 rtlamr -format=json

So there's CPU to spare, but rtlamr is too far behind and fails to find anything.

[bemasher]

-msgtype=all is intended for discovery, it includes the R900 decoder which is quite resource greedy compared with the ERT messages. Your problem was likely that you were using this flag. Once you know what message types you want to listen to, it should be set only to the messages you need to receive.

[bemasher]

No activity, closing.