Round-trip time

from Wikipedia, the free encyclopedia
The articles round trip delay and round trip time overlap thematically. Help me to better differentiate or merge the articles (→  instructions ) . To do this, take part in the relevant redundancy discussion . Please remove this module only after the redundancy has been completely processed and do not forget to include the relevant entry on the redundancy discussion page{{ Done | 1 = ~~~~}}to mark. Minderbinder 20:05, 2 Aug 2020 (CEST)

The packet round trip time or round trip time ( RTT , English for round trip time ) indicates the time that a data packet ( datagram ) needs in a computer network to travel from the source to the destination and back. It is therefore the sum of the running time from point A to point B and the running time from point B to point A.

Application of measurement

This method of measurement is therefore used much more frequently in practice in network technology than the latency time (only measured in one direction) (or delay time), because no time synchronization of the two end devices involved is required. When measuring RTT, however, it should be noted that in many cases asymmetrical routing (e.g. due to BGP policies ) can result in asymmetrical delay times and half the RTT therefore does not necessarily provide a good approximation for the delay time in one direction. In addition, different protocols can be handled very differently on the way, especially through policy-based routing , so that an RTT measurement basically only applies to the protocol used.

The RTT is continuously measured by the Transmission Control Protocol (TCP) , for example , in order to determine when packets should be sent again after no confirmation. This measure serves to adapt the protocol behavior depending on the available transport capacities and with changing load conditions. A simple way of determining the average RTT is to measure the time difference between transmission and arrival of the confirmation of several packets and then to average over several measurements. Packets that had to be sent several times (timeout) should be ignored in the invoice, as it is not always clear which packet the confirmation was for.

Contrary to the definition in the introductory section, the RTT is usually not measured with a packet sent back and forth. Instead, one usually measures in such a way that host A sends a special packet to host B (e.g. ICMP ping). Upon receipt, host B immediately sends a response packet back to host A. The time between sending out the first and receiving the response packet is then the RTT. This minimal difference is of course more of an academic nature and only plays a role if the sending of the response packet is significantly delayed at host B, for example due to a greatly increased CPU load.

End users can measure the RTT for ICMP, for example, with the ping tool , which is included with most modern operating systems.

Typical measured values

Typical RTT values:

Local area network ( TCP ), 1500 byte packet
100BASE-TX Ethernet <1 ms
WLAN 802.11b 10 ms
ADSL 6000 without Fastpath 40 ms
ADSL 2000 without Fastpath 55 ms
ISDN (significantly shorter with small packets) 200 ms
UMTS 300-400 ms
GPRS 700-1000 ms
Internet ( IP ), beyond the router
within Germany <50 ms
United States 100-150 ms
Far East up to 300 ms

RTT vs. Ping

Ping tests routes in the network or the routing in the network and gives the status mostly in the form of ICMP error messages, packet loss rates, sequence numbers, information about packet sizes / fragmentation, time-to-live and etc. a. also the round trip time (the exact information depends on the ping program or operating system used). If you want to measure the RTT in a meaningful way, you should not rely on ping alone, as the ICMP protocol used by ping is routed or prioritized differently in many networks compared to the usual TCP data traffic. The RTT must also not be halved in order to determine the running time of a route. Otherwise an average value would be obtained. Architecturally, TCP can never guarantee that the return route of a packet uses the same route.

Individual evidence

  1. RFC 6298
  2. Christoph Lüders, Martin Winkler: Ping-pong. in: c't . Hanover 2006, 23, p. 199. ISSN  0724-8679