Different sources show different results at same target.
A colleague and I are pinging the same website from different locations (geographically, we are about 30 miles apart, both pinging a server about 1500 miles away) at 15 second intervals. Oddly, I will show a whole spurt of packets dropped by the target server during a particular period, indicating server difficulties, but my colleague may not show that at all. Why would this be? We want to reliably know when the server is having problems, but these differences make it difficult to be sure.
This definitely sounds like the RETURN route. Due to the way traceroute is implemented, PingPlotter can only find the route a packet follows to get TO the destination, not how it gets back. What's more important is that the route your packets take TO the server from your computer is more often than not completely different than the route taken FROM the server back to your computer. This is what's known as asymmetrical routing.
So in cases where you see only the final destination with packet loss, the return route may be significantly different when coming back from the final destination than it is when coming back from the hop right before it.
The best way to troubleshoot this is to have access to traceroute from that server. This isn't feasible for most situations, but if you have a business relationship with them, you may be able to get them to run a traceroute back to you so you can see where the packet loss is occuring. Some sites even have tools installed for you to check this yourself. For instance, TheNetGamer.com provides this type of tool for their customers.
To that end, here is a nice page of servers that will trace back to you located at traceroute.org. In your troubleshooting you would want to select a traceroute server listed there and use the IP address you believe to be the problem, i.e. the one you're tracing to in PingPlotter. If that trace returns an abnormally high ping also, you have found the problem router, and it is on the TO route. If not, it is time to turn your attention to the FROM route. If you suspect a problem on your return route, you can use one of the server-side traceroute facilities (if one exists at that end point) to find out what the route BACK is. This should point to the problem router. If not, then unfortunately you've found one of the weaknesses of trace route troubleshooting in that it only shows the route in one direction.
There are also very rare instances where you may have ran into a multi-homed router. This is where multiple backbone providers are using the same router. These are pretty rare, but have been becoming more and more common (F5 networks makes one of these monsters that can handle insane amounts of traffic) as providers consolidate/merge/etc. If you are at a total loss trying to find the problem, you may have run into one of these puppies. If you suspect this is the case, email us your trace data at email@example.com and we'll try and take a look for you.