Version 5 Manual

Interpreting Results - Gamers


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.). 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. 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... but bear with us here. 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.

The first thing you need is the IP addresses or DNS names for the two servers. You'll launch PingPlotter, enter the IP address of the first server into the Target Entry Field and click the Trace button. 2.5 seconds is a good value for the trace interval. Then, start a trace to your second server's IP address using the same settings you used for the first server.

You then go get yourself a Diet Pepsi, do some stretches or whatever in preparation for a night of gaming. When you get back to your computer you'll have two graphs that look similar to the ones below. Let's analyze both and see which server you want to play on.

Screenshot of PingPlotter timeline graph.

Hmm. This doesn't look too bad until you get to hop 4 and start looking at the history graph. Let's take the time line graph first.

Red is bad. Every time you see red on the history graph you had a timeout, or in other words there's dropped packets. Packet loss is the bane for most online games. 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. Besides the red lines on the history graph, you can also see your packet loss in the PL% column.

With the amount of packet loss we're seeing, we don't want to play here.

Now let's look at our second server.

Screenshot of PingPlotter timeline graph.

Now this is more like it. Really, anything under 150 ms is a great connection. We sitting around 50ms. Sweet.

"What about that 11% packet loss on hops 4 - 7?", you ask. Judging from the numbers for those hops and hop 8, what we're most likely dealing with here is a router that probably has a low priority for ICMP packets. 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

So which server are you going to play? Obviously it's the second server above.

Other considerations

Your graph results can be affected by a number of things that are out of PingPlotter's control.

  1. Many routers put a low priority on ICMP traffic. Others don't even echo back ICMP requests (this will show up as a blank entry for that hop). Obviously, PingPlotter has no control over these situations.
  2. PingPlotter can't track the route that your traffic takes on the return trip from the server back to you. 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. By definition traceroute doesn't take these types of routes into account and, unfortunately, PingPlotter isn't going to be able to tell you about problems with the return route in these cases. One clue that this is happening is that you'll have a great trace up until the last one or two hops on your trace. In other words, you don't have an easily identifiable problem at hop X further up the route that is mucking up the rest of the route downstream.

One thing you can do is save your trace data to a text file and post it up on a support message board for the particular game that you're playing. Even better, save off a graph and post it instead. Many savvy game server admins will actually do a traceroute (or even better a PingPlotter trace... *smile*) back to you and be able to tell you if there's problems with a route back to you when asymmetrical routes are involved.

There are some sites that can do traceroutes back to you if you want to investigate on your own. They can be found here.

In closing, we can't emphasize this enough: latency is the bane of online gaming. Much more so than bandwidth limitations. The good thing is that PingPlotter can tell you this latency, and provide you with ammo in the way of trace and graph data when you're beating up on your ISP.