A Buyer’s Checklist for Networking Software on Robots
Networking software for robots has to be measured on the robot, with the robot’s real workload running. The software shares the onboard computer with perception, planning and logging. Five measurements decide whether a package fits. The five are CPU and memory under load, behavior when an internet connection breaks, routing control, management access and safety scope.
Every robot company evaluating a fleet agent, a remote-access tool, a VPN or a client that combines internet connections runs into the same gap. Vendor datasheets quote resource numbers measured on the vendor’s hardware.
The short version: run all five checks on your own board, with your own internet connections and traffic. Run the checks before any networking software goes into the robot’s image. Agree on the success criteria before the pilot starts.
This article lists the five measurements with the Linux commands for each, and explains how Speedify was designed to answer each check. Speedify is software that combines every network a machine can reach (Wi-Fi, 4G/5G cellular, Ethernet, Starlink and satellite) into one connection. Speedify sells software in this category, and the five checks are the same five Speedify measures on the customer’s hardware during a pilot.
1. Measure CPU and Memory With Your Own Robot Workload Running
Measure per-core CPU, resident memory at steady state and at peaks, and your own application’s latency, with and without the networking software running. Idle numbers say almost nothing.
On Linux, pidstat -u -r -p <pid> 1 from the sysstat package logs a process’s CPU and resident memory once a second. Run the measurement on each board you ship, with the number of internet connections you plan to use and realistic traffic. A figure from an x86 test box says little about an ARM board already busy with perception.
Where the work lands matters as much as how much work there is. On a four-core gateway combining two internet connections, Speedify’s worker threads first ran on any core. Throughput reached about 0.99 Gbps, and the core handling network interrupts was saturated. Keeping the workers off that core reached about 1.31 Gbps, with no core above 92%. Speedify ships a tuning service that holds the faster layout in place.
The Speedify embedded daemon was designed for that budget. The daemon builds with only the features a product needs and, where the platform allows, uses batching and kernel offloads. The daemon for embedded Linux ships as a single static binary of about 4 MB with no runtime dependencies.
2. Break an Internet Connection on Purpose and Watch Your Applications
Break the network three ways, then watch your own applications, not the vendor’s dashboard. Pull a modem physically, because a physical pull exercises the USB and driver path. Take an interface down in software with ip link set wlan0 down, because a clean shutdown of the interface takes a different code path. Degrade an internet connection that stays up with tc qdisc add dev wlan0 root netem delay 80ms loss 5%. A degraded connection that never goes down is the most common case in the field and the hardest for software to handle.
A software shutdown and a physical loss are not equivalent, and the difference is measurable. In Speedify’s testing, an internet connection taken down administratively was known to the daemon in about 70 ms. A cable pulled from a switch port whose status the kernel polls once a second was known about 390 ms later.
Watch for frozen teleoperation sessions, restarted uploads and robots marked offline, and time how long everything takes to settle. Repeat each test enough times to see a pattern, and include a restart of the networking service.
Include a cold boot at the edge of coverage, too. A USB cellular modem that registers every time on a bench can fail to come up at boot in a low-signal spot. A common fix is a watchdog that power-cycles the modem when no connection exists a few minutes after startup. A bench test at a desk never finds that kind of bug.
3. Decide Who Controls Routing on the Robot
Decide before installing whether the networking software or the robot’s own network manager owns the routing table. Many robot images already run a network manager. Software that silently rewrites routes will compete with the network manager, usually at the worst time. Capture ip route and ip rule before and after installing the software.
Speedify supports either approach. By default, the Speedify daemon installs per-connection policy routing as internet connections come and go, and removes the routing on shutdown. With self-managed routing turned off, the daemon follows the robot’s own network manager. The daemon then checks that the expected routes are present and warns loudly when the routes are missing. ‘Everything looks fine but no traffic flows’ is the hardest failure to debug.
Enabling IP forwarding on Linux can stop an interface from accepting router advertisements. Instead of deciding for the operator, the Speedify daemon names the interfaces at risk.
Ask what happens before the service starts, too. The Speedify embedded daemon includes a built-in preflight check. The check covers the configuration, each internet connection’s interface state and route to the server, server reachability and throughput-related kernel settings. The check returns a non-zero exit code the robot’s supervisor can act on, so a misconfigured robot can be caught at boot instead of mid-mission.
4. Check Where the Networking Software’s Management Access Listens
Find every port the software listens on, and check who can reach each port. ss -ltnp lists every listening TCP socket and the process behind each socket. Anything listening on 0.0.0.0 is reachable from every network the robot joins, including a customer’s guest Wi-Fi, unless a firewall blocks the port.
Speedify’s local management interface relies on the operating system’s access control, and the defaults are the closed ones. The control socket is readable only by the owner. The HTTP listener binds to loopback. An invalid socket permission setting stops the daemon at startup instead of falling back to something more permissive. Remote management goes through the customer’s own authenticated layer.
Ask about the language and the encryption, too. Speedify’s robot data plane is written in Rust. A networking daemon parses packets from networks the daemon does not control, on several threads at once. That workload is where C++ produces use-after-free bugs, buffer overruns and data races. Rust rules that class of bug out at compile time, without a garbage collector pausing the packet path.
The Speedify embedded daemon carries traffic over plain TCP on each uplink. Protect sensitive traffic with TLS or SRT in the application, or with a tunnel over the combined connection. The Speedify app and Speedify for Routers encrypt traffic with AES-256 between the machine and the Speedify server. A vendor should be able to state all of the above in one paragraph.
5. Write Down What Is Out of Scope for Safety
Write down, before the pilot, what the networking software is not responsible for. Speedify carries operational traffic: telemetry, video, diagnostics, data and updates. Speedify is not certified as a safety communication channel. Safety-critical control and the machine’s response to lost connectivity belong in the machine’s own independently validated design. Any vendor in this category should draw the same line without being asked.
Why a Datasheet Benchmark Cannot Answer These Five Questions
Each of the five checks depends on something only the robot team knows: the board, the workload, the internet connections, the image and the safety case. A single number on a datasheet hides all of those details.
Speedify tests Speedify the same way. A test matrix runs 129 emulated network scenarios against a real Speedify server. Each scenario gets a grade from A to F instead of pass or fail. Each grade compares against a measured single-connection reference over the same path, not the nominal rate. A grade distribution shows where a build falls short; a pass mark only says the build is acceptable.
If you are evaluating networking software for a fleet, Speedify for physical AI describes how a Speedify pilot is set up. The options range from the Speedify SDK inside the image to Powered by Speedify hardware. Contact Us to book a demo with the Speedify team or to plan a pilot on your own hardware.
Speedify Business Solutions
Speedify Teams
Speedify for Routers
Speedify Embedded Solutions and Integrations
Add Speedify to your own app or hardware with the Speedify SDK. Your product then combines internet connections, fails over automatically when one drops, and encrypts the traffic, using the same technology as the Speedify app.