--- name: satellite-host-latency-test title: Network latency requirements for Satellite hosts description: Review network latency requirements for hosts in your IBM Cloud Satellite location to ensure optimal performance. last-updated: 2026-08-27 --- > ## 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 network latency requirements for hosts in your IBM Cloud Satellite location to ensure optimal performance. {: 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. Higher latency degrades 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`. Higher latency degrades performance, including provisioning and recovery times, available worker nodes in the cluster, Satellite-enabled IBM Cloud service stability, and in extreme cases, cluster application availability. ## 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. Higher latency degrades performance and can cause Satellite-enabled IBM Cloud services such as databases and cluster applications to fail. ## Testing the latency between IBM Cloud and the Satellite location control plane hosts {: #host-latency-mzr} Test the latency between your hosts and their managing [IBM Cloud region](https://cloud.ibm.com/docs/satellite?topic=satellite-sat-regions&format=markdown#understand-supported-regions) to verify the less than or equal to 200 milliseconds (`<= 200ms`) RTT requirement. {: shortdesc} 1. In your infrastructure provider, log in to a host machine that you want to add to a Satellite location. For example, use Secure Shell (SSH) to connect to 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, 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}