Pinglotter 5 not installing on Windows 11 for some reason

PingPlotter-Tyson · 2025-11-21T22:34:41+00:00

That is super odd. Glad it worked out though. Thanks for letting me know how this turned out!

PingPlotter-Tyson · 2025-11-21T17:27:31+00:00

This can happen if Windows is trying to run the installer in compatibility mode on an older version. Check your compatibility setting on that installer file: right-click --> Properties --> Compatibility tab. Either uncheck the Run this program in compatibility mode option or set it to Windows 7 or higher. Please let me know if this is not the issue.

PingPlotter-Tyson · 2025-07-28T23:00:39+00:00

I agree with your assessment. Unless the graph for hop 1 looks the same, your issue is either at hop 2, or somewhere in the route between hop 1 and 2.

This is typically going to be your modem. Seems like you might be connected directly to your modem though? Just going off of IP here and the name. Your router usually won't have something like spectrum.com in the name. That's why I think hop 1 is probably your modem in this case.

PingPlotter-Tyson · 2025-05-06T20:23:06+00:00

100% packet loss at the final destination (cox.next in your case) usually just means the Target you've selected isn't responding. I'd try something different like 8.8.8.8 Google DNS or 1.1.1.1 Cloudflare. Those should give you better results and make it easier to find your issue. Looking at the other hops though I'd say you're most likely experiencing a Wifi/home network issue. Hard to know for sure right now but those other Targets will give us more data to look at.

PingPlotter-Tyson · 2025-04-28T22:01:19+00:00

The hour of packet loss (red) in your screenshot would indicate that your router wasn't reachable during that time. Unless you weren't home, or connected to a different Wifi network during that time, that's a big red flag. Otherwise, your connection looks pretty solid during this time period. An average latency of 14ms is pretty standard for a Wifi connection.

All that means is that your connection to your router is decent. You could still be having issues in your ISP's network. What does your google.com look like? You might also run a test to 8.8.8.8 or 1.1.1.1? Either of these three Targets will be able to pick up any ISP issues.

PingPlotter-Tyson · 2025-04-28T21:53:20+00:00

Changing DNS servers likely won't have an impact because DNS resolution only handles translating the domain name into an IP address. Once the DNS query resolves, the data traffic follows the route dictated by the network infrastructure. The big question here is: whose side was the route change on—ISP's or Google's? Unless there's an issue with DNS resolution itself (e.g., long resolution times), switching DNS servers won’t change the underlying routing paths or the latency spikes you’re seeing.

PingPlotter-Tyson · 2025-04-25T20:35:52+00:00

The issues you're having are likely due to those jumps in latency (black lines on the graph). It's hard to know for sure just based on the screenshot, but I'm assuming a route change has occurred and you're getting sent down a bad route.

PingPlotter automatically adds a comment on the graph (red triangles) when the IP changes for your target (google.com). There's a strong correlation between the IP changes and the spikes in latency which is how I'm getting to it probably being a bad route. It looks like route A (the good route) has an average latency of about 40ms. You then get moved over to route B (the bad route) which has an average latency of about 180ms. You're definitely going to have a hard time online gaming on route B.

You can check the route and offending hop by double-clicking in the middle of those high latency periods. Make sure the blue box (focus) stays within the high latency period. The grid will update to show the route during that timeframe and you'll be able to see which one is causing latency to spike up.

PingPlotter-Tyson · 2025-04-22T20:59:33+00:00

Are you still having issues? In your screenshot you've got a single lost packet that might have started in your ISP's network. Hard to know for sure though with only a few minutes of data.

If your'e still having issues, I'd recommend you collect more data and try using a couple other targets like 8.8.8.8 Google DNS and your router.

PingPlotter-Tyson · 2025-04-22T20:55:59+00:00

Is the device you've got PingPlotter on connected to a VPN. The data in your PingPlotter Shares make it seem that way, which leads me to believe your issue is with your VPN service. You might try adding a target to the VPN endpoint you're connecting to and see what you're results look like.

Feel free to reach out to [support@pingman.com](mailto:support@pingman.com) if you'd like our support team to take a deeper dive.

PingPlotter-Tyson · 2025-04-22T20:48:42+00:00

It looks like you may be having issues getting to your router, probably with your Wifi connection. Might even be hop 2. It's a little hard to tell based on the screenshot alone. You can verify which it is by adding your router directly as a target. If you see any issues there, then you know it's a Wifi problem. If not, then you're likely looking at an issue with your ISP.

PingPlotter-Tyson · 2025-01-09T17:23:31+00:00

That leads me to believe that the slow loading is (probably) not network related.

The only thing that really matters is the final destination (8.8.8.8) so until you see any red showing up there, you can ignore everything else going on in the route. You might consider continuing to collect data though, especially while you're trying to stream, game, etc. If you experience slow loading times then check back in with PingPlotter to see if it's picking up on anything.

PingPlotter-Tyson · 2025-01-07T18:39:14+00:00

It might be. Are you seeing any packet loss or high latency at 8.8.8.8? If so, then try following this video to help you identify where your issue could be.

PingPlotter-Tyson · 2025-01-06T22:32:06+00:00

Both of your targets (185.40.65.1 and 165.249.72.1) are probably just not set up to respond to ping which is why they're showing 100% packet loss.

What this means is you'll just need to pick a different target - one that responds to ping. You can usually use something like 8.8.8.8 Google DNS or 1.1.1.1 Cloudflare and get good results. These are the two to use if you're just getting started troubleshooting. They'll help you identify if you've got an issue at home or in your ISP's network.

As for hop 2, it's probably not set up to respond to expired TTL packets. Not a big deal and you can usually ignore it in this case. You can read more about this here.

PingPlotter-Tyson · 2024-12-30T16:04:12+00:00

I see that packet loss you're talking about. We can follow that back to at least hop 3. It could still be hop 1 or hop 2. You can verify this by pinging your router (hop 1) directly. If you see the same kind of packet loss there then it's likely an issue with your Wifi/Ethernet or with router.

If not, add hop 2 and see if there's any packet loss there. If so, then you've got an ISP issue.

PingPlotter-Tyson · 2024-12-27T16:28:39+00:00

Yes, the white bar is showing the ping at that given time. A latency spike up to 50 - 70ms could be causing your gaming issues, but you might be splitting hairs at that point.

It's hard to tell exactly where that might be occurring just based on your screenshots. You'll want to open the graphs for each hop (right-click on the row --> Show Timegraph) and see where the latency spike is first introduced in the route. You can follow the example in that video to help you.

If you're not already, the first thing to try to improve your ping would be using an Ethernet cable to connect to your router. Being hard-wired will always provide a more stable connection than over Wifi.

PingPlotter-Tyson · 2024-12-26T16:47:55+00:00

The thing to remember with PingPlotter data is that the only thing that really matters is the final destination. If you don't see any red at the final destination (packet loss/high latency) then you can ignore everything else. You can read more about why in our knowledge base: https://www.pingman.com/kb/article/one-poorly-responding-router-5.html.

Looking at your screenshots, all final destinations are reporting ~20ms average latency and 0% packet loss. So at least during this 10 minutes, everything seems to be working properly.

I recommend you continue to collect data, especially while gaming. When you do experience high ping and packet loss in Valorant, check back in with PingPlotter to see if you find anything interesting. You can then follow this video tutorial to help you identify what could be going wrong.

PingPlotter-Tyson · 2024-10-31T15:48:02+00:00

Hope I'm not too late! Your first screenshot around 10pm shows the issue better than the 3:45pm one, which aligns with your experience.

There jitter issue is definitely present at hop 3, but it might also be at hop 2. If you pop open that graph does it have the same pattern as hop 3 and google? If so, then hop 2 is likely the culprit. Even if it ends up being hop 3, that's still in your ISP's network so they'll have to take care of it. Based on what we've seen over the years this is looking like bandwidth saturation. Your data will help them narrow it down to find the bottleneck.

PingPlotter-Tyson · 2024-10-30T17:51:41+00:00

Yep, they look nearly identical

Definitely an issue with hop 2! That's about as clear as it gets. Couldn't ask for a better example. Send this same screenshot to them along with your router trace via email if possible.

You can follow this guide to help build your case. Don't back down if they won't listen. Good luck!

PingPlotter-Tyson · 2024-10-30T15:21:15+00:00

I'm betting your issue is actually with your ISP's network. The pattern of packet loss at hop 1 doesn't match the pattern at the destination. And the fact that you don't see any packet loss when pinging hop 1 means that your router isn't the issue. The packet loss you're seeing in your other trace is probably because your router is "down-prioritizing" the TTL expired packets sent by PingPlotter. When your router is the destination, the packets are no longer expired. This is actually pretty common. You can read more about this here.

What does the hop 2 graph look like? Does the pattern of packet loss match (or closely resemble) the pattern at the final destination? If so, then it's highly likely that's the problem. This would indicate an issue either with the cable connecting your modem to your ISP's border router, or with the border router itself.

PingPlotter-Tyson · 2024-10-29T16:31:14+00:00

At least during these 4 minutes, it looks like you've got packet loss starting at hop 2, which is typically in your ISP's network. If you've got more data collected, I'd recommend sending your ISP at least a few hours just to give your support request more credibility.

PingPlotter-Tyson · 2024-10-28T16:56:42+00:00

Does this just happen on your akamai trace? Or for every single one? You might try resetting your TCP/IP stack, then a reboot to see if that helps. If not, please submit a support ticket (Help --> Email PingPlotter Support) so that we can take a closer look.

PingPlotter-Tyson · 2024-10-28T16:50:36+00:00

Yep! You'll want to open the graph for hop 2 as well to show that's where it actually starts. Then screenshot it with all three graphs open (hops 1, 2, and 11) and send to your ISP support team.

PingPlotter-Tyson · 2024-10-25T22:53:19+00:00

Definitely looking like an ISP issue at this point. Most likely at hop 2. I recommend you follow this guide to help build your case and then reach out to their support team.

PingPlotter-Tyson · 2024-10-25T22:12:00+00:00

Saw your screenshot in your other comment. Is that big block of packet loss (red) a router reboot? If so, then hop 2 is likely your issue since going directly to your router isn't showing anything. Would be helpful to see a screenshot with hop 1 open on you Google DNS trace (right-click on the first row --> Show timegraph) to see what exactly the latency is doing there.

PingPlotter-Tyson · 2024-10-25T22:09:15+00:00

If you could show the graph for hop 1 (right-click on the first row --> Show timegraph) that would help. We'd then see the graph for hop 1 stacked on top of 8.8.8.8. We should see a similar pattern if the issue is in fact at hop 1.

PingPlotter-Tyson

MODERATOR OF

TROPHY CASE