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=054ba05e0955c26b1568053088ca2336What 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.htmlI hope that helps - if you have any further questions, or need assistance with something else, please feel free to reach out!
All the best,
-Austin
Previous Topic
Index
