

The 'weakest link' isn't the right way to see things.Ī weakest link means that it will be the first thing that breaks and you won't be able to see any information about any other links. If it appears at some other hop, that needs to be investigated too - just because one of your early hops is slow doesn't make that packet loss reading any less important to solve.

If the packet loss appears at a link you know is slow, it still needs to be explained and possibly resolved. When you see packet loss in your route, you almost certainly want to resolve that problem. In reality, you're shooting for 0% packet loss and a reasonable latency across your entire route. The difference between 2% and 4% packet loss needs at least 500 samples to be statistically convincing - the stock traceroute utility does 3 samples, while PingPlotter allows you to do thousands or more. PingPlotter is especially useful here because you can sample enough times to make the differences in packet loss and latency at different hops statistically valid. Is some latency and packet loss at hop 1 does not make the information gathered about hop 7 any less valid. If hop 1 adds 150ms and 5% packet loss, you can still see that some other hop (say, hop 7) adds another 100ms of latency and another 10% of packet loss. The part left off the 'objections' statement you got is that any additional latency or packet loss problems can still be seen - even if your first hop is a modem. This means that a slow connection early in your route will, indeed, add latency at all downstream hops. These statements have enough truth in them to cause a lot of users to leave a network administrator alone, but are targeted to do this - drive an end-user to stop bringing these results.īoth latency and packet loss (the two things that PingPlotter excels in capturing, measuring and displaying) are additive. They say they can't trust PingPlotter data, so stop sending it to them.

They also say that ICMP traffic (like PingPlotter creates) is low-priority and can't be trusted. They say that the first slow hop is the weakest link and invalidates any other data reported. I sent my PingPlotter graphs and information to our network administrators and they responded that traceroute is not an accurate way of troubleshooting networks. Should I trust my PingPlotter results? (Definitely)
