--- name: satellite-host-latency-test title: Network latency requirements for Satellite hosts description: Review the network latency requirements for hosts that you add to your IBM Cloud Satellite location to ensure optimal performance and availability. last-updated: 2026-08-14 --- > ## Documentation Index > The table of contents for this documentation set is at https://cloud.ibm.com/docs/satellite?format=markdown > The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt > Use these files to discover more information as needed. # Network latency requirements for Satellite hosts {: #host-latency-test} Review the network latency requirements for hosts that you add to your IBM Cloud Satellite location to ensure optimal performance and availability. {: shortdesc} ## IBM-managed master to customer-provided worker nodes for the Satellite location control plane {: #host-latency-test-master-worker} The hosts that you want to attach to the Satellite location control plane must have a low latency connection of less than or equal to 200 milliseconds (`<= 200ms`) round trip time (RTT) to the IBM Cloud region that your Satellite location is managed from. As latency increases, you might see impacts to performance, including Satellite Link throughput, Satellite-enabled IBM Cloud service provisioning time, host failure recovery time, and in extreme cases, the availability of resources that run in the Satellite location control plane, such as Red Hat OpenShift cluster masters. For more information, see [Testing the latency between IBM Cloud and the Satellite location control plane hosts](https://cloud.ibm.com/docs/satellite?topic=satellite-host-latency-test&format=markdown#host-latency-mzr). ## Customer-provided worker nodes in the Satellite location control plane to worker nodes that run Satellite-enabled IBM Cloud services, such as Red Hat OpenShift clusters in the same location {: #host-latency-test-woker-worker} Your host infrastructure setup must have a low latency connection of less than or equal to 100 milliseconds (`<= 100ms`) round trip time (RTT) between the hosts that are used for the Satellite location control plane worker nodes and the hosts that are used for other resources in the location, like clusters or [Satellite-enabled IBM Cloud service](https://cloud.ibm.com/docs/satellite?topic=satellite-managed-services&format=markdown). For example, in cloud providers such as AWS, this setup typically means that all the hosts in the Satellite location are from the same cloud region, like `us-east-1`. As latency increases, you might see impacts to performance, including provisioning and recovery times, reduced worker nodes in the cluster, Satellite-enabled IBM Cloud service degradation, and in extreme cases, failures in your cluster applications. ## Customer-provided worker nodes that are assigned to the same resource, such as the Satellite location control plane or a cluster {: #host-latency-test-customer-provided} Your host infrastructure setup must have a low latency connection of less than or equal to 10 milliseconds (`<= 10ms`) round trip time (RTT) among all the hosts that are assigned to the same Satellite resource, such as the Satellite location control plane, a Satellite-enabled IBM Cloud service, or cluster. As latency increases, you might see impacts to performance, including Satellite-enabled IBM Cloud services like databases or cluster application failures. ## Testing the latency between IBM Cloud and the Satellite location control plane hosts {: #host-latency-mzr} Each Satellite location is [managed from an IBM Cloud multizone region](https://cloud.ibm.com/docs/satellite?topic=satellite-sat-regions&format=markdown#understand-supported-regions). You can test the latency between your hosts and the region to make sure you use a low latency connection of less than or equal to 200 milliseconds (`<= 200ms`) round trip time (RTT). {: shortdesc} 1. In your infrastructure provider, log in to a host machine that you want to add to a Satellite location. For example, you might SSH into the machine from a command line. 2. Note the IP addresses for the IBM Cloud region that you want to test Dallas : 52.117.39.146, 169.48.134.66, 169.63.36.210 Frankfurt : 149.81.188.122, 158.177.88.18, 161.156.38.122 London : 158.175.120.210, 141.125.97.106, 158.176.139.66 Osaka : 163.68.73.50, 163.69.65.242, 163.73.67.10 Sao Paulo : 163.107.67.18, 163.109.71.82, 169.57.144.42 Sydney : 130.198.65.82, 135.90.66.194, 168.1.58.90 Tokyo : 161.202.104.226, 128.168.67.106, 165.192.108.10 Toronto : 163.74.65.138, 163.75.70.50, 169.53.160.154 Washington, DC : 169.63.123.154, 169.63.110.114, 169.62.13.2, 169.60.123.162, 169.59.152.58, 52.117.93.26 Madrid : 13.120.67.114, 13.121.67.98, 13.122.67.106 3. From your host, ping the IP addresses of the IBM Cloud region. ```sh ping ``` {: pre} 4. After a few packets complete transmission, close the connection. For example, from the command line, you might enter `ctrl+c`. 5. In the `ping statistics` output, note the average (`avg`) round trip distance in milliseconds (ms) between the host and the IBM Cloud region, and compare whether the connection meets the latency requirement of less than or equal to 200 milliseconds (`<= 200ms`). Example of a connection that meets the latency requirements ```sh --- 169.63.123.154 ping statistics --- 25 packets transmitted, 25 packets received, 0.0% packet loss round trip min/avg/max/stddev = 48.131/77.716/181.397/27.893 ms ``` {: screen} Example of a connection that does not meet the latency requirements ```sh --- 158.175.120.210 ping statistics --- 9 packets transmitted, 9 packets received, 0.0% packet loss round trip min/avg/max/stddev = 138.453/217.370/419.901/108.211 ms ``` {: screen}