Not so random ping issue.

Don't offer up "help" unless you know how to read a network trace properly.

The 37% packet loss on that AMS hop is not actual packet loss. It's a mitigation technique used by very active nodes. It's only REAL packet loss if it carries on to the following hops.. like the 1% ionface pointed out (who is also trained in reading network traces properly).

The packet loss however, I don't see as a large problem however because it's generally minor and on the final hope (from the first trace), there were only about 5 packets that were never "sent" to begin with, and only 2 of those went missing.

I think you might have a complex issue where it is possibly multiple "problems" which makes it harder to properly diagnose.

The 600ms on the second ping is definitely signs of a problem with your modem, router, or the ISP equipment. I'd reboot all those things (whatever you have physical access to) and check again.

Also, the problem with it being inconsistent could also be due to the servers you are sent to.

GGG has a LOT of servers in a LOT of places geographically. They are used for different things. It's quite possible that for some of your instances, you're being sent to a different server network, or even a different gateway. The only way to know for sure is to pull up the client.txt logs and look at the addresses that you're being sent to for your instances and see where they are.

The address you traced to is in Amsterdam. Doesn't mean every instance you connect to will also be.

Also another thing to keep in mind is that networks are not "static" things. They are constantly changing conditions and other things based on a multitude of factors. They're almost living/breathing animals. Just because it works "now", doesn't mean it will work the same 5 minutes or 5 hours from now. Doesn't even mean the routes you use will be the same in 5 minutes or 5 hours. They're constantly in flux.

The only way to properly diagnose a network is to trace it in real-time when experiencing the issues and looking at the different factors that can be seen. Taking a trace when there are no issues will give you something to compare against, but you'll also need traces capturing before/during/after the issue to compare against. The reason that it has to have a trace with before/during at minimum is that the only way to locate a problem is to be actively tracing when the problem starts... otherwise the "issue" could already be gone.... like taking a photograph of a crash site after they've already removed all the evidence.... it's not very useful. It's much better to at minimum get a photo with all the evidence still there, and even better to get video of the crash in progress, right?