search cancel

In monthly reports, NRTT for server to server traffic is around 60 - 90ms on avg. but should have the expected < 10 ms


Article ID: 19788


Updated On:


CA Application Delivery Analysis MTP (NetQoS / ADA)



In monthly reports, NRTT for server to server traffic is around 60 - 90ms on avg. but should have the expected <10 ms.

  • This is web to SQL server traffic.
  • Wireshark packet analyser says below 1ms in Avg round trip time and SA says 60 - 90 ms


Wireshark does a very poor job of calculating round trip times. Our metrics are accurate and the built in wireshark charts and graphs are not as intelligent as SuperAgent.

For example:

The wireshark tables below indicate that the maximum round trip time was never out of the microsecond scale (less than 1ms at all times)

Here is an instance of a round trip taking roughly 200ms in one of the attached packet captures:

SuperAgent has been specifically designed to calculate round trip from the server to the client. Wireshark is a powerful analyzer, but its strength (indeed it's primary purpose) does not lie in calculating performance metrics.

If you want to know why you are experiencing 200ms RTT on your LAN the answer is delayed acknowledgements.

Read more about the impact of the delayed acknowledgements here:

Or find extracted the relevant info here:

TCP Nagle and Delayed ACK

Transmission Control Protocol (TCP) combines various delays to optimize TCP performance by reducing small packet traffic. On the sending side, TCP uses the Nagle algorithm that delays outbound packets for interactive applications. On the receiving side, TCP uses delayed acknowledgements (ACK) to increase probability of piggybacking the ACK on data that is sent back. However, in some circumstances these two mechanisms can cause a fixed delay of 200 milliseconds resulting in five packets per second throughput. ISA Server does not contribute to this effect, but because of its role in the middle, ISA Server can mistakenly be blamed for it. The symptom can be seen in a network trace when sent packets are acknowledged after a 200 millisecond delay.

The solution to the problem is changing the behavior of the application. For details about how to avoid this issue in applications, see INFO: Design Issues - Sending Small Data Segments Over TCP w/Winsock, at Microsoft Help and Support. For overcoming common TCP performance problems, see Common Performance Issues in Network Applications Part 1: Interactive Applications, on the MSDN Web site.


Component: NQSPRA