I’m starting to explore various aspects of connecting a Toradex device to a cellular modem. So far I’ve managed to establish a data connection and get that part functional.
One thing that I am interested in (and which I don’t see a lot of discourse on, in general) is how to minimize the network “chattiness” of background services, as one might want to do with a metered connection.
Naturally, we can control the connection explicitly and only bring it up when necessary, in addition to marking it as “metered” in NetworkManager. I know there are additional controls for some of the Toradex services like the update poll rate, etc. but a general guidance document on monitoring what is consuming network bandwidth and what could be done to configure that for the Torizon platform would be an excellent starting point for myself and possibly others.
Do you have some recommended reading or pointers to start looking at?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Thank you for reaching out with your question about minimizing network chattiness on your Toradex device running Torizon, especially when using a metered cellular connection. Here are some strategies you can implement to manage and reduce network usage effectively:
Mark the Connection as Metered: Use NetworkManager to mark your cellular connection as metered. This setting can help reduce automatic updates and background data usage. You can configure this by editing the connection settings in NetworkManager and setting the metered property to yes.
Adjust Update Settings: Torizon allows you to configure the update poll rate and other settings to minimize network usage. You can adjust these settings in the TorizonCore configuration to control how often the system checks for updates.
Monitor Network Usage: Utilize tools like nethogs or iftop to monitor network traffic and identify which services are consuming bandwidth. These tools can help you pinpoint unnecessary network activity and take action accordingly.
Disable Unnecessary Services: Review the services running on your device and disable any that are not essential for your application. This can be done using systemd commands to stop and disable non-essential services.
Efficient Use of ModemManager and NetworkManager: Ensure that ModemManager and NetworkManager are configured to bring up the connection only when necessary. You can script these tools to connect and disconnect based on specific triggers or conditions in your application.
By following these steps, you can effectively manage network chattiness on your Toradex device, optimizing it for use with a metered cellular connection. These strategies should provide a solid starting point for monitoring and configuring network bandwidth usage on the Torizon platform.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
I’m starting to explore various aspects of connecting a Toradex device to a cellular modem. So far I’ve managed to establish a data connection and get that part functional.
Just to understand your use-case better. What kind of cellular modem are you planning to use on your product here? (i.e. 4G, 5G, etc).
Furthermore on this point, will there be a strict data limit on these devices, or are you just trying to minimize data usage with no strict limit?
Now with regards to minimizing your network consumption with our Torizon Cloud Platform. At the moment we don’t have a single best-practices document so to speak. Though this topic is on our radar as we have other customers in a similar situation to you, where they have a modem and need to minimize network usage.
Just some ideas off the top of my head though:
Reducing polling rate as you already mentioned. You can do this for both the Aktualizr update client and the fluent-bit client.
Outright disabling stuff you don’t need. For example if you don’t need device monitoring at all, then perhaps fluent-bit can be disabled entirely on your systems.
For container updates you probably need to architecet the container image in a way that changes require a minimal amount of layers to be downloaded during updates.
It’s not fully ready yet and still disabled by default. Once ready, the idea is that we will use this MQTT client to reduce the data usage of both the Aktualizr update client and the remote access client.
Thanks for the information. We are looking at a 4G/LTE modem (EM7590) and while we do not (yet) have strict network limits, we are looking to understand what the smallest possible “baseline” for usage can be(while retaining features we want; this is to help us decide which data plans are appropriate for our device when deployed.
We are likely going to continue to ship updates as offline lockboxes for this devices, but the static-delta item you mention is certainly interesting. Doesn’t the OS OTA already do something like that with the ostree repository? Or are the additional savings of the delta package from further breaking down all changed files into only the actual file delta?
I’m also glad to hear its on your radar and that you’ve got further improvements in the works. We’ll keep an eye out for those
Doesn’t the OS OTA already do something like that with the ostree repository? Or are the additional savings of the delta package from further breaking down all changed files into only the actual file delta?
To briefly explain. You are correct that OSTree does already have fairly minimal updates. But during the download procedure this can still result in 100s of individual download requests since the OSTree metadata itself is composed of numerous smaller object files.
Creating a static delta takes this even a step farther in terms of download optimization. The trade off is that a static delta is made between two specific OSTree versions. For example without static deltas, you can go from version A to C to B to D, or in whatever order you want. If you create a static delta between version A and B, then you can only use that static delta update to go from A to B, if you go A to C it will be a normal non-static-delta update. That is unless you make another static delta between the two versions. So it’s a tradeoff between flexibility and optimization.
If you want every update to be a static delta, then you need to consistently create static deltas between the two versions that you will update between. This is why it’s not the default for OSTree and need to be explicitly created as such.
As an example of the difference static-deltas can make. We had a customer where one of their updates with normal OSTree updates was about ~100MB. The same update with a static delta was only ~30MB. Furthermore the number of object files that needed to be downloaded was also greatly reduced.
Anyways, I hope that gave a better picture on static-deltas for you to consider.
Thanks for the clarification. That makes sense and it might be something we could indeed use to facilitate smaller updates for the most common update path(s).
Not quite yet - thanks. I’m hoping to get some more hands-on time today to experiment with the various evaluation boards we have for this. I’m sure I’ll have more questions as I wrap my head around the details
