I.e. You are showing that it worked on one occasion.
Absolutely true; that's why I wrote "during those 300 seconds". (And the most recent iperf test also looks absolutely fine.)
Cttached iperf3 result for 508 bytes packet size. Looks good and I am not happy about that
True also.
Yet, absence of evidence is not evidence of absence. Depending on how often the issue occurs, one might have to run quite long tests to reproduce the glitch.
For example, whenever I build a new desktop or server machine, I always run memtest over the weekend (48 hours or longer).
I found many discussions about clockdrift in games and there is no answer what actually causes it.
Basically, each computer has an internal clock (actually several, but let's concentrate on the one we call "real time clock", that measures wall clock time; there is also a battery-backed up Real Time Clock that maintains a rough real time clock when the computer is powered off on all x86-64 based machines, but that's not relevant here).
It has limited precision, and may drift somewhat (due to temperature and other reasons). If two different computers clocks differ by 1%, it amounts to
over 14 minutes per day. If the game server and the client machine disagree on the time, odd things may happen (because clock drift is a bit difficult to handle in the physics modeling, without requiring every single event to be routed through the game server).
Depending on the processor, the CPU cycle counter may not be stable (the rate may vary too often to measure real time effectively), so typically a HPET (High Precision Event Timer) is used. Unfortunately, depending on the processor (and possibly motherboard), the HPET timer may not be stable either. Because it is up to the operating system –– Windows, in your case –– to choose what to use, I do believe you can experiment by disabling or enabling HPET.
On servers, Network Time Protocol is often used. On my own Linux machines, I also use it. It keeps the time synchronized to free time servers on the internet; I use the
NTP Public Services Project localized NTP pools (fi.pool.ntp.org in my particular case), but many ISPs also provide their own NTP servers (often on the main gateway), because it is quite lightweight protocol. For example, this particular laptop is right now about 3ms ahead of the pool servers. (Linux (and Android and MacOS) uses a funky NTP time adjustment scheme, where the apparent clock rate is sped up or slowed down to eventually match, instead of "jumping" the clock to immediately match the NTP servers. I suspect, but cannot confirm, that Windows does the same.) I do recommend having this enabled in Windows, too, to keep the clock difference between your machine and game servers to a minimum.
It happens especially at peak times for internet congestion (on weekends I have most extreme cases, there is no point to start any match because I know already what I can expect).
You need to redo the iperf tests at a peak time for internet congestion, and preferably immediately after an (attempted) online gaming session. This best simulates a continued gaming session, and should have the best chance of capturing network glitches, if the problem is (even partly) due to networking issues.
Depending on population density, the congestion could be at the 'last mile', i.e. the actual ethernet or fiber capacity to your house/building is limited by the very first connection outwards, as it is serving too many customers. It may be the same hardware regardless of the ISP (simply because it is the only cable coming from the neighborhood hub to your particular home), and just does not have enough bandwidth to serve you and your neighbors; especially so for FTTP.
For 4G/LTE, the situation is a bit different, because there the congestion depends the base station your modem connects to, and using a bit better antennae can boost your connection slightly over others'. (Modems supporting dual antennae can often much better deal with reflections, when there is no clear line of sight to the base station.) But there too it depends on how many human customers the base station serves; the physical bandwidth is limited.