Hi Imme,
Thanks for reaching out! I'm sorry you've been having so many difficulties getting this issue resolved with your ISP.
I can't say for sure using only screenshots, but there does seem to be a problem originating from hop#2. This could be a issue with the line between #1 and #2, or an issue with the device itself.
If you could please export your file and send it over (either through this post or send it to support@pingplotter.com), then I'll be able to pull that data in and take a closer look. To export, click File -> Export SampleSet.
If the device at hop#2 is
not in your local network and your ISP isn't convinced your local network is healthy, here are some recommended steps you can take to narrow the results and prove your case:
1. Trace to the
site or
service you are having issues with (Netflix, Fortnite server, Zoom.com, etc.)
2. You can also trace to your
ISP (generally hop #2 or #3). A "WHOIS" google search on the IP address usually provides results about who the IP address is registered to.
3. Trace to your
router (Usually the first hop in the route - 192.168.0.1 or something similar).
4. Trace to your
NIC (Network Interface Card). In Windows, run Command Line as administrator and type
ipconfig and look for the IPv4 address - this is your NIC IP.
5. Finally, trace to your
loopback address (127.0.0.1). This lets you verify that any issues you are seeing are not related to the hardware or IP stack on the machine you're using.
6. Trace to a reference address like google.com
7. After 24-48 hrs, in your All Targets Summary tab, double-click each entry to bring up their Timeline Graphs.
8. Scroll through the graph (using the slider at the bottom) and when latency or packet loss occurs, compare the graphs and look for where the issue
begins.
You can also share your results with us by changing your
Focus field to reflect
24 hours (or more), then clicking
File -> Share -> Create Share Page - then,
copy/paste the URL of your share page in your reply.
-
PingPlotter Sharing Tracing directly to intermediate hops is important because some devices can down-prioritize ICMP requests where TTL=0 (forwarding the packet, but dropping the response to PingPlotter). Since this shows up as packet loss, and if many intermediate devices are doing this, it's difficult to tell if it's
TRUE packet loss.
Here are a couple of articles which talk about this in a little more detail:
-
Interpreting Latency and Packet Loss -
Requests/responses/and behaviors Let us know if this leaves you with any questions!
All the best,
Austin BernerSoftware Support Technician | Pingman Toolssupport@pingman.com | (208) 345-0030
Previous Topic
Index
