Latency is the time delay caused by getting a network message to a remote computer, and getting a response back again. It is normally expressed in milliseconds (thousandths of a second).
High latency times cause noticeable performance degradation in applications such as:
An internet connection consists of a number of transmission hops between routers. Latency times can be made larger by:
In addition, there are additional latencies caused specifically by the DOCSIS cable modem system, which will be discussed below.
Latency between your PC and a remote computer can be measured with the ping command. This can only be executed inside a command window. For instance, if you were interested in the latency to www.jolt.co.uk, you would type the command:
C:\>ping www.jolt.co.uk Pinging clarity.jolt.co.uk [195.149.21.11] with 32 bytes of data: Reply from 195.149.21.11: bytes=32 time=21ms TTL=245 Reply from 195.149.21.11: bytes=32 time=19ms TTL=245 Reply from 195.149.21.11: bytes=32 time=23ms TTL=245 Reply from 195.149.21.11: bytes=32 time=19ms TTL=245 Ping statistics for 195.149.21.11: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milliseconds: Minimum = 19ms, Maximum = 23ms, Average = 20ms
The times highlit above are the round-trip times (RTT), expressed in milliseconds, for a ping request to be sent and replied to, and represent the latency of the internet path between your PC and the specified remote computer. This is a rather unrealistic test, because the test packet size was, by default, too small. To perform a more realistic test, add the parameter -l 1472, (that's a lower case -L for Length), like this:
C:\>ping -l 1472 www.jolt.co.uk Pinging clarity.jolt.co.uk [195.149.21.11] with 1472 bytes of data: Reply from 195.149.21.11: bytes=1472 time=43ms TTL=245 Reply from 195.149.21.11: bytes=1472 time=45ms TTL=245 Reply from 195.149.21.11: bytes=1472 time=45ms TTL=245 Reply from 195.149.21.11: bytes=1472 time=41ms TTL=245 Ping statistics for 195.149.21.11: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milliseconds: Minimum = 41ms, Maximum = 45ms, Average = 43ms
Note the higher RTTs, caused by higher transmission delays from the longer data packets: these are more realistic measurements than the default ones above.
The ping probes and replies are carried by the ICMP protocol. ICMP is carried within an IP packet. The IP protocol has a header overhead of 20 bytes, and ICMP has a header overhead of 8 bytes, making 28 total bytes of overhead within a maximum packet size of 1500 bytes. This leaves 1500-28 = 1472 as the longest ping request which can be made without fragmentation.
The ping request is carried as an ICMP Echo Request, and the reply comes as an ICMP Echo Reply. Firewalls have to permit these classes of packet through at each end of the connection for the ping command to work.
To alter the number of ping trials from the default of 4, use the parameter -n followed by the number. For instance -n 100 will do 100 pings. A long sequence of pings is useful for spotting short-term variations in the latency.
To ping continuously, use the parameter -t. Stop it by typing Ctrl-C.
Please note that, if transparent web proxying is in effect, a ping or traceroute to the remote web server will not follow the same path as the web browser's data. You might get successful pings or traceroutes to the server, but the transparent proxy might be broken. Pings and traceroutes are not affected by proxy settings, and always go direct.
Apple Mac OS 8.x/9.x users can perform ping tests with utilities such as IPNetMonitor.
Apple Mac OS X users can open a command window by launching the Terminal application (in the Utilities folder inside the Applications folder), and then use the ping command. However, the parameters are different from the Windows description above: type the command man ping for details. Alternatively, the Network Utility application (in the Utilities folder) offers a simple GUI version of ping with no parameters.
Apart from normal internet latencies, there are additional latencies caused by the DOCSIS cable modem system. The ping times one gets on tests from a PC to the UBR, for instance, far exceed the times one can normally account for with the short length and high speed of the cable network. The main reasons for additional latency between the cable modem and the UBR are:
Upstream slots: Unlike an ethernet card, a cable modem is not allowed to transmit on demand. A single upstream channel frequency has to be shared by hundreds of cable modems that cannot hear each other's transmissions. If more than one cable modem transmitted at once, the UBR would not be able to understand either of them. So all cable modems must remain silent until they are allocated a time slot (measured with a precision of microseconds) by the UBR. The time-slot allocations are broadcast by the UBR on the downstream as MAP packets, so called because they map time slots to individual cable modems. So a typical sequence might be:
All of this takes time. If the upstream is congested, the UBR might not be able to allocate a time-slot until some considerable time in the future, and poor latency will be seen. If signal conditions on the cable are poor, the bandwidth request or the MAP packet might not be heard, and nothing will happen until the cable modem retries the bandwidth request.
FEC Interleaving: The data transmitted by the UBR on the downstream, and by cable modems on the upstream, carries with it extra information, enabling simple errors (e.g. from noise) to be corrected at the receiving end: this is called Forward Error Correction. To reduce the effect of impulse noise (e.g. from mains switching, typical of domestic environments), the data bits are interleaved (sent out of order) after the FEC is applied, and put back into order at the receiving end before FEC correction. The interleaving and de-interleaving causes some additional unavoidable latency, but usually very little compared to other effects.
Rate caps: The upstream rate cap enforcement in the UBR is like a leaky bucket: the user's PC is allowed to send data in a bursty sort of way, maybe exceeding the rate cap for a few seconds, but the data is buffered in the UBR and transmitted onwards at a steady rate, not exceeding the rate cap. This is like slopping water randomly into a leaky bucket: however much is held in the bucket, it dribbles out of the leak at a fixed rate. But the effect of buffering the data in the UBR and holding it in the leaky bucket is to add dramatically to the latency, maybe thousands of milliseconds. Thus, if latency matters to you, you must avoid sending data faster than your upstream rate cap: you can achieve this only with bandwidth throttling software in your own PC, or by configuring individual applications.
All the above effects combine to give an RTT between the user's PC and the UBR (first hop in the ISP's network) which is usually no better then 7 or 8 milliseconds.
It is important to realise that, unlike dial-up modems, the latency arising from transmission delay on cable modems is independent of the rate caps. One packet is transmitted on the downstream at roughly 30Mbps, regardless of the downstream rate cap. One packet is transmitted on the upstream at roughtly 2.56Mbps, regardless of the upstream rate cap. So ping times on a 128kbps service will be the same as ping times on a 1Mbps service. The different rate caps affect only how often packets are allowed, not the transmission rate of a single packet.
If you think you are having latency problems with a certain remote host, the first thing to do is to identify roughly where the latency is accumulating: a traceroute is the best way to do this.
If the first hop with poor RTT is occurring beyond the last hop in your ISP's network, then there is nothing that you or your ISP can do about it. Latency such as propagation delay on transatlantic or transcontinental routes is simply a fact of life and cannot be avoided: for this reason it is not sensible to attempt using highly interactive games servers on the opposite side of the Atlantic.
If the first hop with poor RTT is occurring after the first hop and before the far edge of your ISP's network, then all you can do is draw it to the attention of your ISP as some sort of internal problem.
If the first hop itself has poor RTT, meaning the latency problem is between your PC and the UBR, then it is necessary to distinguish whether this is something that you can remedy, or whether it is something that your ISP needs to attend to.
Things that you can possibly remedy are:
The things that you might be able to diagnose but the ISP needs to remedy are:
Guidelines from Cisco suggest that no more than 200 cable modems should use a single upstream; however, that figure was estimated on assumptions of domestic usage only: if customers run servers such as P2P systems, upstreams might get overloaded on fewer than 200 users. The capacity of a single cable upstream is just over 2 Mbps, and this is easily saturated by a handful of cable modem users running servers at full capacity.
If you discover that your cable modem is on an overloaded upstream, and if the cable modem is a Surfboard, then you can reconfigure the Surfboard to try a different upstream channel: see Changing the Surfboard's Upstream Channel.
Return to Index.