![]() ![]() The key to analyzing a path issue is to analyze it's performance while real data is transiting it, which can't be done unless you have a packet sniffer/network monitor at each hop and have access to memory, CPU, and throughput counters on each network node (routers and switches) in the path from source to destination. Hop 21 is the destination and, with a 59ms response time, is telling you that the path between the source and the destination is fine. Only when you see those types of results in traceroute should you suspect a path issue. ![]() If there were a problem at hop 12 (as you highlighted) or at any other hop that was affecting the path then you would see a problem at every successive hop and you would see each hop worse than the one before. The fact that hops 14, 19, and 21 have very good response times are indicators that there's nothing wrong with the path. A routers job is to forward traffic and as such, many are programmed to ignore, drop, or give low priority to ICMP traffic directed to themselves. The result from each hop are an indication of how THAT hop is responding to ICMP traffic, it is not an indication of the quality of the path through and beyond that hop. Traceroute sends ICMP echo request packets to each successive hop between the source and destination, incrementing the TTL by one for each successive hop. So pathping shows you what the network is doing over a period of 325 seconds (by default), and tracert is showing you what 3 packets per hop on the network are doing.ĩ times out of 10 trace route results are not an indication of network issues. Your pathping looks good because it is running a large number of queries instead of just 3 that tracert is running. They're spiky because the network is unreliable. That's why the response times go down sometimes. That can't be helping, particularly if there's any NAT or firewalling going on.Īs says, the traceroute ping latency to a given host only indicates the state of the entire network in between the interfaces taken as a whole at that point in time. Plus the fact that you're going through 10+ hops just to get to the Internet. First because air is a hub instead of a switch so you're sharing it with anybody around you and colliding packets, second because CSMA/CA is slower than CSMA/CD, third because wireless is generally half-duplex instead of full duplex, and fourth because there are orders of magnitude higher interference through the air versus copper. You can't really fix it because your medium (the atmosphere) is really awful for transmitting data. Wireless is unreliable and you're seeing proof of that. WISP? Meaning Wireless ISP? If so, there's your likely answer. In other words, while having troubles with my application, if I run a trace at the same time I get the above result while simultaneously pinging the suspect host shows a normal ping. Why does this latency only show up during a trace-route and not with a normal ping? The lack of performance I see in my application coincides with this. The high latency can persist for only a few seconds up to a few minutes at a time.ĮDIT Yes this is a bad example of a trace showing a definite problem, but after repeated tests there is never latency >100ms before hop 9, that's why I thought it could be a problem.Ī pathping during the event produces the following: Source to Here This Node/Link ![]() Pinging subsequent hops after the suspected node gives reasonable round-trip times as well. However, if I directly ping the host everything seems fine (~10ms round-trip). Which seems to indicate that the problem is the host at 10.250.200.1. If I do a trace route you can see the path though the back-haul network: Tracing route to The latency is detectable in online games and other streaming applications. I have been working with my ISP (which is a WISP, actually Fixed Broadband Wireless) trying to figure out why I intermittently get high latency. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |