Packet loss describes an error condition in which data packets appear to be transmitted correctly at one end of a connection, but never arrive at the other. This might be because:
The main observable effect of packet loss is poor data throughput performance. But packet loss is not the only cause of poor performance, so some care is needed in diagnosing whether packet loss is being experienced.
Packet loss exhibits itself in different ways according to the protocol that is being observed or tested. Certain error conditions might affect one protocol but not others.
With UDP (Unreliable Datagram Protocol), used by many online games and streaming media applications, it is impossible to use any system tools to assess whether UDP packets are being lost: only the applications themselves have any knowledge of their network usage. The games or applications might tell you whether they consider they are losing packets.
The ICMP (Internet Control Message Protocol) is used by the ping and traceroute commands. The output of a ping command normally finishes with an analysis of packets sent, returned, and lost. Ideally there should be no losses, and a loss rate exceeding 5% is really pretty bad. The output of a traceroute command will show an asterisk in place of a dropped packet. The ping command is a fair way of establishing whether there is reasonable connectivity with a specific remote host, but it does not indicate at which point in the journey things might be going wrong. The traceroute command can sometimes indicate the point in the route at which packet loss occurs, or begins to occur.
The TCP (Transmission Control Protocol) is used to carry most important data on the internet, including web pages, e-mail, news posts, and file transfers. TCP guarantees end-to-end delivery, and is self-healing. It does this by detecting errors and recovering, which might involve re-transmitting packets after packet loss. This happens automatically, and the applications using TCP are entirely unaware that errors have occurred and been fixed. The applications cannot therefore inform you of any such error conditions. The only thing you might observe is poor upload or download performance: poorer than your cable modem rate cap would suggest.
Although we can't actually count lost packets, we can infer estimates of packet loss by observing statistics of TCP error recovery kept by the operating system.
For instance, open a command window and type the following command:
C:\>netstat -s -p tcp TCP Statistics for IPv4 Active Opens = 201 Passive Opens = 12 Failed Connection Attempts = 0 Reset Connections = 16 Current Connections = 1 Segments Received = 1679 Segments Sent = 1617 Segments Retransmitted = 2
This shows that, of 1617 packets sent, only 2 had to be retransmitted, which is very good. A retransmission rate higher than a few percent would be poor. Retransmission might occur because:
These figures are cumulative totals since the last restart, and might therefore include the effects of some problem long since cured. What matters is how the counters are changing now. It would be better when investigating an upload performance problem to do this:
For instance, here is an example:
Before upload: Segments Sent = 12506 Segments Retransmitted = 485 After upload: Segments Sent = 14214 Segments Retransmitted = 1156 So, segments sent = 14214 - 12506 = 1708 Segments retransmitted = 1156 - 485 = 671 Nearly 40% retransmitted.
This is a very poor result.
Systems other than Windows (e.g. Linux, Mac OS X) have better output to netstat -s -p tcp, and include a count of Duplicates Received as well as Segments Received. A duplicate packet might be received because:
Again, the strategy for investigating a download performance problem should be:
There are only a few things under a user's control that can cause packet loss, and be fixable.
Things that you can possibly remedy are:
The things that you might be able to diagnose but the ISP needs to remedy are:
Most other packet loss occurs within the internet and is beyond the control of the user.
A user has reported experiencing packet loss with the Pace models 2000 or 4000 (but not the model 1000) when performing uploads. In his case, he found that a cure was:
To experiment with MTU settings on Windows systems, try Dr TCP from http://www.broadbandreports.com/front/drtcp.html. Use the Adapter Settings pull-down to select the network interface that connects to the cable modem, type the desired MTU in the MTU box, click Save, click Exit, then restart the PC. For more information on Dr TCP, see http://www.dslreports.com/faq/578.
Return to Index.