We Benchmarked Teleoperation Latency Across 3 Continents: Full Results
Leela Yanamaddi
November 5, 2026
We can’t recommend a teleoperation route from this report. Its 40 ms latency budget is modeled - not measured. Before choosing a route, we need repeated tests of command delay, video delay, and the time from operator input to visible robot response.
Here’s what we can - and can’t - tell you:
- Route comparisons: Missing locations, session logs, and timing checks prevent us from ranking connections.
- Control delays: We need median, p95, and p99 results - not just an average. Those last two thresholds cover 95% and 99% of samples.
- Task fit: Precision work, navigation, and pick-and-place each need delay limits tested against robot speed and behavior.
- Deployment checks: We would test peak traffic, stale video, disconnects, recovery, and local stopping before approval.
Our takeaway: <u>treat this as a guide to what to test, not proof that a route is ready</u>. A low delay estimate alone does not establish safe robot control.
Teleoperation Latency: Route Validation Checklist
Measurement Methods and Data Quality
Command, Video, and End-to-End Measurement Boundaries
The reported timing breakdown is a modeled allocation, not a direct measurement of each boundary. Command timing stops when the controller receives the command - not when the robot moves. Without timestamps at each boundary, network transit time cannot be separated from processing or buffering.
Clock Synchronization and Timing Checks
The timing method is only partly described, so its uncertainty bounds are unknown. The supplied material does not report timestamp sources, the synchronization method, clock uncertainty, sampling rate, trial duration, command count, or how invalid samples were handled.
Latency Statistics, Jitter, and Repeatability
The supplied material does not include route-level medians, tail latency, jitter, sample counts, confidence intervals, or results from repeated sessions. Without medians, p95/p99, and repeatability data, route rankings cannot be independently checked in this section.
Full Results by Route
Command, Video, and End-to-End Results
The timing boundaries above define how route-level results should be reported. But the source provides only modeled latency components, so no route table can be reconstructed.
Route Findings and Control Problems
Without session logs, routes cannot be ranked by responsiveness or task fit. Command delays, stale video, interruptions, and extra operator corrections also cannot be tied to specific routes.
Delay Sources and Changes Over Time
The modeled budget assigns 2 ms to command transmission and 8 ms to packetization and video transport, within a total of 40 ms. These are modeled allocations - not observed route results.
Persistent delay can indicate buffering; spikes can indicate contention, retransmission, or scheduling; stale video can indicate excessive buffering.
These symptoms offer diagnostic clues, not route-specific findings. That distinction shapes the discussion of control in the next section.
What the Results Mean for Robot Control
Matching Latency to Robot Tasks
Use latency budgets to decide which tasks can stay remote and which need local assistance. Base each budget on end-to-end response delay, including actuation and the full camera-to-display path - not round-trip time alone. Measure command and video paths separately, then compare end-to-end median, p95, and p99 with the task budget. Delay tolerance depends on robot dynamics and the interface; these results do not establish a universal threshold for precision control.
| Task | Latency profile to validate | Likely failure mode | Safeguards to validate separately |
|---|---|---|---|
| Fine manipulation | Low, stable end-to-end delay, including tails | Overshoot, missed contact, repeated corrections | Local force limits, short motion segments, low-speed mode |
| Precision alignment | Consistent feedback through the final approach | Alignment against an outdated image | Visual markers, guarded motion, local assist for final alignment |
| Supervised navigation | Delay compatible with speed and local stopping behavior | Late obstacle response | Local obstacle detection, speed limits, geofencing |
| Slow pick-and-place | Predictable feedback with bounded interruptions | Placement errors | Grasp verification, structured workspace, pause-on-timeout |
Tail Latency and Stale Video
Median delay doesn't tell the whole story. Tail latency helps determine whether operators can maintain control. p95 and p99 mark the delay thresholds that 95% and 99% of samples stay under. But they don't show whether slow samples occurred in one long stall or as scattered spikes.
Delayed commands postpone motion. Delayed video hides motion already underway. Measure both paths separately, and log spike duration and frame age to identify when overshoot or repeated corrections become likely.
Timestamp commands and frames, show frame age, reject expired commands, and switch to a local hold when feedback exceeds an age limit validated for the task. Receiving a remote stop command does not validate safety. Physical stopping behavior must be tested locally, including during link failure.
Operator Location and Connection Requirements
Operator location matters only if it improves measured delay and jitter under the actual workload. Compare locations with identical workloads and timing boundaries. Then use end-to-end latency, jitter, and frame age to check whether each connection meets the task budget.
| Deployment decision | Evidence to compare | Recommended interpretation |
|---|---|---|
| Nearby versus distant operator | Median, p95/p99 end-to-end delay, jitter, packet loss, and frame age under identical load | Choose proximity only when the measured improvement matters to the task |
| Continuous precision control | Sustained end-to-end delay, spike frequency, and recovery under peak load | Approve only after task trials meet the control budget |
| Supervisory intervention | Intervention delay, disconnect duration, and stale-frame behavior | Keep time-critical responses local; validate remote recovery separately |
| Network capacity for peak use | Sustained bandwidth, packet loss, packet retransmissions, video bitrate, frame rate, and recovery behavior | Test under peak traffic, not idle conditions alone |
Study Limits, Deployment Checks, and Conclusions
Study Limits and Where Results Apply
The route results above are incomplete, so deployment remains conditional. They do not support approval across all settings.
The report leaves out session counts, durations, dates, repeated trials, and details about sites, robots, and networks. Those gaps prevent route-level generalizations. It also does not say whether the benchmark measured task performance, safety, or link recovery, which limits deployment claims. Without repeatability data, treat the results as observations from individual sessions.
Routing changes, congestion, interference, handoffs, VPN or cloud-path changes, hardware differences, and live traffic could explain variation, but none are confirmed here. Missing timing-uncertainty estimates also limit confidence in small differences between routes.
Production Monitoring and Local Safeguards
These limits shift the focus from broad claims to monitoring in production.
Keep command, video, and end-to-end latency distributions. Set alerts for task-specific p95/p99 thresholds, and monitor packet loss, stale frames, and reconnections. Validate local interlocks, watchdogs, and safe-stop behavior independently of the operator.
Test failover and operator handoff. Measure detection, reconnection, video recovery, and situational-awareness recovery times, and prevent duplicate commands. Repeat these checks under production load and after configuration changes.
This benchmark is not safety certification.
Choosing a Route for Deployment
Consider a route for deployment only after those checks pass.
The current evidence does not approve any route for any tested task. Require another trial if task evidence, tail measurements, or recovery tests are missing - or if the provider, camera pipeline, controller, or workload changes.
Approve deployment only when end-to-end delay and command/video tails meet task tolerances under representative load, repeated trials show consistent results, and failover, recovery, and local safeguards pass validation. Approve slower routes only for tasks with suitable autonomy, lower motion speed, and validated local safeguards.
Motion Scaling Solutions for Improved Performance in High Delay Surgical Teleoperation
FAQs
How can I set a latency budget for my robot?
Set limits for each task, rather than using universal thresholds. Map the full feedback loop - from operator input to displayed motion - and assign a latency budget to each stage.
Measure median, p95, and p99 latency using synchronized timestamps on a shared timebase. Set separate targets for commands and video, then test both under actual network conditions, including peak load and jitter.
Automatically end sessions that exceed those limits. Keep independent onboard safety and stop mechanisms in place.
How many test runs make latency results reliable?
Repeat tests 30 to 100 times to set an initial teleoperation latency baseline. For each run, record raw timestamps and synchronized video. Change only one variable at a time, such as bitrate, network traffic, or codec settings.
Collect longer traces to get reliable p99 measurements - small samples aren't enough. Test under the network conditions you expect during deployment, including peak load and possible wireless interference.
How can I measure latency without synchronized clocks?
Use a high-speed camera recording at 240 fps or higher to film both the input trigger and the operator’s display. Measure the time from the trigger until robot motion appears on-screen. This gives you end-to-end latency.
For intervals within each stage, use local monotonic clocks. When measuring across devices, establish a shared timebase or calibrate clock offsets using PTP. Report the synchronization uncertainty, too.
Collect traces over long periods and report the median, p95, and p99, not just averages.