Thanks for posting in the forum!
Here are the guidelines that I use to diagnose networking issues with PingPlotterGathering data:
I suggest tracing to the following targets
1. Trace to the site
you are having issues with (Netflix, Fortnite server, Zoom.us, etc.).
2. To your router
(Usually the first hop in the route - 192.168.0.1, 10.10.0.1 or something similar).
3. To your NIC
(Network Interface Card) on the machine where PingPlotter is. In Windows, run Command Line (CMD in search) as administrator and type ipconfig
and look for the **IPv4 address** - this is your NIC IP. On Mac click the Apple Icon -> Preferences -> Ethernet or Wi-fi and your NIC IP address will be displayed.
4. Finally trace to a reference target
(Google DNS (18.104.22.168) or Cloudflare DNS (22.214.171.124))Interpreting the data:
1. Gather a good amount of data (24 hrs is ideal and the more intermittent the issue is the more data you need to gather)
2. Open the final hop and zoom out to the 24hr view on the trace graph
3. Look for areas where the background color of the graph is yellow or Pink and where the black latency line is high or has a lot of variation. Also, look for red packet loss bars.
5. Zoom in on these areas using the timeline graph time period drop-down (10-30 Minutes) and scroll (with the slider or the mouse wheel) until you see the incident
6. Change your Focus (drop-down at the top) to something in the 1-5 minute range and double click into the Timeline graph at the end of the incident
7. This will give you the Trace Graph
data for the Focus window
8. Notice where the high latency or packet loss starts in the route and that is generally where the issue is.
9. You can also open a timeline graph for each hop by double-clicking the hop in the trace graph. This can be helpful for finding patterns that go all the way through the route. Narrowing down where the problem is:
* If it's only on the final hop then it's the service
* If it goes all the way back to hop #1 (usually the router) then it's likely within the local network
* If there is a high level (10-100%) of masking packet loss
(lots of red lines and blocks of red) on any of the hops you can open another trace directly to that IP address and compare your results. Generally, it will be clean as it is just down-prioritizing the expired ICMP echo requests.
* If you can trace it back to a hop outside of the local network (usually hop #2 onward) it's the ISP
* If it starts at hop #2 or at the border of the local network it can either be something between hop #1 and hop #2 (ie lines, connectors, modem, etc) or it's the device at hop #2 having issues and you'll have to get in touch with the ISP to look at it.Here's a YouTube video which talks a little more about isolating the problem.
These are the common problems
that you'll see so you know where to look to fix the issue. Whenever you have an incident see if it matches any of these common issues.
This should get you set up to do interpretation but please let me know if you have specific questions, I'm happy to help!