Hey Monoxide,

Ouch… these results *definitely* look painful. It's a bit tough to speculate on any specific issues with only the one screenshot with 5 minutes of data, but there *are* a few things we noticed here.

85% packet loss would be a completely intolerable connection - and would *most likely* result in not being able to stay connected to the internet for more than a few minutes at a time. The first question here would be: does it seem like the PingPlotter data you’ve got here is accurately representing your actual experience with this network? If the data presented here is accurate, you most likely wouldn't have even been able to write the post you did.

If this data *doesn't* seem to accurately represent your network experience, then it's possible that something early in your route (possibly the device at hop #1, or something just before it - as this seems to be where the packet loss starts) either has a buggy firmware (where it doesn't like a bunch of outstanding ICMP requests), or is deliberately dropping ICMP packets.

Before putting trust in the data you're seeing, you'll want to make an effort to verify that the packet loss that you're seeing in PingPlotter is impacting non-ICMP traffic the same way it's impacting PingPlotter traffic. If the PingPlotter data doesn't accurately capture the network performance, then it becomes a liability to your troubleshooting effort (as it could be showing you the wrong picture).

Here's a quick test you can run to see if you can gain some additional insight here:

* Close every instance of PingPlotter (or any ICMP tool) on your network.
* Set up PingPlotter to ping only the final hop ("Edit" -> "Options" -> "Packet/Engine Settings" -> "Starting Hop")
* Ping your most reliable server.
* See if you still get packet loss

If not, then turn back on full route. Ping the same target. See if the results change.

Let us know what you find, and we'll be happy offer any guidance we can from there!

Cheers!

-Phillip