Raspberry Pi 2 100% CPU

[rogerfar]

I had an old version running until now on my RPi 1 with symbollength=7 and had about 30% CPU, now I upgraded to a RPi2 (clean distro of Raspbian), but with the same symbollength it is maxing out at 100%, with a load of 1.2.

It doesn't seem to miss packets but it's slowing down other processes.

[bemasher]

Could you provide the output for the command: rtlamr -version

[rogerfar]

Build Date: 03-08-2016
Commit: v0.7.1

It's this release:
https://github.com/bemasher/rtlamr/releases/download/v0.7.1/rtlamr_linux_arm.tar.gz

[bemasher]

I've made a few commits that significantly improve performance. Something still doesn't sound right about the difference in performance between your RPi and RPi2. Could you try running this build as of 17b0016 and let me know how it performs?

rtlamr_linux_arm.tar.gz

[rogerfar]

It's similar, high CPU (100% on a core) but the load is slightly lower.

I connected my old Pi, but that version doesn't even have the version flag yet, the readme of that release is broken but the date is 2014-08-30.

That version is maxing out around 15% with a .25 load.

[bemasher]

I'm unable to reproduce this on my RPi2, running the latest version shows approximately 10% CPU usage with 5 minute load average of 0.13 using -symbollength=7.

On v0.5.0 it shows approximately 20% CPU usage and 5 minute average load of 0.22 with the same flags.

Which version of rtl_tcp are you running? Did you build it from source or are you using the package available via raspbian?

Can you provide performance values with no -symbollength flag?

[rogerfar]

I'm running the latest version, compiled from git according these instructions: http://sdr.osmocom.org/trac/wiki/rtl-sdr

When I run without symbollength CPU is 100% and load climbs to about 1 too, but I am barely getting any messages, maybe 2 in 5 mins where I get about 50 with the older version.

[bemasher]

It's possible the issue is related to cross compiling the binaries. I've attached a binary that was built on my RPi2 with go1.6.2 armv6l that has the desired performance, let me know if this performs any better.

rtlamr.tar.gz

[rogerfar]

Yes much better! Looking at a 10% CPU with a 0.3 load.

[bemasher]

Perfect. Unless I can figure out exactly what is broken while cross-compiling for ARM I'll just have to build the ARM binaries on my RPi2 for release. I'll be creating a new release in the near future that will take care of this and incorporate some new performance improvements.

Thanks for opening the issue, I probably wouldn't have ever caught it otherwise.

[bemasher]

Looks like cross-compiling for ARM statically links the binary while compiling on the RPi2 itself, it dynamically links with interpreter /lib/ld-linux-armhf.so.3. Not sure how to fix this other than building ARM releases on the RPi2.

[abishur]

even using the rtlamr.tar.gz included here on my Pi 2 I'm seeing 81.4% CPU usage by rtlamr. Is there anything I can do to decrease that load?

[bemasher]

That sounds like an appropriate level of CPU usage for rtlamr. The only thing you can really do to reduce load is to use shorter symbol lengths with the -symbollength flag, which will lower the sample rate. Just keep in mind that shortening the symbol length will reduce receivable bandwidth and will result in fewer messages being received. Below is a set of tables describing valid symbol lengths. The default symbol length is 72 samples per chip.

Symbol Length	Sample Rate
7	229.376 kHz
8	262.144 kHz
9	294.912 kHz

Symbol Length	Sample Rate	Symbol Length	Sample Rate
28	917.504 kHz	39	1.277952 MHz
29	950.272 kHz	40	1.310720 MHz
30	983.040 kHz	41	1.343488 MHz
31	1.015808 MHz	42	1.376256 MHz
32	1.048576 MHz	43	1.409024 MHz
33	1.081344 MHz	44	1.441792 MHz
34	1.114112 MHz	45	1.474560 MHz
35	1.146880 MHz	46	1.507328 MHz
36	1.179648 MHz	47	1.540096 MHz
37	1.212416 MHz	48	1.572864 MHz
38	1.245184 MHz

Symbol Length	Sample Rate	Symbol Length	Sample Rate
49	1.605632 MHz	74	2.424832 MHz
50	1.638400 MHz	75	2.457600 MHz
51	1.671168 MHz	76	2.490368 MHz
52	1.703936 MHz	77	2.523136 MHz
53	1.736704 MHz	78	2.555904 MHz
54	1.769472 MHz	79	2.588672 MHz
55	1.802240 MHz	80	2.621440 MHz
56	1.835008 MHz	81	2.654208 MHz
57	1.867776 MHz	82	2.686976 MHz
58	1.900544 MHz	83	2.719744 MHz
59	1.933312 MHz	84	2.752512 MHz
60	1.966080 MHz	85	2.785280 MHz
61	1.998848 MHz	86	2.818048 MHz
62	2.031616 MHz	87	2.850816 MHz
63	2.064384 MHz	88	2.883584 MHz
64	2.097152 MHz	89	2.916352 MHz
65	2.129920 MHz	90	2.949120 MHz
66	2.162688 MHz	91	2.981888 MHz
67	2.195456 MHz	92	3.014656 MHz
68	2.228224 MHz	93	3.047424 MHz
69	2.260992 MHz	94	3.080192 MHz
70	2.293760 MHz	95	3.112960 MHz
71	2.326528 MHz	96	3.145728 MHz
72	2.359296 MHz	97	3.178496 MHz
73	2.392064 MHz

[abishur]

Oh I see, so if I only cared about my one meter (which according to meters.csv only transmits between 910 and 920 Mhz) then I could do a symbol length of 7 and set my centerfreq to 915M and should easily get the data I want?

[bemasher]

Maybe, you'd likely miss a lot of messages since the meter hops between all of the channels it transmits on and your radio will usually only hear messages occurring within the bandwidth it is listening for. A symbol length of 7 has an extremely narrow bandwidth, I would try 7, 8 and 9 to see which is most reliable.

[abishur]

Thanks, apologies for hijacking a previous question with what ended up being an unrelated issue!