server round trip

Home  >  Learning Center  >  Round Trip Time (RTT)  

Article's content

Round trip time (rtt), what is round trip time.

Round-trip time (RTT) is the duration, measured in milliseconds, from when a browser sends a request to when it receives a response from a server. It’s a key performance metric for web applications and one of the main factors, along with Time to First Byte (TTFB), when measuring  page load time  and  network latency .

Using a Ping to Measure Round Trip Time

RTT is typically measured using a ping — a command-line tool that bounces a request off a server and calculates the time taken to reach a user device. Actual RTT may be higher than that measured by the ping due to server throttling and network congestion.

Example of a ping to google.com

Factors Influencing RTT

Actual round trip time can be influenced by:

• Distance  – The length a signal has to travel correlates with the time taken for a request to reach a server and a response to reach a browser.
• Transmission medium  – The medium used to route a signal (e.g., copper wire, fiber optic cables) can impact how quickly a request is received by a server and routed back to a user.
• Number of network hops  – Intermediate routers or servers take time to process a signal, increasing RTT. The more hops a signal has to travel through, the higher the RTT.
• Traffic levels  – RTT typically increases when a network is congested with high levels of traffic. Conversely, low traffic times can result in decreased RTT.
• Server response time  – The time taken for a target server to respond to a request depends on its processing capacity, the number of requests being handled and the nature of the request (i.e., how much server-side work is required). A longer server response time increases RTT.

See how Imperva CDN can help you with website performance.

Reducing RTT Using a CDN

A CDN is a network of strategically placed servers, each holding a copy of a website’s content. It’s able to address the factors influencing RTT in the following ways:

• Points of Presence (PoPs)  – A CDN maintains a network of geographically dispersed PoPs—data centers, each containing cached copies of site content, which are responsible for communicating with site visitors in their vicinity. They reduce the distance a signal has to travel and the number of network hops needed to reach a server.
• Web caching  – A CDN  caches  HTML, media, and even dynamically generated content on a PoP in a user’s geographical vicinity. In many cases, a user’s request can be addressed by a local PoP and does not need to travel to an origin server, thereby reducing RTT.
• Load distribution  – During high traffic times, CDNs route requests through backup servers with lower network congestion, speeding up server response time and reducing RTT.
• Scalability  – A CDN service operates in the cloud, enabling high scalability and the ability to process a near limitless number of user requests. This eliminates the possibility of server side bottlenecks.

Using tier 1 access to reduce network hops

One of the original issues CDNs were designed to solve was how to reduce round trip time. By addressing the points outlined above, they have been largely successful, and it’s now reasonable to expect a decrease in your RTT of 50% or more after onboarding a CDN service.

Latest Blogs

Grainne McKeever

Feb 26, 2024 3 min read

Erez Hasson

Jan 18, 2024 3 min read

Luke Richardson

Dec 27, 2023 6 min read

Dec 21, 2023 2 min read

Dec 13, 2023 5 min read

Dec 7, 2023 6 min read

• Imperva Threat Research

, Gabi Stapel

Nov 8, 2023 13 min read

Nov 7, 2023 1 min read

Latest Articles

• Network Management

169.7k Views

164.8k Views

152.8k Views

102.9k Views

100.3k Views

98.2k Views

58.6k Views

54.6k Views

2024 Bad Bot Report

Bad bots now represent almost one-third of all internet traffic

The State of API Security in 2024

Learn about the current API threat landscape and the key security insights for 2024

Protect Against Business Logic Abuse

Identify key capabilities to prevent attacks targeting your business logic

The State of Security Within eCommerce in 2022

Learn how automated threats and API attacks on retailers are increasing

Prevoty is now part of the Imperva Runtime Protection

Protection against zero-day attacks

No tuning, highly-accurate out-of-the-box

Effective against OWASP top 10 vulnerabilities

An Imperva security specialist will contact you shortly.

Top 3 US Retailer

Written by Vasilena Markova • September 27, 2023 • 12:58 pm • Internet

Round-Trip Time (RTT): What It Is and Why It Matters

Round-Trip Time (RTT) is a fundamental metric in the context of network performance, measuring the time it takes for data packets to complete a round trip from source to destination and back. Often expressed in milliseconds (ms), RTT serves as a critical indicator for evaluating the efficiency and reliability of network connections. In today’s article, we dive into the concept of RTT, exploring how it works, why it matters in our digital lives, the factors that influence it, and strategies to enhance it. Whether you’re a casual internet user seeking a smoother online experience or a network administrator aiming to optimize your digital infrastructure, understanding this metric is critical in today’s interconnected world.

Table of Contents

What is Round-Trip Time (RTT)?

Round-Trip Time is a network performance metric representing the time it takes for a data packet to travel from the source to the destination and back to the source. It is often measured in milliseconds (ms) and is a crucial parameter for determining the quality and efficiency of network connections.

To understand the concept of RTT, imagine sending a letter to a friend through the postal service. The time it takes for the letter to reach your friend and for your friend to send a reply back to you forms the Round-Trip Time for your communication. Similarly, in computer networks, data packets are like those letters, and RTT represents the time it takes for them to complete a round trip.

How Does it Work?

The concept of RTT can be best understood by considering the journey of data packets across a network. When you request information from a web server, for example, your device sends out a data packet holding your request. This packet travels through various network devices in between, such as routers and switches, before reaching the destination server. Once the server processes your request and prepares a response, it sends a data packet back to your device.

Round-Trip Time is determined by the time it takes for this data packet to travel from your device to the server (the outbound trip) and then back from the server to your device (the inbound trip). The total RTT is the sum of these two one-way trips.

Let’s break down the journey of a data packet into several steps so you can better understand the RTT:

• Sending the Packet: You initiate an action on your device that requires data transmission. For example, this could be sending an email, loading a webpage, or making a video call.
• Packet Travel: The data packet travels from your device to a server, typically passing through multiple network nodes and routers along the way. These middle points play a significant role in determining the RTT.
• Processing Time: The server receives the packet, processes the request, and sends a response back to your device. This processing time at both ends also contributes to the Round-Trip Time.
• Return Journey: The response packet makes its way back to your device through the same network infrastructure, facing potential delays on the route.
• Calculation: It is calculated by adding up the time taken for the packet to travel from your device to the server (the outbound trip) and the time it takes for the response to return (the inbound trip).

Why does it matter?

At first look, Round-Trip Time (RTT) might seem like technical terminology, but its importance extends to various aspects of our digital lives. It matters for many reasons, which include the following:

• User Experience

For everyday internet users, RTT influences the sensed speed and responsiveness of online activities. Low Round-Trip Time values lead to a seamless experience, while high RTT can result in frustrating delays and lag during tasks like video streaming, online gaming, or live chats.

• Network Efficiency

Network administrators and service providers closely monitor RTT to assess network performance and troubleshoot issues. By identifying bottlenecks and areas with high RTT, they can optimize their infrastructure for better efficiency.

• Real-Time Applications

Applications that rely on real-time data transmission, such as VoIP calls, video conferencing, and online gaming, are highly sensitive to RTT. Low RTT is crucial for smooth, interruption-free interactions.

In cybersecurity, Round-Trip Time plays a role in detecting network anomalies and potential threats. Unusually high RTT values can be a sign of malicious activity or network congestion.

Factors Affecting Round-Trip Time (RTT)

Several factors can influence the metric, both positively and negatively. Therefore, understanding these factors is crucial, and it could be very beneficial for optimizing network performance:

• Distance: The physical distance between the source and destination plays a significant role. Longer distances result in higher RTT due to the time it takes for data to travel the network.
• Network Congestion: When a network experiences high volumes of traffic or congestion, data packets may be delayed as they wait for their turn to be processed. As a result, it can lead to packet delays and increased RTT.
• Routing: The path a packet takes through the network can significantly affect RTT. Efficient routing algorithms can reduce the time, while not-so-optimal routing choices can increase it.
• Packet Loss: Packet loss during transmission can occur due to various reasons, such as network errors or congestion. When lost, packets need to be retransmitted, which can seriously affect the Round-Trip Time.
• Transmission Medium: It is a critical factor influencing RTT, and its characteristics can vary widely based on the specific medium being used. Fiber optic cables generally offer low RTT due to the speed of light in the medium and low signal loss. In contrast, wireless mediums can introduce variable delays depending on environmental factors and network conditions.

How to improve it?

Improving Round-Trip Time (RTT) is a critical goal for network administrators and service providers looking to enhance user experiences and optimize their digital operations. While some factors affecting it are beyond our control, there are strategies and practices to optimize Round-Trip Time for a smoother online experience:

• Optimize Routing: Network administrators can optimize routing to reduce the number of hops data packets take to reach their destination. This can be achieved through efficient routing protocols and load balancing .
• Optimize Network Infrastructure: For businesses, investing in efficient network infrastructure, including high-performance routers and switches, can reduce internal network delays and improve RTT.
• Upgrade Hardware and Software: Keeping networking equipment and software up-to-date ensures that you benefit from the latest technologies and optimizations that can decrease RTT.
• Implement Caching: Caching frequently requested data closer to end-users can dramatically reduce the need for data to travel long distances. The result really helps with lowering RTT.
• Monitor and Troubleshoot: Regularly monitor your network for signs of congestion or packet loss. If issues arise, take steps to troubleshoot and resolve them promptly.

Discover ClouDNS Monitoring service!

Round-Trip Time (RTT) is the silent force that shapes our online experiences. From the seamless loading of web pages to the quality of our video calls, RTT plays a pivotal role in ensuring that digital interactions happen at the speed of thought. As we continue to rely on the Internet for work, entertainment, and communication, understanding and optimizing this metric will be crucial for both end-users and network administrators. By reducing it through strategies, we can have a faster, more responsive digital world where our online activities are limited only by our imagination, not by lag.

Hello! My name is Vasilena Markova. I am a Marketing Specialist at ClouDNS. I have a Bachelor’s Degree in Business Economics and am studying for my Master’s Degree in Cybersecurity Management. As a digital marketing enthusiast, I enjoy writing and expressing my interests. I am passionate about sharing knowledge, tips, and tricks to help others build a secure online presence. My absolute favorite thing to do is to travel and explore different cultures!

Related Posts

Ping Traffic Monitoring: Ensuring Network Health and Efficiency

March 28, 2024 • Monitoring

In an era where digital connectivity is the lifeline of businesses and individuals alike, maintaining optimal network performance is more ...

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

• What is Traffic Director?
• Telnet Explained: What Is It and How It Works?
• Decoding Error 500: Understanding, Preventing, and Resolving the Internal Server Error
• What is a Smurf DDoS attack?
• Linux MTR command
• Cloud Computing
• DNS Records
• Domain names
• Load balancing
• SSL Certificates
• Web forwarding
• DNS Services
• Managed DNS
• Dynamic DNS
• Secondary DNS
• Reverse DNS
• DNS Failover
• Anycast DNS
• Email Forwarding
• Enterprise DNS
• Domain Names

• Engineering Mathematics
• Discrete Mathematics
• Operating System
• Computer Networks
• Digital Logic and Design
• C Programming
• Data Structures
• Theory of Computation
• Compiler Design
• Computer Org and Architecture

What is RTT(Round Trip Time)?

• What is Real-Time Linux?
• What is RTS(Real Time Streaming)?
• What is Time-To-Live (TTL)?
• Program to calculate the Round Trip Time (RTT)
• What is TCP Fast Open?
• Difference between Round trip time (RTT) and Time to live (TTL)
• Real Time Transport Protocol (RTP)
• How to subtract time in R ?
• Python time.tzset() Function
• TCP Tahoe and TCP Reno
• Ruby | Time to_time function
• Ruby | Time round function
• What is 15:00 Military Time?
• Time tuple in Python
• What Time will it be in 24 Hours From Now?
• Dart - Date and Time
• Ruby | Time utc function
• time.Time.Round() Function in Golang with Examples
• Ruby | Time to_r function
• What is OSI Model? - Layers of OSI Model
• TCP/IP Model
• Basics of Computer Networking
• Types of Network Topology
• Network Devices (Hub, Repeater, Bridge, Switch, Router, Gateways and Brouter)
• RSA Algorithm in Cryptography
• Caesar Cipher in Cryptography
• Differences between TCP and UDP
• TCP Server-Client implementation in C
• Types of Transmission Media

RTT (Round Trip Time) also called round-trip delay is a crucial tool in determining the health of a network. It is the time between a request for data and the display of that data. It is the duration measured in milliseconds. 

RTT can be analyzed and determined by pinging a certain address. It refers to the time taken by a network request to reach a destination and to revert back to the original source. In this scenario, the source is the computer and the destination is a system that captures the arriving signal and reverts it back. 

RTT(Round Trip Time) Measurement

What Are Common Factors that Affect RTT?

There are certain factors that can bring huge changes in the value of RTT. These are enlisted below:

• Distance: It is the length in which a signal travels for a request to reach the server and for a response to reach the browser,
• Transmission medium: The medium which is used to route a signal, which helps in faster transfer of request is transmitted.
• Network hops: It is the time that servers take to process a signal, on increasing the number of hops, RTT will also increase.
• Traffic levels: Round Trip Time generally increases when a network is having huge traffic which results in that, for low traffic RTT will also be less.
• Server response time: It is the time taken by a server to respond to a request which basically depends on the capacity of handling requests and also sometimes on the nature of the request.

Applications of RTT

Round Trip Time refers to a wide variety of transmissions such as wireless Internet transmissions and satellite transmissions. In Internet transmissions, RTT may be identified by using the ping command. In satellite transmissions, RTT can be calculated by making use of the Jacobson/Karels algorithm.  

Advantages of RTT

Calculation of RTT is advantageous because:

• It allows users and operators to identify how long a signal will take to complete the transmission.
• It also determines how fast a network can work and the reliability of the network.

Example: Let us assume there are two users, one of which wants to contact the other one. One of them is located in California while the other one is situated in Germany. When the one in California makes the request, the network traffic is transferred across many routers before reaching the server located in Germany. Once the request reverts back to California, a rough estimation of the time taken for this transmission could be made. This time taken by the transmitted request is referred to as RTT. The Round Trip Time is a mere estimate. The path between the two locations can change as the passage and network congestion can come into play, affecting the total period of transmission. 

How Does Round-Trip Time Work?

Consider a topology where an appliance named “Exinda” is located between the client and the server. The diagram shown below depicts how the concept of RTT works: 

RTT Calculation

  For the calculation of Average RTT, RTTS for server and client needs to be calculated separately. The performed calculations are shown below:

Server RTT: RTT1 = T2 – T1 RTT2 = T5 – T4

Client RTT: RTT3 = T3 – T2 RTT4 = T7 – T6 

Average RTT: Avg Server RTT = (RTTs1 + RTTs2) / 2 Avg Client RTT = (RTTc1 + RTTc2) / 2 Avg Total RTT = Avg Server RTT + Avg Client RTT 

You can refer to the Program to calculate RTT for more details.

Measures To Reduce RTT

 A significant reduction in RTT can be made using Content Delivery Network (CDN) . A CDN refers to a network of various servers, each acquiring a copy of the content on a particular website. It addresses the factors affecting RTT in the enlisted ways:

• Points of Presence (PoP)
• Web caching
• Load distribution
• Scalability
• Tier 1 access 

CDN has been largely successful in reducing the value of RTT and due to this, a decrease in RTT by 50% is achievable.

Please Login to comment...

Similar reads.

Improve your Coding Skills with Practice

What kind of Experience do you want to share?

• Looking Glass
• Developer Tools
• Status Page
• Case studies
• Press & Media
• Product Roadmap
• Product Documentation
• API Documentation
• Help Center
• CDN for Gaming
• Game Server Protection
• Game Development
• CDN for Video
• Video Hosting
• Live Streaming
• Video Calls
• Metaverse Streaming
• TV & Online Broadcasters
• Sport Broadcasting
• Online events
• Cloud for financial services
• Image Optimization
• Website Acceleration
• WordPress CDN
• White Label Program
• CDN for E-commerce
• AI Universities
• Online Education
• Wordpress CDN
• DDoS Protection
• Penetration Test
• Web Service
• White Label Products
• Referral Program
• Data Migration
• Disaster Recovery
• Content Hub Content Hub Blog Learning News Case studies Downloads Press & Media API Documentation Product Roadmap Product Documentation Help Center
• Tools Tools Looking Glass Speed Test Developer Tools Status Page
• Talk to an expert
• Under attack?

Select the Gcore Platform

• Edge Delivery (CDN)
• DNS with failover
• Virtual Machines
• Cloud Load Balancers
• Managed Kubernetes
• AI Infrastructure
• Edge Security (DDOS+WAF)
• Object Storage
• ImageStack (Optimize and Resize)
• Edge Compute (Coming soon)
• VPS Hosting
• Dedicated Servers

What is round-trip time (RTT) and how to reduce it?

In this article, factors affecting rtt, how to calculate rtt using ping, normal rtt values, how to reduce rtt, i want to reduce rtt with cdn. what provider to choose.

Round-trip time (RTT) is the time it takes for the server to receive a data packet, process it, and send the client an acknowledgement that the request has been received. It is measured from the time the signal is sent till the response is received.

When a user clicks a button on a website, the request is sent to the server as a data packet. The server needs time (RTT) to process the data, generate a response, and send it back. Each action, like sending a form upon a click, may require multiple requests.

RTT determines the total network latency and helps monitor the state of data channels. A user cannot communicate with the server in less than one RTT, and the browser requires at least three round trip times to initiate a connection:

• to resolve the DNS name;
• to configure the TCP connection;
• to send an HTTP request and receive the first byte.

In some latency-sensitive services, e.g., online games, the RTT is shown on the screen.

Distance and number of intermediate nodes. A node is a single device on the network that sends and receives data. The first node is the user’s computer. A home router or routers at the district, city, or country level are often intermediate nodes. The longer the distance between the client and server, the more intermediate nodes the data must pass through and the higher the RTT.

Server and intermediate node congestion. For example, a request may be sent to a fully loaded server that is concurrently processing other requests. It can’t accept this new request until other ones are processed, which increases the RTT. The RTT includes the total time spent on sending and processing a request at each hop, so if one of the intermediate nodes is overloaded, the RTT adds up.

You never know exactly to what extent the RTT will grow based on how the infrastructure is loaded; it depends on individual data links, intermediate node types, hardware settings, and underlying protocols.

Physical link types and interferences. Physical data channels include copper, fiber optic, and radio channels. The RTT here is affected by the amount of interference. On the Wi-Fi operating frequency, the noise and other signals interfere with the useful signals, which reduces the number of packets per second. So, the RTT is likely to increase over Wi-Fi than over fiber-optics.

To measure the RTT, you can run the ping command in the command line, e.g., “ping site.com.”

Requests will be sent to the server using ICMP. Their default number is four, but it can be adjusted. The system will record the delayed time between sending each request and receiving a response and display it in milliseconds: minimum, maximum, and average.

The ping command shows the total RTT value. If you want to trace the route and measure the RTT at each individual node, you can use the tracert command (or traceroute for Linux or Mac OS). It is also can be performed via the command line.

Many factors affect RTT, making it difficult to establish a normal—the smaller the number, the better.

In online games, over 50 milliseconds are noticeable: players cannot accurately hit their targets due to network latency. Pings above 200 milliseconds matter even when users browse news feeds or place online orders: many pages open slowly and not always fully. A buyer is more likely to leave a slow website without making a purchase and never come back, which is what 79 percent of users do .

Let’s compare the pings of the two sites—the US jewelry store Fancy and the German news portal Nachrichtenleicht.de . We will ping them from Germany.

The RTT of a German news portal is almost three times lower than that of a US store because we ping from Germany. There are fewer nodes between the user and the server, which are both in the same country, so the RTT is lower.

Connect to a content delivery network (CDN). The hosting provider’s servers are usually located in the same region where most of the audience lives. But if the audience of the site grows or changes geographically, and content is requested by users who are far away from the server, RTT increases for them, and the site loading speed is slower. To increase the loading speed, use a CDN.

CDN (Content Delivery Network) is a service that caches (mostly static) content and stores it on servers in different regions. Therefore, only dynamic content is downloaded from the main source server, which is far from the user. Heavy static files—the main share of the website—are downloaded from the nearest CDN server, which reduces the RTT by up to 50 percent.

For example, the client requests content from a CDN-connected site. The resource recognizes that there is a caching server in the user’s region and that it has a cached copy of the requested content. To speed up the loading, the site substitutes links to files so that they are retrieved not from the hosting provider’s servers, but from the caching server instead since it is located closer. If the content is not in the cache, CDN downloads it directly from the hosting server, passes it to the user, and stores it in the cache. Now a client on the same network can request the resource from another device and load the content faster without having refer to the origin server.

Also, CDN is capable of load balancing: it routes requests through redundant servers if the load on the closest one is too high.

Optimize content and server apps. If your website has visitors from different countries/regions, you need a CDN to offset the increased RTT caused by long distances. In addition, the RTT is affected by the request processing time, which can be improved by the below content optimizations:

• Audit website pages for unnecessary scripts and functions, reduce them, if possible.
• Combine and simplify external CSS.
• Combine JavaScript files and use async/await keywords to optimize their processing—the HTML code first, the script later.
• Use JS and CSS for individual page types to reduce load times.
• Use the tag instead of @import url (“style.css”) commands .
• Use advanced compression media technologies: WebP for images, HEVC for video.
• Use CSS-sprites: merge images into one and show its parts on the webpage. Use special services like SpriteMe.

For fast content delivery anywhere in the world, you need a reliable CDN with a large number of points of presence. Try Gcore CDN —this is a next-generation content delivery network with over 140 PoPs on 5 continents, 30 ms average latency worldwide, and many built-in web security features. It will help to accelerate the dynamic and static content of your websites or applications, significantly reduce RTT, and make users satisfied.

Related product

Try gcore cdn.

• 150+ points of presence
• Low latency worldwide
• Dynamic content acceleration
• Smart asset optimization
• Top-notch availability
• Outstanding connectivity

Related articles

• What is Managed Kubernetes
• Ways to Harm: Understanding DDoS Attacks from the Attacker’s View
• What Is a Data Breach and How Can It Be Prevented?

Subscribe and discover the newest updates, news, and features

• Skip to primary navigation
• Skip to main content
• Skip to footer

Cyara Customer Experience Assurance Platform

Blog / CX Assurance

December 12, 2023

What is Round-trip Time and How Does it Relate to Network Latency?

Tsahi Levent-Levi, Senior Director, Product

Round-trip time (RTT) is an important metric that can indicate the quality of communications available between two end-points. It’s a metric that our team often discusses with customers because it directly relates to the service quality experienced. RTT can be impacted by a range of design decisions, especially concerning network topology. However, there is some confusion around what exactly RTT is, how it relates to latency, how it can impact your service, and how you can improve it.

What is Round-trip Time?

One of our most viewed dashboard metrics in our Cyara testRTC product suite is RTT. This is the time it takes for a packet to go from the sending endpoint to the receiving endpoint and back. There are many factors that affect RTT, including propagation delay, processing delay, queuing delay, and encoding delay. These factors are generally constant for a given pair of communicating endpoints. Additionally, network congestion can add a dynamic component to RTT.

Propagation delay is the network distance between the two endpoints. It is the route taken by the data across the various networks, through different network switches and routers to get from the sending endpoint to the receiving endpoint. Sometimes, this may be aligned with geographical distances and sometimes it may not. Propagation delay is usually the dominant component in RTT. It ranges from a few milliseconds to hundreds of milliseconds, depending on whether the endpoints are separated by just a few kilometers or by an entire ocean.

The remaining components (processing, queuing, and encoding delays) can vary by the number of nodes in the network connecting endpoints. When only a few router hops separate the endpoints, these factors are insignificant. However, the more hops, the higher the delay, since each network node needs to receive, process and route all the data towards the next hop, adding its own milliseconds of delay to the total RTT calculation.

Impact of Network Topology

In real-time communications, we must consider the impact of network topology on RTT. Any infrastructure-based topology introduces incremental delays when compared with a peer-to-peer connection. When media is anchored by a multipoint control unit MCU , SFU , or TURN server, additional processing, queuing and encoding delays occur. But, more importantly, an infrastructure topology can add significant propagation delay depending on where the server is located relative to the endpoints.

Figure 1: Infrastructure Topology

Hairpinning occurs when media is anchored in a location that is geographically remote from an endpoint, this adds significant propagation delay, when compared to a peer connection. This is why the placement of infrastructure can be critical to delivering low RTT and a high-quality user experience. The further the media server is from the sending and receiving endpoints, the higher the RTT value and the lower the service quality.

Figure 2: The media server is located further away than necessary from the sending and receiving endpoints, resulting in a high round-trip time.

Figure 3: The media server is located between the sending and receiving endpoints, resulting in a lower round-trip time.

Clearing Up a Few Misconceptions

RTT and ping time are often considered synonymous. But while ping time may provide a good estimate of RTT, it is different. This is because most ping tests are executed within the transport protocol using internet control messaging protocol (ICMP) packets. In contrast, RTT is measured at the application layer and includes the additional processing delay produced by higher level protocols and applications (e.g. HTTPS). In WebRTC, RTT on the media streams is calculated by looking at the secure real-time transport protocol (SRTP) packets themselves. This provides the closest measure to what the actual media in a session feels like in terms of RTT.

Network latency is closely related, but different from RTT. Latency is the time it takes for a packet to go from the sending endpoint to the receiving endpoint. Many factors affect the latency of a service, including:

• Network congestion
• Packet loss and jitter
• Traffic prioritization
• Server load
• Codecs and encryption

Therefore, latency is not explicitly equal to half of RTT, because delays may be asymmetrical between any two given endpoints. For example, RTT includes processing delay at the echoing endpoint.

How Does RTT Affect Your Real-time Communications Service?

As a rule of thumb, the lower the RTT, the higher the media quality for that session is. Our focus is on ensuring the delivery of live, highly interactive services and conversations. Doing that requires a low delay from the time a user speaks until the intended recipients hear the spoken words.

At Cyara, we’ve made RTT a central focus in all of our WebRTC services. We ensure it is available to you in both aggregate form (in highlight dashboards) as well as in drill down analysis charts where you can analyze RTT over time.

Read more about: Cyara testRTC , Latency , Round-Trip Time (RTT) , Web Real-Time Communication (WebRTC) , WebRTC Monitoring

Subscribe for Updates

Join our email list, and be among the first to learn about new product features, upcoming events, and innovations in AI-led CX transformation.

What Is Round Trip Time (RTT)?

Want to understand what’s round trip time and why it’s important? You’re on the right page! Read our article and learn everything you need to know about this metric and the CDN role.

Wondering what’s round trip time and what’s its impact on performance? This article will cover everything you need to know about the round trip time (RTT), how it’s calculated, what affects it the most, and how a CDN can help to decrease it. 

What’s Round Trip Time?

Round trip time (RTT) measures the time it takes for the data to leave a starting point (the browser) and return to that very same point in milliseconds. It is a key metric used to measure network latency, page loading times, and the overall quality of a network.

• RTT = The time taken for a small packet of data to travel across the network and return at the same point. 
• Network latency = The communication delays over a network between the server and the user. Read our complete guide about network latency and how to reduce it with a CDN .

How To Calculate Round Trip Time (RTT)

Round trip time is the average server round-trip time plus the average round trip to the final client. 

When a user requests page content on Chrome, a request is sent to the server to load that page. This request/response scheme takes time, and those “lags” are called “propagation delays”. Two propagation delays constitute one round trip time.

When it comes to the actual calculation, there is one simple formula to remember.

How to Fix an RTT Average

If you want to fix an RTT average, you should aim at improving the propagation delay time on both the browser and server sides. 

To calculate the total RTT average, it’s crucial to know your client’s average server RTT and Average Client RTT. 

Let’s break down the process into two simple steps.

Step 1: the calculation needs to be done on the server and client sides: 

• Average Server RTT = (RTTs1 + RTTs2)/2  
• Average Client RTT = (RTTc1 + RTTc2)/2

Step 2: then you have all the data to calculate the average total RTT

Average Total RTT = avRTTs + avRTTc

What’s a Good Round Trip Time?

A good round trip time (RTT) should be below 100 milliseconds for optimal performance. Anything above may affect the connection depending on the application. 

Example of a Round Trip Time at Microsoft 

Microsoft has guidelines and rules to maintain healthy network quality. They published their network Performance requirements from a Skype for Business client to Microsoft network Edge. Here are the performance target requirements for optimal Skype for Business media quality.

How to Check My Round Trip Time – Example

Round trip time can be seen thanks to a “ping” via the terminal command of your computer. Follow the steps below to launch the command line: 

• Open your “Terminal Command” (on Mac) or your “CMD terminal” (on Windows)
• Type “traceroute” and “yourdomain” (it also works with your IP address)
• Press “Enter”

The round-trip times (RTTs) are expressed in ms from the third to the fifth column:

How Does Round Trip Time Work?

Round trip time is based on two main parameters:

• It determines the speed at which a network can operate as well as its global reliability.
• It allows users and operators to identify how long a signal will take to complete data transmission.

What Affects Round Trip Time?

The common factors affecting Round trip time are traffic, physical distance from the user to the servers, the transmission medium, and the overall infrastructure components.

Let’s go over each factor that impacts RTT the most:

• Physical distance – the high distance between the user computer (starting point) and the server (ending point) can be responsible for a high RTT. The data transfer time will take longer if the server is located on the opposite side of the world. 
• Response time of the origin server – measured with the Time to First Byte (TTFB) metric, it’s the amount of time it takes a server to process and respond to a request. If a server is attacked with thousands of simultaneous requests (e.g, during a DDoS attack), its ability to respond efficiently will be compromised, resulting in a high RTT.
• Transmission medium – Connections are made via cables, satellite, wireless or optical fiber. Each way affects the connection speed differently.
• Local area network (LAN) traffic – if a local area is already overloaded, it can impact the connection before it reaches the public internet. 
• Node count and congestion – the connection route may encounter some issues or congestion and may be redirected several times to intermediate nodes. The more nodes are touched, the slower the connection will result in a high RTT.

What’s the Impact of RTT on Performance and How a CDN Can Help

If the RTT is too high, time-outs and performance issues are very likely to occur. The Core Web Vitals of your website will also be impacted, resulting in a poor user experience. 

Let’s take the example of the Largest Contentful Paint (LCP), which measures when the page starts loading the largest text block or image rendered on the screen. To ensure that the resource starts downloading as soon as possible, you should reduce the distance from the browser to the server. 

This is exactly the purpose of a CDN: making the content available closer to visitors.

Let’s have a closer look at the four main reasons why a CDN can help reduce the RTT and improve performance:

• CDNs decrease RTT because the users’ requests are handled by a local PoP and not the origin server, reducing the physical distance between a server and a user. CDN pops shorten the distance and improve the availability of assets, leading to an enhanced RTT.

• A CDN reduces data transfer time between the cache servers and the user’s device by using caching to improve page load times. The idea is to get faster page loads for users located far away from the servers. 
• CDN helps to reduce server response time and the TTFB Time to First Byte (TTFB) metric. TTFB is the amount of time it takes for the server to get a response ready and the best way to reduce TTFB is by using a CDN to cache content. Kinsta run a performance audit before and after using a CDN, and they saw two interesting results: a faster loading site and less waiting time (TTFB).

Scenario #1 – Performance results – No CDN 

• Loading time = 1,45 s
• TTFB (wait time) = 136 ms

Scenario #2 – Performance results – With a CDN 

• Loading time = 788 ms
• TTFB (wait time) = 36 ms

• Lastly, CDNs protect your origin server in case of DDoS attacks. If your website targets an attack, a CDN will help to ensure it doesn’t reach the origin server and render your site completely offline. Thanks to the CDN, the traffic will simply be redirected to other PoPs servers, and this will help maintain a good RTT.

Using RocketCDN to Reduce RTT 

RocketCDN is a powerful CDN that uses caching and more than 35 Points of Presence to distribute the data around the globe, ensuring your website a low RTT.  It’s also very simple and easy to use – RocketCDN does all the advanced settings for you. 

Sounds promising? 

Let’s go over the best features of RocketCDN that will help boost your performance and keep your RTT below 100 ms. 

✅  RocketCDN: maintain a low RTT and TTFB but a high uptime 

Present in more than 35 markets and on four continents, RocketCDN is a powerful CDN that helps reduce RTT and TTFB. The CDN ensures fast responsiveness for all international visitors located around the globe. Nobody wants any latency to occur, and a fast website is the key to a great user experience. 

✅ Decrease the server response time with powerful caching

RocketCDN uses caching to make the content available faster for international users via PoPs, resulting in a faster server response time and increased performance. 

✅   Network security and DDoS attacks protection

RocketCDN includes Secure Sockets Layer (SSL) traffic and protects your origin server in case of DDoS attacks. If your website is targeted, RocketCDN will ensure that it doesn’t reach the origin server. Visitors won’t experience any downtime. They will simply be redirected to the other edge servers. And most importantly, the RTT will not be impacted!

✅ Straightforward installation and compatibility with any website technology

RocketCDN works with any website technology making it easy to connect to any CMS, including WordPress or Joomla. There is a WordPress plugin that automatically points your assets to RocketCDN.

✅  Unlimited bandwidth and high scalability 

RocketCDN can easily handle many visitors and unexpected traffic peaks with unlimited bandwidth. This is great for reducing the round trip time and avoiding any “hops” in the connection.

✅  A Cache Hit Ratio > 90% 

With a Cache Hit Ratio superior to 90%, it’s safe to say that the data is properly cached and that RocketCDN can process many requests successfully. Like RTT, Cache Hit Ratio is also an important performance metric for a CDN.    

Managing your Round trip time is straightforward with RocketCDN! 

Using RocketCDN allows you to distribute content more efficiently worldwide, save on RTT, TTFB and increase the performance of your website. RocketCDN does all the heavy lifting for you – you don’t need to worry about the technical settings! On top of that, you have up to 48 hours to cancel it if you don’t see any improvements. Try RocketCDN and start reducing your round-trip time today!

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free
• English (US)

Round Trip Time (RTT)

Round Trip Time (RTT) is the length time it takes for a data packet to be sent to a destination plus the time it takes for an acknowledgment of that packet to be received back at the origin. The RTT between a network and server can be determined by using the ping command.

This will output something like:

In the above example, the average round trip time is shown on the final line as 26.8ms.

• Time to First Byte (TTFB)

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Data obtained from ping: is it round trip or one way?

I have 2 servers, each in two separate locations. I need to host an application on one, and the database server on the other.

From the app server, if I ping the database server, on average I get about 30ms.

My question is:

Is it going to take 30 ms + database_server_query_run_time

Is it going to take 30 ms + database_server_query_run_time + 30ms

I would like to understand this please.

3 Answers 3

It will usually take more then those two options.

Ping measures just the time from client, to server, and back again (rtt - round trip time)

Usually databases use TCP, so you first need to send a SYN packet to start the TCP handshake (to simplify let's say 15ms* + cpu time, then you recieve and SYN/ACK (15ms+cpu time), send back an ACK and a request (atleast 15ms + cpu time), then the time for the DB to process the query, and then the time (15ms + cpu) to get the data back, and a bit more to ack, and close the connection.

This is ofcourse not counting the authentication (username/password) to the database, and no encryption (ssl handshakes/DH or whatever is needed).

*half of a round trip time, assuming the route there and back is symmetrical (half the time to get there, and half to get back... cpu processing time for ping reply is very short)

• The problem of three-way-handshake could be encountered with persistent TCP sessions. –  Michuelnik Oct 15, 2012 at 12:57
• @Michuelnik, could you please elaborate? I would really like to understand this whole thing and find the best way to minimize the latency for querying the DB. –  Phil Oct 15, 2012 at 12:58
• 2 Sadly, most software (atleast web apps) dont's support this :/ But the idea is, to establish the connection (once) to the DB, and keep the connection running (open), and just keep sending queries/getting replys over one, constantly open connection. This eliminates the need for tcp handshakes, authentication, etc. each time. –  mulaz Oct 15, 2012 at 13:01
• mulaz, thank you for explaining. I'll be working with Python so we shall see how it goes. ;-) –  Phil Oct 15, 2012 at 13:42
• Don't forget the size of the request and the reply. For example, over a 1MB/sec link, a 100KB payload would take an extra 100ms to transport. –  Dustin Boswell Jun 26, 2014 at 3:01

The ping time is round trip. If you think about it -- how could it measure the one way time? So it will take 30ms plus the query time.

• 1 I'll just add that is probably going to take a bit longer than just the 30 secs +query time. since Ping is ICMP and your DB connection is TCP, you will also have setup/handshake, and DB Connection initiation etc in there as well –  Doon Oct 15, 2012 at 12:51
• @Doon: Which could be "avoided" with persistent TCP/database connections –  Michuelnik Oct 15, 2012 at 12:57
• @Michuelnik, do you think that persistent DB connection is the way to go here? Will it cause some other issues? –  Phil Oct 15, 2012 at 12:59
• @michuelnik , of course. Was just pointing out it isn't as simple as RTT + Query. There are also Limits to Max Speed, per session due to latency, etc..) –  Doon Oct 15, 2012 at 12:59
• @phil In most cases it Persistent DB connections are beneficial, if you are going to do be doing multiple queries. If queries are spread out /sporadic you are tying up resources unnecessarily, but if queries are coming all the time, etc. you will save a non trivial amount of overhead by reusing the existing connection as opposed to opening a new one on each request. –  Doon Oct 15, 2012 at 13:01

The ping time would represent all three together, so it would include the time from app to database server, the time the database query took to complete ( as it creates the timestamp for the response after the query is completed ), and the time it took in transit back to the app server round-trip.

So in short ping is the all-inclusive round trip time it took from a packet being sent to it's response arriving back round-trip.

The "ping" of a service is usually measured in the average of multiple pings, so a ping could mean one single packet sent or it could be referring to the average value of all of the round trip times. And so if you took the ping's round trip time value from the last 100 packets and all together they average 30ms, then you would say "it has a 30ms ping".

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged networking ping latency ..

• The Overflow Blog
• Is GenAI the next dot-com bubble?
• What language should beginning programmers choose?
• Featured on Meta
• New Focus Styles & Updated Styling for Button Groups
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network

Hot Network Questions

• Frozen can safety
• Model and implication of bidirectional time
• Analogies for quantum properties
• Select elements from a list based on alphabetical order criteria
• What does it mean that a language has a "effect system"?
• Advantage of GLMs over transformation models
• Taking a scene from a video I made
• Can a non-trivial continuous function "undo" the discontinuities of another function?
• Prepositional Phrases as Arguments
• Is a Shimano GRX FC-RX600 crankset compatible with Shimano Claris groupset?
• If a secondary target of the Chain Lightning spell casts Hellish Rebuke as a reaction, who does it target?
• Why don't they use guns or lasers on Arrakis?
• Weave two lists, cycling if necessary
• Finding food on the run
• Do "tinker" and "tinkerer" imply "unskillful"?
• Is std::atomic<bool> trivially copyable?
• What are advantages of plasma based weaponry in ship-to-ship combat
• Can I say "keep your head tipping backwards for 2 minutes" to mean to keep the head still and in a state that it is fixed at a tipping position?
• Can you naïvely reduce the dimensionality of a QFT?
• My PhD supervisor is indicating that I should leave my PhD. What do you think?
• Is Batman's utility belt ever missing something he needs?
• Windows Batch Script: how to recursively go through all files except certain file types and folders?
• Why is a post-measurement state a valid quantum state?
• How can I identify the material of this mystery gear?

Database administration Automate critical tasks for database administration

• Auditing and compliance
• Database backup
• Disaster recovery
• Forensic auditing
• Index defragmentation
• Inventory management
• Load testing
• Object level restore
• Server compare
• SQL job automation
• SQL Server monitoring
• Transaction log reading
• Transactional replication

Database development Integrate database changes and automate deployments

• Continuous delivery
• Continuous integration
• Data compare
• Data import/export
• Data masking
• Database DevOps
• Database documentation
• Database modeling
• Dependency analysis
• Developer productivity
• Development best practices
• Documentation
• Multi-DB script execution
• MySQL data compare
• MySQL documentation
• MySQL schema compare
• Object decryption
• Object refactoring
• Packaging and deployment
• Schema and data scripting
• Schema compare
• Script comparison
• SharePoint documentation
• SQL formatting
• SQL Server documentation
• SQL source control
• SQL unit testing
• SSAS documentation
• SSIS documentation
• SSIS package compare
• SSRS documentation
• Statement auto complete
• Static code analysis
• Test data generation
• Text and object search

How to monitor and detect SQL Server round-trip performance issues using custom designed metrics

For every query issued by the application, time is needed to reach the SQL Server and then the time needed for results to get back to the application. As all communication between an application and SQL Server goes via some network (LAN or WAN), network performance could be a critical factor affecting overall performance. Two factors affect network performance: latency and throughput.

The latency or so-called SQL Server round-trip time (RTT) is something that is often overlooked by DBAs and database developers, but excessive round-trip time can severely affect performance. However, to be able to understand why and how the round trip affects the SQL Server performance, as first, it is vital to understand the SQL protocol itself.

A talkative SQL protocol

SQL protocol is designed to rely on intensive communication between the client and SQL Server. It as a very talkative protocol where the client can create a series of requests to the database, each request must wait for the response on the previous one before it can be sent.

Since applications tend to handle their data in a way that minimizes the data volume transferred in each interaction with the database, the result is usually that a significant number of requests/responses are needed for dealing with even modest data requests. In other words, an application that interacts with SQL Server is often forced to spend excessive time waiting for handling all requests/responses duos on the network.

Looking at the diagram above it is clear that even in an ideal scenario, where SQL Server query processing time is zero, the application must wait for at least a sum of SQL Server round-trip times for each query execution. What’s more, in a situation where a single query has to return a substantial amount of data, more than one round-trip could be experienced for that query, which depends on the network TCP protocol. The number of round-trips in such cases can increase exponentially causing an additional increase in the total round-trip time.

The most obvious scenario where inefficiency relating to the SQL protocol is the most noticeable is update statements. Even when a single update SQL query is issued, the application must wait a minimum of one round-trip time for each row updated in the target table.

The more data that has to be updated; the longer time application must wait on the round-trips.

It is now clear that application performance does not depend strictly and always on SQL Server, so let’s expand this a bit to get a better insight into scenarios when the high round-trip times could affect the application performance.

When developing the application, developers usually work in a controlled environment with high-end machines and with the whole development environment is on the same machine as SQL Server, and thus close-to-zero delay in communication with a database. So after the development completes, the application has to be deployed in the customer environment; and this is where the problem starts.

Depending on the type of the application, it can be deployed in the LAN (Local Area Network), WAN (Wide Area Network) or combined LAN-WAN environment

It can often be heard from developers that the application should use LAN or WAN connection with high throughput to get satisfactory performance. However, it is not unusual that the application users start to complain that instead of getting results immediately or in a few seconds they have to wait tens of seconds or even minutes to get results. The problem here is that SQL Server applications are not throughput based, but transaction-based, meaning that it does not move a significant amount of data in a single transaction, but rather small chunks of data in numerous transactions. So for a SQL Server application, the network round-trip (latency) time is often more critical for performance, than network throughput.

Various network round-trip times:

With these network round-trip times, an impact on the application performance for a transaction that requires 500 round-trips can be calculated. For the calculation, some typical round-trip times were used:

So the difference and impact on performance are noticeable. For application deployed in a LAN total network round-trip is 1.5 seconds, while when deployed in a WAN total round-trip is 50 seconds.

So now it is evident that monitoring the round-trip is an essential performance parameter, especially in today’s modern environments that are often deployed in a WAN environment, either by deploying SQL Servers in the cloud or by using the web or mobile-based applications.

Monitoring the round-trip time – Ping

Using the system ping utility is the easiest way to measure network round-trip between two machines. The ping measures round-trip time (latency) for transferring data to another machine plus the transferring data from that machine back to the first machine. Below is an example of measuring ping between the machines, where destination machine is deployed to a WAN and the connection between machines is established using a VPN.

So in this particular case, an average round-trip is 188 ms, which is not a particularly good result.

However, ping results are typical network-related results, and for DBAs, it is more important to measure. For them, measuring round-trip time considers how long it takes to the database to respond to a single application request. In this case, using ping is not the best choice, but it still can be the first choice for initial troubleshooting.

Monitoring the round-trip time – SQL Server Profiler

SQL Server Profiler is a handy tool that can provide much information about the SQL Server, and that includes the ability to track round-trip times. The most important events for measuring the round-trip are SQL:BatchCompleted and RPC:Completed events . However, Profiler can be invasive and when used is sometimes the reason for the degradation of SQL Server performance on a highly active server. It is often a choice for quick troubleshooting, but not a long-term choice for monitoring the round-trip and collecting the historical data.

There are some other custom build options for measuring the round-trip time, but many if not most of those require a significant investment of knowledge, time and energy and are often out of reach for new or less experienced database administrators.

Related posts:

• Monitor SQL Server queries – find poor performers – SSMS Activity Monitor and Data Collection
• Monitor SQL Server queries – find poor performers – dynamic management views and functions
• How to get notifications on SQL Server performance issues
• The process of elimination: How to analyze SQL Server performance with baselines and wait statistics
• How to master SQL Server performance baselining to avoid false positives and/or missing alerts

What's supported

Requirements

Testimonials

Support plans

Renewals and upgrades

Resend keys

What's next

Reducing Round Trips

Andy Warren , 2005-07-15 (first published: 2002-01-24 )

One of the best ways to reduce the load on your server and increase

application responsiveness is to reduce the number of "round trips" your

application makes. A round trip consists of a request sent to the server for

data or an action (select query for a request, insert/update/delete for action).

Every time you do that it takes time and resources. To the client the time

starts when you hit 'GO' and ends when they can proceed. Behind the scenes that

time includes set up time in the app, maybe to build a sql string or some other

task, then network time to send the request, server time to process the request,

network time to return the results, then time to process the results on the

client. Resources used included client RAM and CPU, network bandwidth, and

server RAM and CPU.

So how can you reduce the round trips?

One good way is to try to do as much as you can in one trip. After all, you're

going to have to connect to the server at some point! Instead of running a

single query to return an account or order record, then a second query to return

the associated contacts (or order details), combine the two in a stored

procedure like this:

Create Proc usp_GetMyData @OrderID int as 

--comment here 

set nocount on --save just a little bit more by using this 

select field1, field2, etc, from ordertable where primarykey=@OrderID 

select field3, field4, etc, from orderdetails where foreignkey=@OrderID

By doing this we've saved the time/resources of one entire network trip! In this

example I'm returning 'multiple recordsets' which are cake to handle in ADO. Get

your developers using this method! Remember also that while I used a master

detail relationship to illustrate, there is no requirement that the recordsets

be at all related.

Of course if you don't have much data, you could use the same idea but return

everything as output parameters. This can be tricky and/or aggravating if you'll

have an unknown number of return records that you need to 'flatten' out into

parameters. For example, if you might return up to 10 detail records, you might

end up with a proc like this:

Create proc usp_GetMyData @OrderID int, @Order1ID int output, @Order1Desc

varchar(20) output, @Order2ID int output, @Order2Desc varchar(20) output ....etc

If you've have a fixed set of values this works good. If you will end up having

to spend a lot of work in the client working through all the values to see which

are populated - I think you'll be better off using a recordset.

Next week we'll talk about a couple more ideas for decreasing round trips,

including my variant - not making the trip at all! Got ideas or comments about

this subject? Let me know!

Log in or register to rate

You rated this post out of 5. Change rating

• Performance Tuning

Join the discussion and add your comment

Related content

Discuss content posted by jesper ordrup.

• by administrator
• SQLServerCentral.com

Discussions about content posted by jesper ordrup

Introduction to ADO Part 2 - Recordsets

• by Andy Warren

Part two in the Introduction to ADO series, this beginner level article shows how to open a recordset, how to add and edit records, and touches lightly on how to select the best cursor type and locking mode. Good code samples help you get started fast!

16,569 reads

Reducing Round Trips - Part 3

This week Andy continues his series on how to reduce the number of round trips to the server by looking at some things you can easily add to your applications without a lot of rearchitecting.

8,015 reads

Performance Comparison: Data Access Techniques

• by Additional Articles
• Microsoft SQL Home

Architectural choices for data access affect performance, scalability, maintainability, and usability. This article focuses on the performance aspects of these choices by comparing relative performance of various data access techniques, including Microsoft® ADO.NET Command, DataReader, DataSet, and XML Reader in common application scenarios with a Microsoft SQL Server™ 2000 database.

2,857 reads

Reducing Round Trips - Part 2

Last week Andy started a discussion of the various ways you can reduce the number of round trips to the server. This week he continues by looking at a method he used recently to do client side caching of data to eliminate the round trip altogether. Gotta read it!

9,356 reads

  Windows OS Hub / Windows 10 / 0x80244010 Exceeded Max Server Round Trips: Windows Update Error

0x80244010 Exceeded Max Server Round Trips: Windows Update Error

If you see an error in the graphical Control Panel or Settings Panel when you try to download or install an update, you need to open the Windows Update agent log. This is %Windir%\WindowsUpdate.log in older versions of Windows 7 and 8. On the latest versions of Windows 10/11 and Windows Server 2022/2019, you  should use PowerShell to generate a WindowsUpdate.log file :

I found the following errors in the update log:

Windows Update also has a 200KB limit on the maximum size of the XML file that the client can download from the server in a single trip. The greater the number of updates on the server for the client to check, the larger the size of the XML file to download. If the client has not retrieved the required data from the update server in 200 trips, it will temporarily disconnect from the server and return the error 0x80244010 .

The most common cause of this error is a poor or unstable network connection to the update server, or if the client is trying to receive too many updates (a new WSUS server client, or a computer that hasn’t been updated in a long time).

In most cases, all the user needs to do is click the Retry / Check for Updates button in Control Panel again after a few minutes, or run the command:

wuauclt.exe /detectnow

In most cases, this solves the problem. However, if there are many clients on the network, this method of solving the problem is unacceptable.

You can change this interval using the computer’s Group Policy settings. Open the local Group Policy editor ( gpedit.msc ) or create a domain GPO with the Group Policy Management Console ( gpmc.msc ). Navigate to Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update.

Enable the Automatic Update detection frequency option and reduce the frequency of client synchronization with the update server to 3 hours.

You can also remove the limit on the maximum XML file size that the client can download from your WSUS server. To do this, open SQL Server Management Studio and connect to the SUSDB database. Execute the following T-SQL command:

USE SUSDB GO

Check and remember the current value:

Disable the XML file size restriction: UPDATE tbConfigurationC SET MaxXMLPerRequest = 0

If you do not want to change the settings in the WSUS database, you can clean up the WSUS server by using the built-in Cleanup Wizard (Update Service console -> Options -> Server Cleanup Wizard -> all options -> Next) and remove old, unused, or replaced updates (especially a lot of junk from MS Office updates).

As a result, the Windows Update client will receive much less meta-information from the WSUS server, and its interaction should fit into 200 sessions of 200 KB each.

Also, if there are a lot of WSUS clients in your company, you need to increase the performance of the WsusPool pool in IIS on the WSUS server (can cause the Windows Update error 0x80244022):

WsusPool ( Application Pools -> WsusPool -> Advanced settings ):

• Private Memory Limit (KB) – 0 (remove the 1.2 GB limit on RAM usage by WSUS working processes)
• Queue Length — 25000 (increase the application pool queue length from 10000)
• Limit Interval (minutes) — 15 (increase the counter reset and CPU throttle time from 5 to 15 minutes)
• Service Unavailable Response — TcpLevel (with the old HttpLevel value, an HTTP 503 error is returned to the client.)

If all of the above methods have failed to resolve the update error on the client, try completely resetting the Windows Update Agent settings on the client’s computer and restoring the default settings. After that, do a few cycles of the update check.

Fixing the Read-Only File System Error on Linux

Updating powershell version on windows, related reading, hide library and special folders from file explorer..., prevent server manager from starting at logon on..., how to enable and configure wake-on-lan (wol) in..., fix: your it administrator has limited access to..., fix: remote desktop (rdp) session freezes (disconnects) on....

Great article, thank you.

Much appreciated, this has been bothering me for some weeks.

excellent, problem is resolved now.

Thank you very much!

hero-style, awesome, thanks soooooooooooooooooo much!

Thanks for your post! this helped me greatly along with some changes to IIS after I upgraded from 2012 to 2012 R2 and had nightmares with my WSUS Server. Keep up the good work!

So few sites with info about this error. I only had a single server out of 10 getting it – all others were fine. Attempting to reset WU client didn’t help. In the end, removing the XML size limit worked perfectly. Thanks!

Changing IIS pool setting as described here also helped me to fix the 0x8024401c update error: 0x8024401C means the client response timeout: WU_E_PT_HTTP_STATUS_REQUEST_TIMEOUT — HTTP status 408 — the server timed out waiting for the request.

1) Edit the config file (C:\Program Files\Update Services\WebServices\ClientWebService\web.config) by replacing to 2) Restart WSUS service using PowerShell: Get-Service -Name WsusService | Restart-Service -Verbose 3) New IIS settings: Private Memory Limit (KB) – 0 Queue Length – 25000 Limit Interval (minutes) — 15 Service Unavailable Response — TcpLevel 4) WSUS Administration -> Advanced settings Change the Connection Time-out from 180 to 320

Leave a Comment Cancel Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Current ye@r *

Leave this field empty

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Azure network round-trip latency statistics

• 8 contributors

Azure continuously monitors the latency (speed) of core areas of its network using internal monitoring tools and measurements.

How are the measurements collected?

The latency measurements are collected from Azure cloud regions worldwide, and continuously measured in 1-minute intervals by network probes. The monthly latency statistics are derived from averaging the collected samples for the month.

Round-trip latency figures

The monthly Percentile P50 round trip times between Azure regions for a 30-day window are shown in the following tabs. The latency is measured in milliseconds (ms).

The current dataset was taken on April 9th, 2024 , and it covers the 30-day period ending on April 9th, 2024 .

For readability, each table is split into tabs for groups of Azure regions. The tabs are organized by regions, and then by source region in the first column of each table. For example, the East US tab also shows the latency from all source regions to the two East US regions: East US and East US 2 .

Monthly latency numbers across Azure regions do not change on a regular basis. You can expect an update of these tables every 6 to 9 months. Not all public Azure regions are listed in the following tables. When new regions come online, we will update this document as soon as latency data is available.

You can perform VM-to-VM latency between regions using test Virtual Machines in your Azure subscription.

• North America / South America
• Australia / Asia / Pacific
• Middle East / Africa

Latency tables for Americas regions including US, Canada, and Brazil.

Use the following tabs to view latency statistics for each region.

Latency tables for European regions.

Latency tables for Australia, Asia, and Pacific regions including and Australia, Japan, Korea, and India.

Latency tables for Middle East / Africa regions including UAE, South Africa, Israel, and Qatar.

• Canada / Brazil
• Western Europe
• Central Europe
• Norway / Sweden
• UK / North Europe
• UAE / Qatar / Israel
• South Africa

Round-trip latency to West India from other Azure regions is included in the table. However, West India is not a source region so roundtrips from West India are not included in the table.]

Additionally, you can view all of the data in a single table.

Learn about Azure regions .

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

• Contact Sales

Round-trip times

Modern and redundant network.

Our data centers are located in USA, Netherlands, Luxembourg, United Kingdom, Singapore and Hong Kong. Using the top carriers alongside smart traffic routing, we provide fast network with low latencies.

You can chose the most convenient option to decrease latency and, if necessary, arrange geo-replication of your data to a geographically remote area.

Public network RTTs

Round-trip times in the public network

• SJC1 San Francisco Bay Area, CA, USA
• WAS1 Washington D.C., VA, USA
• WAS2 Washington D.C., VA, USA
• SIN1 Singapore, Singapore
• LON1 London, United Kingdom
• DFW1 Dallas–Fort Worth, TX, USA
• DFW2 Dallas–Fort Worth, TX, USA
• DFW3 Dallas–Fort Worth, TX, USA
• HKG1 Hong Kong, Hong Kong
• LUX1 Luxembourg, Luxembourg
• LUX2 Luxembourg, Luxembourg
• AMS1 Amsterdam, Netherlands
• AMS2 Amsterdam, Netherlands
• AMS3 Amsterdam, Netherlands
• AMS4 Amsterdam, Netherlands
• AMS5 Amsterdam, Netherlands
• AMS2 Amsterdam Metropolitan Area, Netherlands
• AMS4 Amsterdam Metropolitan Area, Netherlands
• AMS5 Amsterdam Metropolitan Area, Netherlands
• DFW1 Dallas–Fort Worth, United States
• DFW2 Dallas–Fort Worth, United States
• DFW3 Dallas–Fort Worth, United States
• SJC1 San Francisco Bay Area, United States
• WAS1 Washington D.C. Metropolitan Area, United States
• WAS2 Washington D.C. Metropolitan Area, United States

Private network RTTs

Round-trip times in the private network

Google RTTs

• asia-east1-b Changhua County, Taiwan
• asia-northeast1-b Tokyo, Japan
• asia-south1-b Mumbai, India
• asia-southeast1-b Jurong West, Singapore
• australia-southeast1-b Sydney, Australia
• europe-west1-b St. Ghislain, Belgium
• europe-west2-b London, United Kingdom
• europe-west3-b Frankfurt, Germany
• europe-west4-b Eemshaven, Netherlands
• northamerica-northeast1-b Montréal, Canada
• southamerica-east1-b São Paulo, Brazil
• us-central1-b Council Bluffs, Iowa, USA
• us-east1-b Moncks Corner, South Carolina, USA
• us-east4-b Ashburn, Virginia, USA
• us-west1-b The Dalles, Oregon, USA

Amazon RTTs

• ap-northeast-1 Tokyo, Japan
• ap-northeast-2 Seoul, Republic of Korea
• ap-northeast-3 Osaka-Local, Japan
• ap-south-1 Mumbai, India
• ap-southeast-1 Singapore
• ap-southeast-2 Sydney, Australia
• ca-central-1 Canada
• cn-north-1 Beijing, China
• eu-central-1 Frankfurt, Germany
• eu-west-1 Ireland
• eu-west-2 London, United Kingdom
• eu-west-3 Paris, France
• sa-east-1 São Paulo, Brazil
• us-east-1 North Virginia, USA
• us-east-2 Ohio, USA
• us-gov-west GovCloud, USA
• us-west-1 North California, USA
• us-west-2 Oregon, USA

Free Global Private Network

Our free global private network connects three continents with 20 Gbps to each dedicated server. The private network is protected on both physical and logical levels to ensure the fastest and safest data transfer. GPN allows our clients to organize the interaction of their servers without the use of additional tunneling and VPNs.

Have a specific project?

Do you have a specific project, need to make changes to a specific configuration, or have different needs? Get in touch to discuss other options.

• Programmer's Guide
• OCI Function Server Round-Trips

C OCI Function Server Round-Trips

This appendix provides information about server round-trips incurred during various OCI calls.

This information can help programmers to determine the most efficient way to accomplish a particular task in an application. A server round-trip is defined as the trip from the client to the server and back to the client.

Enhanced array data manipulation language (DML) capability for arrays

Ability to associate a commit request with a run to reduce round-trips

Optimization for queries using transparent prefetch buffers to reduce round-trips

Using SQL Statements in OCI for an overview and more specific information on tips to reduce server round-trips

OCI Array Interface to significantly reduce round-trips to the database when you are updating or inserting a large volume of data

About Setting Prefetch Count to minimize server round-trips

This appendix contains these topics:

Relational Function Round-Trips

LOB Function Round-Trips

Object and Cache Function Round-Trips

Describe Operation Round-Trips

Data Type Mapping and Manipulation Function Round-Trips

Any Type and Data Function Round-Trips

Other Local Functions

C.1 Relational Function Round-Trips

Describes for each OCI relational function the number of server round-trips.

Table C-1 lists the number of server round-trips required by each OCI relational function.

Table C-1 Server Round-Trips for Relational Operations

C.2 LOB Function Round-Trips

Describes for each OCI LOB function the number of server round-trips.

Table C-2 lists the server round-trips incurred by the OCILob calls.

To minimize the number of round-trips, you can use the data interface for LOBs. You can bind or define character data for a CLOB column or RAW data for a BLOB column.

For calls whose number of round-trips is "0 or 1," if LOB buffering is on, and the request can be satisfied in the client, no round-trips are incurred.

Table C-2 Server Round-Trips for OCILob Calls

About Binding and Defining LOB Data for usage and examples for both INSERT and UPDATE statements

for usage and examples of SELECT statements

C.3 JSON Function Round-Trips

Describes for each OCI JSON function the number of server round-trips.

Table C-3 Server Round-Trips for OCIJSON Calls

C.4 Object and Cache Function Round-Trips

Describes for each OCI object and cache function the number of server round-trips.

Table C-4 lists the number of server round-trips required for the object and cache functions. These values assume the cache is in a warm state, meaning that the type descriptor objects required by the application have been loaded.

Table C-4 Server Round-Trips for Object and Cache Functions

C.5 Describe Operation Round-Trips

Describes for each OCI operation function the number of server round-trips.

Table C-5 lists the number of server round-trips required by OCIDescribeAny() , OCIAttrGet() , and OCIParamGet() .

Table C-5 Server Round-Trips for Describe Operations

C.6 Data Type Mapping and Manipulation Function Round-Trips

Describes for each OCI data type mapping and manipulation function the number of server round-trips.

Table C-6 lists the number of round-trips for the data type mapping and manipulation functions. The asterisks in the table indicate that all functions with a particular prefix incur the same number of server round-trips. For example, OCINumberAdd() , OCINumberPower() , and OCINumberFromText() all incur zero server round-trips.

Table C-6 Server Round-Trips for Data Type Manipulation Functions

C.7 Any Type and Data Function Round-Trips

Describes for each OCI Any Type and Data function the number of server round-trips.

Table C-7 lists the number of server round-trips required by Any Type and Data functions. The functions not listed do not generate any round-trips.

Table C-7 Server Round-Trips for Any Type and Data Functions

C.8 Other Local Functions

Describes for each OCI other local function the number of server round-trips.

Table C-8 lists the functions that are local and do not require a server round-trip.

Table C-8 Locally Processed Functions