Pingplotter ipv67/29/2023 ![]() ![]() If your inbound traceroute traffic is taking a different route back to you than the outbound traffic to the server, this is called an asymmetrical route. PingPlotter can't track the route that your traffic takes on the return trip from the server back to you.Obviously, PingPlotter has no control over these situations. Others don't even echo back ICMP requests (this will show up as a blank entry for that hop). Many routers put a low priority on ICMP traffic. In the analysis of the second graph above, we mentioned that hop 15 is more than likely just a problem with that router not giving us back good information.Your graph results can be affected by a number of things that are out of PingPlotter's control. So which server are you going to play? Obviously it's the second server above. ![]() A lot of network admins will set a router up to drop ping/ICMP packets first if it starts getting busy - have a look here for more details Judging from the numbers for that hop and hop 16, what we're most likely dealing with here is a router that probably has a low priority for ICMP packets. "What about that 11% packet loss at hop 15?", you ask. If you didn't have that fat pipe installed (and were instead running a modem) you'd probably be running at about 220-230ms for your latency. So you've got a 120-130ms ping to hop 16. When you factor in speed of light latency, you can account for about 40-50ms of your latency to hop 17 with that hop across the backbone between hops 11 and 12. ![]() Notice from the DNS names that you actually go from Seattle across Global Crossing's backbone to Cleveland. ![]() Let's look at that connection between hops 11 and 12. We don't even make it over 40ms until hop 12. Really, anything under 150 ms is a great connection. Combined with the bandwidth saturation we're getting on the DSL line itself, it's best to try later. Once you make it to the server at hop 16, not only is your latency still way up there, but you're getting 9 to 10% packet loss. All the sudden your latency goes up to 400+ms at hop 15. Where we start running into problems is when we get off of BestPeer and hit the Mediagods domain that's hanging off the DSL link. From the DNS on hop 8, we can see that hop is a gateway (thus the "dsl-gw7" part of the name) to some DSL customers. No problem there, there's plenty of bandwidth between those two providers since the time doesn't really go up. Notice that you move off of LevelX's backbone into BestPeer between hops 8 and 9. Besides the red lines on the history graph, you can also see your packet loss in the PL% column and, if you look at hop 16, the horizontal red line contains your packet loss value.ĭigging a bit deeper, you can see that you're running under 100ms all the way down until you hit hop 15. When you're running across a big open area and then all the sudden *blip,* you're on the other side (and most likely dead), that was more than likely caused by timeouts, or packets you didn't get to (or back from) the server. Packet loss is the bane for most online games. Every time you see red on the history graph you had a timeout, or in other words there's dropped packets. This doesn't look too bad until you get to hop 15 and start looking at the history graph. Let's analyze both and see which server you want to play on. When you get back to your computer you'll have two graphs that look similar to the ones below. You then go get yourself a Diet Pepsi, do some stretches or whatever in preparation for a night of gaming. Then, start a trace to your second server's IP address using the same settings you used for the first server. 2.5 seconds is a good value for the trace interval, and the # of times to trace should be unlimited (we're gonna watch it for awhile). You'll launch PingPlotter, enter the IP address of the first server into the Address to Trace box and click the Trace button. The first thing you need is the IP addresses or DNS names for the two servers. We're learning! The same topics we go over in this section, as far as graph interpretation, are also applicable if you were trying to figure out why a connection to a specific server you were just playing on is so cruddy. We realize some folks aren't going to be so patient as to use the method below to decide which server they're going to play on. You've got two servers that are running the same maps you like to play, so the only issue you have is which one out of the two is going to give you a better connection. For this example, let's assume you're an online gamer - specifically, a Quake III player (though the following is representative of any online game really - MMORPG, RTS, racing sims, fighting games, etc.). ![]()
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |