Description
I’m reading 20 sensors and sending data every hour and encoding them in to a ~337 byte CBOR string so my direct data usage is 8KB/day or 0.25MB/month and my Golioth data is reported at ~14KB/day=0.5MB/month (with logs)
My cellular provider is reporting that my data usage is 6K-8K per session=154KB/day = 4.8MB/month. I’m trying to understand if this ~10x increase in data is normal and if it can be reduced. What is the Golioth overhead for checking firmware revision, syncing 4 DB-State variables, and 3 settings? Is this normal?
2nd issue: The data above is with the modem turned off except for ~40 seconds each hour. If I leave the modem on it shouldn’t be sending anything more than keep-alive packets but my data usage goes through the roof. Instead of 6.4K/hr=4.8MB/month I have a 650K data session every 6 hours which uses 82MB/month.
Is there any explanation why an ‘idle’ modem connection uses 17x the data of a connection that’s turned off except for 1 reading an hour?
Steps to Reproduce
Q1) Compare Golioth reported data to Hologram reported cellular data. Hologram data is 10X Golioth data.
Q2) Compare Hologram reported cellular data with turning the modem off between readings vs. leaving it on. Data with modem on is 17x higher.
Expected Behavior
Q1) Hologram reported usage close to Golioth reported usage. Golioth overhead shouldn’t be 10x.
Q2) Data usage should be only slightly higher if modem is left on between readings.
Actual Behavior
See above.
Impact
Modem-on data usage is hitting my data caps when the modem is left on, but I can’t talk to the device between readings if I turn it off.
Environment
Custom NRF9160 design running SDK v21.
Logs and Console Output
2025-12-26 20:35:02
2025-12-26 20:34:23
00:00:39
6.28 KB
8944501611213459166
350457793160464 AT&T Mobility LTE
2025-12-26 20:29:05
2025-12-26 20:28:23
00:00:42
6.80 KB
8944501611213459166
350457793160464 AT&T Mobility LTE
2025-12-26 20:26:38
2025-12-26 20:25:42
00:00:56
10.88 KB
8944501611213459166
350457793160464 AT&T Mobility LTE
2025-12-26 20:25:42
2025-12-26 19:57:02
00:28:40
44.65 KB
8944501611213459166
350457793160464 AT&T Mobility LTE
2025-12-26 19:57:02
2025-12-26 12:57:16
06:59:46
649.47 KB
8944501611213459166
350457793160464 AT&T Mobility LTE
2025-12-26 12:57:16
2025-12-26 05:57:29
06:59:47
649.32 KB
Attempts to Resolve
Q1) I haven’t found any documentation on how much data Golioth overhead adds or if 10x is normal.
Q2) I haven’t found any forum posts or documentation that would explain the large increase in data usage from an idle modem vs. a sleeping modem.
1 Like
@john.stuewe thank you for reporting this behavior! There are a number of reasons why your cellular usage may exceed your Golioth usage. Only OTA, logs, and streaming data are billed based on data usage on Golioth. For streaming data, usage is billed on egress data from Pipelines, and depending on the configuration in a project, data from a device may be transformed to be smaller / larger than the original payload, and / or sent to multiple destinations. In addition to the data used to interact with these Golioth services, cellular data usage includes handshakes, protocol overhead, and usage of other Golioth services (e.g. RPCs, Settings, LightDB State, etc.). Therefore, it is very likely that the usage metrics on Golioth do not align directly with your cellular data usage.
However, in this case it does appear that there is quite a significant difference in the Golioth data usage and your cellular data usage, which may be indicative of configuration or connectivity issues. For example, if your firmware is sending keep-alives and frequently loses connection to the Golioth platform, it may frequently be performing handshakes. I suspect this may be the issue in your case. Similarly, if you have frequent changes to services (e.g. Settings) on which your firmware has a CoAP observation established, the platform may be sending you data that you ultimately discard. In any of these cases, it would make sense that putting the modem to sleep would minimize your cellular data usage.
There are some controls in the SDK today to mitigate this behavior. First, you can reduce the frequency at which keep-alives are being sent with CONFIG_GOLIOTH_COAP_KEEPALIVE_INTERVAL_S. It defaults to 9 seconds, which sounds to be much more frequent than required for your use case. Keep-alives can be disabled entirely by setting to 0 if preferred. Additionally, you may opt to stop the Golioth client when you are not sending or syncing data with golioth_client_stop(). Using either of these options will impact how responsive your devices are to changes made on the cloud (i.e. if you stop the client you will not be notified of changes to Settings, for example, until you reconnect), but it does give you tighter control over when data is being transmitted.
We may be able to provide additional assistance with answers to the following questions.
- What is the current keep-alive interval for your firmware?
- Did you see this same level of cellular data usage prior to using
v0.21.0 of the Golioth Firmware SDK?
- Is the data usage fairly consistent across devices in your fleet?
- Are you frequently updating Settings and / or LightDB State values via the Golioth Console or Management API?
@hasheddan
-
keep-alive is still at default: build/sm-iot-gen5/zephyr/.config:219:CONFIG_GOLIOTH_COAP_KEEPALIVE_INTERVAL_S=9
-
Yes. I see similar values with SDK 0.18.
-
Yes. Data usage is fairly consistent across the fleet in the first scenario. I don’t know about the huge increase when I leave the modem on since I only do that when I have USB power and the fleet is on battery.
-
No, they are very static. I only update settings or LightDB state values on a configuration change which are all manual.
I occasionally get a “golioth_zephyr_coap_req: 1 resends in last 10 seconds” message but no client disconnect\reconnects recently. I have seen the cellular network does drop and re-connect to Golioth but that’s not happening now.
I’m trying just dis-connecting Golioth and leaving the modem on to isolate the modem-on data increase now.
With modem on during readings, increasing the KEEPALIVE_INTERVAL from 9 to 30 had no effect. Increasing it >60 caused disconnects and increased data usage.
2225KB/day with CONFIG_GOLIOTH_COAP_KEEPALIVE_INTERVAL_S=9
2229KB/day with KEEPALIVE_INTERVAL=30
9189KB/day with KEEPALIVE_INTERVAL=360. Significant ‘disconnect’ events requiring re-synch
KEEPALIVE_INTERVAL=60 also had many disconnects and is likely high data usage
[490828:40:36.506,000] sm_iot: on_client_event: Golioth client disconnected/offline
[490828:40:38.593,000] sm_iot: on_client_event: Golioth client Connected
It doesn’t look like modifying the keepalive interval is a solution.
@john.stuewe thank you for the update here. The relative changes in data usage that you are reporting are not unexpected, given that I suspect you are hitting NAT timeouts on your cellular network, meaning that when the device next pings the sever with a keepalive message it is coming from a new IP address. We have a blog post that describes how DTLS Connection ID can be used to work around this, demonstrating doing so with an nRF9160 device using a Hologram SIM on AT&T. It may be worth testing enabling connection IDs with CONFIG_GOLIOTH_USE_CONNECTION_ID=y if you haven’t already, then testing with a long keepalive interval again.
However, if you want to ensure no data is being sent in between your sensor reading deliveries (and you can tolerate up to an hour for settings / etc. to be synced), I would recommend using the strategy of stopping the Golioth client, rather than just increasing the keepalive interval.
I added these thre
CONFIG_GOLIOTH_USE_CONNECTION_ID=y
CONFIG_GOLIOTH_COAP_KEEPALIVE_INTERVAL_S=360
CONFIG_GOLIOTH_COAP_CLIENT_RX_TIMEOUT_SEC=370
Taking hourly readings I estimate my usage at 7.4MB/month before this change and 7.2MB/month after it when I turn the modem off after every reading. Golioth is reporting usage less than 3MB/month so the overhead is >2x.
Keeping the modem on I am estimate 69MB/month with my old settings and 5.4MB/month with these settings. My cellular connection wasn’t great and I got ~15 COAP re-tries but no re-syncs but I’m seeing a >10x reduction in modem-on data usage. I know this doesn’t apply to battery usage but I was hitting data caps on my development system that has USB power so this is a big help. I’ll play around with lowering the interval and timeout next.
1 Like