Hey there Jaccsun,
Thanks for writing in - I'm sorry your connection has been acting up lately!
There definitely seems to be intermittent packet loss here, indeed, too much to work through (especially when playing competitively). However, it's a little difficult to determine where the 2% packet loss (from Google.com) is originating from in this image. The initial hops and intermediate hops seem to be down-prioritizing ICMP echo replies
or where TTL = 0 - this behavior affects only the returning packets, and is the reason these large amounts of packet loss don't show up at the final destination
. More information about this topic can be found here: http://www.pingman.com/kb/41?pk_vid=054ba05e0955c26b1568053088ca2336
What we're looking for is a pattern of 2% packet loss
carrying through from an earlier hop to the target - and since these earlier hops are down-prioritizing our requests, this is masking the real
packet loss (for the forwarded packets
). In order to separate these results, we need to use ICMP echo requests
in order to receive data from those devices.
To troubleshoot this issue further, you'll need to trace to each hop (starting at hop 1) and compare the pattern of packet loss in that trace session, to a separate trace session for www.google.com.
For example, if a trace to hop #3
shows 2% packet loss
, and a separate trace to Google
shows 2% packet loss at that same time
, you've likely found the offending hop!
If you're interested, we cover a few more details about interpreting PingPlotter results here: https://www.pingplotter.com/wisdom/article/latency-packet-loss.html
I hope that helps - if you have any further questions, or need assistance with something else, please feel free to reach out!
All the best,