Anyone care to comment on what they would infer from the following:

http://fermat.bemidji.k12.mn.us/plot

Latency does not seem to be an issue, but does anyone see a problem with packet loss? This is tracing every 2.5 seconds.

Thanks

(Edited by Pete Ness 2004-1-7 to change from Image to URL. Our forum software only allows images with specific extensions, and yours doesn't have an extension).

Hi, Tony.

This shows that there is a router in the chain (likely one of the routers on the return path) that down-prioritizes ICMP TTL Expired packets. Unfortunately, this situation masks the fact that things are working pretty well through these hops. We discuss a similiar situation in our knowledgebase at:

http://www.nessoft.com/esupport/?_a=knowledgebase&_j=questiondetails&_i=2

Always remember that if you're not seeing packet loss or latency problems at the final destination, then any of this data in any of the intermediate hops is a priorization / configuration decision that has been made by some router some place in the route. It is only affecting the data reported on intermediate hops, though, and you're not trying to get to the intermeidate hops - you're trying to get to the final destinatino, which is working fine.

Thanks Pete...

I was puzzled by the packet loss when I was seeing such good response times. They seem very consistent. The reason I am watching that particular host is that it is the primary server we connect to for PLATO Learning Networks. They provide online curriculum solutions to which we subscribe and our users have been having horrible problems with timeouts and disconnects. I have been watching every nook and cranny of our network for potential problems (we're getting into the old finger pointing game now) and have tried to stretch beyond our network to find possible issues. This is a 2mb DSL pipe and rarely rises above an average utilization of 50%. Any other ideas are appreciated.

Tony

Can you create another picture that includes the timegraph for hop 4 also (double-clicking on hop 4 will show that graph). Sometimes, you can correlate lost packets in an intermediate hop and latency in a final-destination hop, but that starts to become difficult as the "noise level" of the intermediate hop increases.

In the knowledgebase article I referenced, we talk about correlating real-world application performance against PingPlotter data. This is an important thing to do. Run PingPlotter against that host and then correlate the complaints against users against this data. You can right-click the time-graph in PingPlotter and use the option to create a comment at a particular point in time.

See if you get packet loss to your final destination with PingPlotter at the same time you're getting complaints from your users. If you're *NOT*, then the problems your users are seeing might be server application based, or the packet loss might be protocol dependant.

You can check for server application based problems by looking for another network to connect to. If you get better performance when connecting via a different network, then you can mostly elminate the server application as the bottleneck.

Do you *ever* see packet loss in PingPlotter ot the final destination? If you do, you might be able to correlate these packet loss / latency spikes with earlier hops by turning on the time-graphs for the earlier hops and then mentally "subtracting" the normal packet loss and latency you're seeing. You're trying to determine where the problem originates, and although the "noise level" on the intermediate hops is higher than we'd like, you may still be able to extract a pretty good picture from this data. If you can't correlate final-destination packet loss/latency with your user's horrible problems, though, then PingPlotter likely isn't going to be a lot of help in determining where the problem is.

Hi Pete...

The following is another graph of the latest tracing including hop 4... the last for our ISP:



I intend to watch packet loss on the destination host a bit more closely. I am beginning to wonder if the issue rests with the PLATO software... but they had a tech onsite with a packet sniffer one day and he supposedly observed a high rate of retransmission when sniffing traffic between a workstation here accessing PLATO curriculum on the web server at the end of the above trace. To me there could be a multitude of reasons for this, including the possibility that he may not even have the sniffer set up properly. You get the idea.

This is more of a case for using PingPlotter to demonstrate that there really are no significant problems with the link.

Thanks again for the analysis.

Tony