logging: intermittent rtlamr-collect timeout about rtlamr-collect HOT 12 CLOSED

from rtlamr-collect.

Which terminal exactly is saying it is timing out? Can you provide logs of both rtl_tcp and rtlamr-collect?

from rtlamr-collect.

I was never able to get the systemd auto-start to work, so I am opening a screen instance, starting a bash script then detaching from the screen instance so I can log out. I pull up the graph and notice missing data points so then I re-login and attach to that running screen instnace and that's where it is giving me golang errors with timeouts. I just reset it yesterday so as soon as it fails again I'll post screenshots. Where are the log files stored?

from rtlamr-collect.

Neither rtlamr nor rtlamr-collect write log outputs to any files by default. The output on the terminal should be the only evidence anything is timing out. If you can copy and paste any logs of that nature to this issue, that'd be helpful.

from rtlamr-collect.

13:40:41.484746 flags.go:107: Environment variable "RTLAMR_FORMAT" overrides flag "format" with "json"
13:40:41.514412 flags.go:107: Environment variable "RTLAMR_MSGTYPE" overrides flag "msgtype" with "idm"
13:40:41.526900 decode.go:43: CenterFreq: 912600155
13:40:41.527209 decode.go:44: SampleRate: 2359296
13:40:41.527335 decode.go:45: DataRate: 32768
13:40:41.527452 decode.go:46: ChipLength: 72
13:40:41.527557 decode.go:47: PreambleSymbols: 32
13:40:41.527680 decode.go:48: PreambleLength: 4608
13:40:41.527792 decode.go:49: PacketSymbols: 736
13:40:41.527922 decode.go:50: PacketLength: 105984
13:40:41.528083 decode.go:51: Preamble: 01010101010101010001011010100011
13:40:41.528194 main.go:94: GainCount: 29
13:40:41.602539 main.go:163: connecting to "user"@"http://localhost:8086"
13:40:41.667911 main.go:127: Preloaded: 0
09:30:22.585928 main.go:235: {"error":"timeout"}

13:20:46.512018 main.go:235: {"error":"timeout"}

00:40:14.877256 main.go:235: {"error":"timeout"}

09:03:44.048526 main.go:235: {"error":"timeout"}

from rtlamr-collect.

from rtlamr-collect.

That timeout is occurring when rtlamr-collect is writing a point batch to influxdb. If I'm reading your log right, you're running rtlamr and influxdb both on the same Pi?

Can you try running influxdb on a different system and write the data to that?

from rtlamr-collect.

Yes Influx and rtlamr-collect are on the same Pi. I'll try influx on my windows file server, it's idle most of the time.

from rtlamr-collect.

I'd like to share how I ended up fixing my issue, while keeping Influx, Graphana, and RTL all on the same raspberry Pi.

At first I was logging any meter I could receive... which was about 100 or so. I filtered it down to just me, and my two immediate neighbors who have a graphana login to monitor their usage as well. That still didn't fix the issue for some reason.

So I decided to just modify the nice settings for the various programs, and have yet to have a timeout issue since. I know this is a band aid, but I'm a lazy S-O-B and it works... so.... just gonna leave it :)

Basically I assigned nice by Program Group so all threads were changed at the same time, and did the following:

Kapacitor Has a nice of 2
Grafana, RTLAMR & RTLAMR Collect, Has a nice of 1
Telegraf Has a Nice of -4
RTL_TCP Has a Nice of -5
Influxd Has a Nice of -10

Since writing to influx seemed to be the issue according to @bemasher I put that as highest priority and the RTL right behind it.

I'm sure Linux aficionados are crawling in their skin.... but I'm a newb, and an idiot... but I got it to work with minimal time invested in researching it :)

from rtlamr-collect.

Well that didn't work... Definitely lasted longer, but still didn't work.
I have another Pi that I use for my 3D printer. CPU utilization even when printing is never more than 20% so I may be able to run InfluxDB on it without any ill effects. Will report back if that works.

from rtlamr-collect.

My guess would be that InfluxDB doesn't play nice with writing to/reading from flash media.

from rtlamr-collect.

from rtlamr-collect.