Hey Ben,

There are a couple of points you mentioned in your posts that I would like to hit on first before getting to your data.

You asked if switching from ICMP to UDP or TCP shows up in the logs. They actually don't. The best thing to do is to just right click in the graph for the final hop at the time you switch packet types and click "Create Comment" and then type in a comment that will let you know what happened at that time (i.e. Switched to UDP Packet type).

I also wanted to let you know that "Winpcap" is a software required to run TCP packet type. This is a really small software that runs behind the scenes. You can download it at http://www.winpcap.org/.

The last thing I wanted to hit on before getting into the meat if things is what a packet and packet loss is. When you do a trace (either a ping, tracert or PingPlotter trace), you are sending out a "packet" (otherwise called a request or ping) to another device which asks for that device to respond back. Once the "packet" is received back from the device, the time it took to send and receive the packet is measured in "latency". If a request has been sent out, but never comes back, it is considered "packet loss". If you send out 10 packets, and 9 packets make it back then this would be represented as 10% packet loss (1 out of 10 didn't make it back). What sets PingPlotter apart from a command line ping or tracert request is that PingPlotter sends requests at a determined interval - and continues until you stop the trace. It also sends requests to every hop on the way too, so that you can view the data for latency and packet loss for those hops as well (to determine where the issue is coming from).

Ok, so now for the trace results for this latest trace you did. I can see a couple of issues present in this trace. The first issue is the first hop (which should be your modem inside your network). I can see some packet loss originating from this hop that carries through to the final target (meaning it is influencing the trace). This would indicate something between your computer and hop 1 causing an issue. You will want to try to eliminate variables that could be causing this issue. Between eliminating variables, you should trace again to see if the packet loss (red lines) stop. The first thing would be to switch to a wired connection if you are on wireless. If you are already on a wired connection, try replacing your cable with one you know is good. If you have access to a different modem, you can try replacing the modem. You may even want to see if the first hop looks the same from another computer (to see if it is something within your network).

The second issue I see is starting at hop 3. This *appears* to be the first hop outside of your network (hop 1 being your modem and hop 2 probably being your router). You can see high latency starting at hop 3 (the black line in the graph) that continues on to the final target. For this, you will want to build a compelling case to bring to your internet service provider showing the high latency. Here is a document on how to do this:

http://www.pingplotter.com/manual/building_a_compelling_case.html

If you follow the guide here:

http://www.pingman.com/network-nirvana/

It will help you from start to finish resolve your network issues.

Hopefully this helps out! If you should find yourself with any other questions, or needing any other assistance - please don't hesitate to let us know. You can email us at support@pingplotter.com

Cheers! 

-Phillip