PC performance correlated with relative humidity?

[ultraknur]

CS:GO is CPU dependent, GPU has not much to do and it's barely loaded when playing, at least in my case. As you can see throttling didn't occur. System was stable, I could browse the Internet without problems and meanwhile record it. That is interesting because surprisingly I had quite good gaming experience today but I didn't do any changes in any settings. That is really weird. Maybe in my building somebody switched off a device spreading noise all around, I don't know...

[MK14]

Maybe in my building somebody switched off a device spreading noise all around, I don't know...

Not that I want to encourage you, in any way to go in that direction. But, has any other electronic/electrical device(s) in your apartment and/or any other apartment as part of the same block/building, experienced any 'funny' behaviors that you think are related to electronic interference etc ?

[ultraknur]

Maybe in my building somebody switched off a device spreading noise all around, I don't know...

Not that I want to encourage you, in any way to go in that direction. But, has any other electronic/electrical device(s) in your apartment and/or any other apartment as part of the same block/building, experienced any 'funny' behaviors that you think are related to electronic interference etc ?

I wish I could know that BUT in my building there are a lot of seniors, like 80% of all apartments are occupied by elders and they can't afford modern electrical/electronic devices and still use ie. old cathode ray tube TVs or equipment from Soviet Union times which is definitely not fulfilling EMC requirements. I crashed into the wall and I can't move further with investigation because like I said, I can't find anybody who would do proper measurements. Having something would help me to outsource research by governmental office for electronics and telecommunication but telling them that my PC is affected in the way I can't really prove because it's based on my preception is hilarious. I hoped that somebody here had experienced anything unusual related to electricity/transformers or my harmonics result would indicate something. It seems like moving away from my current location is the only option.

[SilverSolder]

It is overwhelmingly unlikely that the problem is due to external interference.

I'd just take the machine to a friend's place and try it there, and see if it behaves any different.   Also try a friend's computer at your place.

This isn't rocket science, just an annoying bunch of legwork to eliminate the various possibilities.

[MK14]

It seems like moving away from my current location is the only option.

You don't really seem to be producing any actual evidence, of problems with stuff, let alone evidence that it might be caused by EMC issues. What I seem to be hearing from you, is that your computer, *might* be playing up in some visually detectable way, but which hasn't shown up in any computer tests, you have carried out so far.
Then you are going further, and somewhat insisting (it seems to be), that it must be EMC, because of some old CRT TV, or something.

Even if it is 100% EMC. The various logs (such as error ones), tests and things, should be showing things about the problems.

Surely you don't want to move, only to find it is just some problem with your computer's hardware/software/setup/etc, and moving doesn't make the slightest difference ?

[dervu]

Hi. I am this guy that @ultraknur mentioned.
I apparently might have fixed this issue, however that needs long time for confirmation, since with this issue connecting any filter between PC/monitor and socket affects system behavior. Often it improves for couple of days, but then it goes back to previous bad state.
Keeping same setup for long time and then doing some change like connecting some EMI/RFI filter makes noticeable change. That change can be reverted to previous state by disconnecting filter. That would usually work like that for first days, then the longer it is connected the smaller difference gets.
Generally it is better at night and worse at middle of day and evening, but it is not a rule.

It is hard to prove to anyone who didn't saw it for himself. If you play for years and then suddenly you can't do same thing anymore and drop from almost elite player level to like retarded noob level, then you know something is for real.
If logs, errors, statistics do not show anything I bet it has something to do with monitors or just those errors are not accessible for most of us?

System behavior when it is bad:
- Delayed inputs. Clicks are affected but not as much as movement, which is much more evident. It is changing in time, sometimes at same time of day it can be feeling like you drag mouse through mud, then next day it can feel light. Not physically, but in relation to what you see on monitor.
- Usually on lower power usage it is better, but not always. There are days when even on desktop without anything running at all it can feel like moving through mud.
- System is affected both offline and online. Player movement is like running with 50kg bag filled with rocks.
- Unusually fast reactions of enemies, no matter how smart you play and how fast your reactions are

For me this issue was present for very long time, since 2014-2015.
Same for laptops and PCs. Different models, different parts, different monitors.
I moved to different place for couple of months where I could have perfect behavior with exactly the same hardware and equipment, both offline and online.

At place where issue was I tried:
Hardware/electricity:
- Switching ISPs: 2 x FTTH, 1x coaxial cable, 1x 4G
- Replacing all parts in PC, one by one - researched every part model I had and replace by best one I could  get within my budget
- Replaced mousepads, keyboards, mouse
- Replacing monitor - it feels much worse on higher refresh rate monitors
- Replacing display cables HDMI, DP, DVI - difference between HDMI an DP - also used certified DP without 20pin connected
- Connecting only keyboard and mouse
- Replacing power cables to PSU - none
- Replacing powerbars - some temporary differnce
- Connecting to different sockets - no difference
- Checking electricity by electrician - all good
- Replacing old fuse box for new one - slight constant improvement
- Checking harmonics THD level - within limits
- Using different circuits in my apartment - no difference
- Running on double conversion/online UPS connected to socket in online mode for days- some temporary difference
- Running on double conversion/online UPS disconnected from socket for half an hour - some temporary difference
- Running on double conversion/online UPS disconnected from socket and disabled mains half an hour - no difference
- Disabling all devices from sockets for 1 hour - no difference
Disabling old radio from socket for 24hr - only that made significant difference that is comparable to the other place I lived in - now I am checking how long it lasts.
Connecting other devices to same socket, other radios doesn't make it worse.
- Moving routers (they were closer to the faulty radio) to other room (that gave some slight improvement)
- Using Schaffner FN700Z filter - big improvement at first, but then again worse after 2 weeks
- Using isolation transformer - some improvement, seems like works best with FN700Z filter but again it doesn't last long enough
- Using ferrite toroids on cables, not only whole cables, but also separated live and neutral - that made big difference at first, it lasted for a week or more but then it was bad again


From software side:
- Running different Windows version
- Running Ubuntu
- Different drivers for anything, chipset, network, GPU (using DDU for removing old drivers also)
- Updating UEFI, GPU bios, SSD firmware
- Tons of tweaks on Windows, that are on level of placebo
- Disabling all OC/XMP in UEFI
- Checking memory with memtest and system stability for many hours with Prime95, OCCT, Cinebench
- Checking for thermal throttling, recording data with HwInfo during gaming, frametimes ale normal - nothing
- Switching hardware to MSI mode
- Running with cap framerate, uncap framerate, G-Sync on/off
- Disabling all unnecessary things in system.

That list could go like that for couple of more pages, but it is pointless when you don't change anything in system and just move PC in exact same configuration to another place and it works flawlessly.

Also I contacted with regulatory institituion for interference and all they could tell me is that if anything affected PC it would have to be really close.
Without something they could see themselves (such as some artifacts on monitor) or some data on PC related to something happening on their spectrum analyzers, they couldn't proceed further.
But during conversation with them I got an idea to disconnect some devices for really long time. So there goes my old radio - now during assessment time, to see if it holds for really long time.
Also I suspected VFDs in elevator  equipment that was renovated in similiar time my issue started, but that is in progress. That would be only device strong enough to spew wide range of RFI.

I am thinking about building some device that would move small mousepad under mouse to have consistent input and try to record this movement with 240fps camera for two cases:
- When interference is present
- When interference is not present
and compare videos.

It is probably one of things anyone can do to prove this.
Another thing is nvidla latency analyzer in some new high refresh rate monitors. I know one case when it was displaying unusually high numbers for someone who has this issue also.

If conversion from AC to DC in PSU doesn't let any interference in, PC is in kind of faraday cage and monitor is not. Then it makes monitor weakest point, right? If strong enough interference could travel far enough/is close enough to disrupt anything in monitor/PC, then it would be the weakest point to go through that path through GPU, right?
If it was affecting anything without any errors visible on level that we have access to, then maybe it happens on the level that isn't available to regular users? Like something that engineers would only know and could access?
For example error correction at GDDR5 and GDDR6X memory in nvidia cards?
I doubt that manufacturers check their equipment in all EMI/RFI spectrum to check if it doesn't lag. That error correction might have been implemented for other reasons, but who knows if it is not also affected by interference?
It might be rare case, but it is definitely real and really hard and expensive to troubleshoot.

[ultraknur]

System behavior when it is bad:
- Delayed inputs. Clicks are affected but not as much as movement, which is much more evident. It is changing in time, sometimes at same time of day it can be feeling like you drag mouse through mud, then next day it can feel light. Not physically, but in relation to what you see on monitor.
- Usually on lower power usage it is better, but not always. There are days when even on desktop without anything running at all it can feel like moving through mud.
- System is affected both offline and online. Player movement is like running with 50kg bag filled with rocks.
- Unusually fast reactions of enemies, no matter how smart you play and how fast your reactions are

Exactly the same issues on my side. Most of troubleshooting trials you mentioned I've done already long time ago and it is extremely difficult to prove that problem exist, if you're not much into gaming.

https://streamable.com/vu1six It's my experience when playing against skilled players for last 3 years (these 2 bullet holes on the wall were made before he hit me, with ping 8ms).

[MK14]

You really need (ideally), to split this unexpected 'latency' issue while gaming sometimes, into one of a number of possible high level causes.
Is it that your ISP service(s), introduced a delay, during that actual shooting sequence ?

Is it that your computer introduced a latency, because of problems with your computer hardware/drivers/software ?

Is it a problem with your incoming mains supply (doesn't really seem to be the cause here) ?

Is it EMI/EMC issues (doesn't really make that much sense either, except maybe with the monitor, but probably still not very likely) ?

Is your monitor, having EMI/EMC issues (or other reasons on why it might lag, sometimes, e.g. compatibility), e.g. with the leads picking up stuff, can the monitor diagnose such issues, and report failed screen updates to you ?

There are (I would imagine), specialist forums (computer-technical-high-end-gaming ones), with people who have the same or very similar concerns and issues, as yourselves. I'm convinced they would know how to get to the bottom of such problems. There could be specialist software, diagnostics, tests, error logs, maybe even ISP monitoring/checking software tests. Because some of the people at such places, would know how to check and diagnose ISP latency (if that is the right word), issues. Such as occasional packet losses/delays, and so on.

My hunch is it is problems with your internet, given you are trying to always get 100% reliable, very, very fast communication LATENCIES. Most customers, don't need or notice, an extra 10 milliseconds on very rare occasions (perhaps). But for high end gaming, it really matters for you, as you can lose the match/game. But that is just a hunch, there are many different possible causes, of varying likelihood.

[MK14]

In summary, to wrap up.

it is extremely difficult to prove that problem exist, if you're not much into gaming.

Which is why I'm continually recommending gaming related (technical computer help forums).

My suspicion is that you have already tried those places. Where they didn't accept the fact that you weren't prepared to listen to them, perform the detailed steps to confirm/deny what was going on, and came up with theories, that most other people are not convinced about (e.g. humidity, or some distant old CRT TV, which may have nothing to do with anything).

[MK14]

Often it improves for couple of days, but then it goes back to previous bad state.

That's not really rigorous or proof of anything very much. When you say 'Often' you are basically/potentially mean 50% of the time it does and 50% of the time it doesn't. Also, the fact that after a relatively short while it starts making no difference, again.
Probably means, you are trying a fix, by sheer luck the problem (which this thread seems to say it occurs occasionally over a 3 year period, if I understand things correctly), also it perhaps represents a mere 5 milliseconds extra delay (or some kind of temporary frame drop, or something), every few hours, once or twice a week, sometimes/maybe.

I'm NOT trying to make fun, but I am trying to illustrate the possible problems with your methods.

Analogy:
I give you my magic soap rock, with powerful anti-gremlin psycho-energy powers, which fixes all gaming rig issues. You believe me, and try it. On some games, some of the time, it really works, or at least the problem doesn't appear, on some days.

So what would really be happening is that through sheer luck/coincidence, your games work for a limited period of time, and you might (probably incorrectly), believe that it is because of the magic soap rock, I gave you. I.e. It is more of a psychological effect, where you think the observations have 'fixed your computer'.

On this forum, we have a name for it, and a place for such threads. Called 'Audiophile Audiophoolery'. Which normally applies to some people who are overly concerned about their hifi/audio equipment, but the concept may also apply to someone overly concerned about their gaming rig/setup and how 'special EMC filters' and stuff are affecting their gaming rig/setup.



tl;dr
If you have a very rare intermittent fault, and doing something about it, sometimes seems to fix it, for a very short while, then it becomes faulty again. It is very likely, you didn't really fix it. It was just luck, because it is a rare intermittent fault, not something which occurs all the time.

[dervu]

It was working like that with another "fixes" months ago.
This is why I have that rule to wait really long time, to avoid those placebo fixes, like many people do - having one more fix every day. 
For now it is working really well without any changes for long enough time, but I am waiting even longer.

I catch your point with that proof.
The thing is, without any data you can't really tell specific how often, how bad it is.
With 1000fps cam and consistent input tests, sure. Having specific amount of delay in ms when it is bad compared to no delay when it is good would be rigorous.
Unfortunately proving is expensive in this case.

Now I am getting some decent enough spectrum analyzer to really find out if there is any weird interference with my old radio compared to other good radios.
At least that will be something close to proof - if it correlates with changes observable on PC.
This is the approach that pros from regulatory institution talked about. They need something to correlate with interference present on spectrum analyzer.
But they would need hours to even comprehend what this is about (notice those changes in behavior) and they do not have enough time for that.
Maybe if I would get this device closer to PC then there would be some artifacts on screen that would be good enough for them.
For me it is easier to tell if something is wrong than for them, now with that spectrum analyzer I at least have something to work with.

[magic]

Consumer point and shoot cameras can do slow motion at 120~240fps with VGA resolution or HD if you are lucky.
Should be enough to see if mouse cursor moves?

[MK14]

It was working like that with another "fixes" months ago.
This is why I have that rule to wait really long time, to avoid those placebo fixes, like many people do - having one more fix every day. 
For now it is working really well without any changes for long enough time, but I am waiting even longer.

I catch your point with that proof.
The thing is, without any data you can't really tell specific how often, how bad it is.
With 1000fps cam and consistent input tests, sure. Having specific amount of delay in ms when it is bad compared to no delay when it is good would be rigorous.
Unfortunately proving is expensive in this case.

Now I am getting some decent enough spectrum analyzer to really find out if there is any weird interference with my old radio compared to other good radios.
At least that will be something close to proof - if it correlates with changes observable on PC.
This is the approach that pros from regulatory institution talked about. They need something to correlate with interference present on spectrum analyzer.
But they would need hours to even comprehend what this is about (notice those changes in behavior) and they do not have enough time for that.
Maybe if I would get this device closer to PC then there would be some artifacts on screen that would be good enough for them.
For me it is easier to tell if something is wrong than for them, now with that spectrum analyzer I at least have something to work with.

That sounds better. At least with the 'spectrum analyzer', you can see if there are spurious signals, and hopefully by seeing them, what frequency(s) they are at, begin to fathom out what might be going on. Also, by moving around, you can have more insight into where it might be coming from.
But really, PCs are so complicated and feature rich these days. There are a ridiculously large number of things which can be slightly mal-performing, on very rare occasions (hardware/software/drivers/settings/OS/windows-updates/other-installed-software/firmware-updates/motherboard-settings/etc). Which most people wouldn't notice, but a 240fps fast shooting game might make the difference between getting your hit(s) in, and wondering why you didn't get the success you wanted.

[Nominal Animal]

Do you use wired or wireless controllers?

RF interference could easily affect wireless controllers.  Depending on the protocol (proprietary like Logitech, or BT/BTLE), interference could cause retransmissions; similar to how bad network connection can cause packet loss and increased round-trip times (ping).

If I were OP, I would start logging the processor frequencies and temperatures long-term, and try to correlate any observed issues with changes in temperature or CPU core frequencies.

[ultraknur]

Do you use wired or wireless controllers?

RF interference could easily affect wireless controllers.  Depending on the protocol (proprietary like Logitech, or BT/BTLE), interference could cause retransmissions; similar to how bad network connection can cause packet loss and increased round-trip times (ping).

If I were OP, I would start logging the processor frequencies and temperatures long-term, and try to correlate any observed issues with changes in temperature or CPU core frequencies.

I have wireless mouse Razer Basilisk Ultimate so it's pretty decent equipment and contrary to appearances it gives me better experience than wired.

[Nominal Animal]

I wish I could help you better measure things on your computer.  (I can't, because I do not have Windows; and even if I showed you how to do these tests in Linux, it would tell very little about your problem, because it is almost certainly Windows-specific.)

For example, I just checked the touchpad and the nipple joystick on my HP EliteBook 840 G4 laptop.  The touchpad has 11ms to 60ms report intervals, and the nipple joystick has 5ms to 25ms report intervals, as measured by an userspace program (less than 150 lines of Linux-specific C code).

I could easily check the event report roundtrip time (using USB HID, and force feedback events) with a Teensy, and with an optotransistor or optoresistor, measure the event report to display change latency.  It would only take a rather simple Arduino (Teensyduino) sketch, an optotransistor or optoresistor, and possibly a current-limiting resistor for the opto, connected to an analog input pin to allow for reliable level detection.  However, it also requires a test program run on the target machine, one that changes an area on the display from bright to dark whenever it receives an input event (say, mouse movement) from the Teensy (pretending to be a standard gamepad/joystick/keyboard/mouse; no drivers to install).  I can do that for Linux, but Windows.... Also, you probably don't have a Teensy 4.0 or 4.1 microcontroller.  It would be even better to have two or three optotransistors, so that one could use the pattern to ensure synchronicity, and detect missing/dropped input events.

A similar test can be done using TCP and UDP packets over the network.  TCP is a connection-oriented protocol, and UDP is connectionless (and ISPs can drop UDP packets due to network congestion and other reasons).  You just need two computers running suitable software in two different locations, so that they can connect each other over the network (IP protocol).  The software sends data over, tracking the round-trip time (and for UDP, the number of lost packets), by having each packet have an identifier both ends can track.  A simple counter works.

Game servers that let you test 'ping' do exactly that: they provide a service that reflects each packet back to its sender, and your own local machine just measures the round-trip time.  On the really good ones, the server also sends packets that your local machine responds to, so that the server too measures the round-trip time.  The protocol (TCP or UDP over IP) and the size of the packets should match whatever that particular game uses, for the metric to be meaningful.
(The name 'ping' comes from the fact that the ICMP protocol used for checking connectivity between internet hosts has dedicated 'echo request' and 'echo response' packets that the venerable ping utility uses to check connectivity between hosts. traceroute does much the same, but also causes each host or device in between to send a response back to the sender, so that the sender can track which hosts/devices the packet travels via on its way to the destination.)

[ultraknur]

Unfortunately iperf3 results didn't indicate any problems (I am not sure about that 119 retransmissions from server to client)

Test has been made with TCP and UDP packets from client to server and opposite:

[Nominal Animal]

(I do not play games online, so my opinion here is from someone who has done server-side backends a long, long time ago.  Hopefully, those who know more about current game networking needs, can post their opinion here too.)

(I am not sure about that 119 retransmissions from server to client)

It does not look bad at all, as causing TCP retransmissions is how ISPs limit bandwidth.

Only if they were all grouped in time (so that during the 300 seconds of the test, there were seconds during which the bandwidth dropped below say 50% of the average), would I consider the connection problematic/congested.

The first two look like a fairly typical TCP test for a 11 Mbit/s upload, 85 Mbit/s download network connection.

The third and fourth are UDP tests using 8192-byte payload (rather large for a game?), without any lost UDP packets.  I wonder what the test with 508-byte UDP packets would show; this is a common size that should never be fragmented.  I do not expect the results to differ too much.  Choose the total bandwidth to match (say 80% of) the requirements of some existing online game.

During those 300 seconds, I'd say the network connection –– both bandwidth and latency –– look absolutely fine, if the output dumps looked roughly like the screenshots during the entire test.

As said, I just don't know how well the test matches what current online games use.  I'd definitely retest the UDP test with 508-byte packets, though.  One could use e.g. Wireshark to dump some of the game traffic to see the typical packet size and bandwidth needed; the exact contents would not be interesting.  But it does not look like the network connection has any issues to me.

[ultraknur]

CS:GO sends 1200 bytes packets.

Attached iperf3 result for 508 bytes packet size. Looks good and I am not happy about that because it pretty rules out internet connection problems and desync issue seems to be unfixable in my place. The same I had with different ISP using its own infrastructure.

I found many discussions about clockdrift in games and there is no answer what actually causes it.

Additionally, when I am spectating my teammates, very often they shoot 0.5-1m away from a moving enemy. As you can see my internet connection looks fine and this is complete nonsense.

Understanding interpolation is important in designing for lag compensation because interpolation is another type of latency in a user's experience. To the extent that a player is looking at other objects that have been interpolated, then the amount of interpolation must be taken into consideration in computing, on the server, whether the player's aim was true.

Lag compensation is a method of normalizing server-side the state of the world for each player as that player's user commands are executed. You can think of lag compensation as taking a step back in time, on the server, and looking at the state of the world at the exact instant that the user performed some action. The algorithm works as follows:

    Before executing a player's current user command, the server:
        Computes a fairly accurate latency for the player
        Searches the server history (for the current player) for the world update that was sent to the player and received by the player just before the player would have issued the movement command
        From that update (and the one following it based on the exact target time being used), for each player in the update, move the other players backwards in time to exactly where they were when the current player's user command was created. This moving backwards must account for both connection latency and the interpolation amount8 the client was using that frame.
    Allow the user command to execute (including any weapon firing commands, etc., that will run ray casts against all of the other players in their "old" positions).
    Move all of the moved/time-warped players back to their correct/current positions

Note that in the step where we move the player backwards in time, this might actually require forcing additional state info backwards, too (for instance, whether the player was alive or dead or whether the player was ducking). The end result of lag compensation is that each local client is able to directly aim at other players without having to worry about leading his or her target in order to score a hit. Of course, this behavior is a game design tradeoff.

https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization#Lag_Compensation

Assuming on this I can say, that lag compensation on my side is completely f**ked. If the game itself tries to create accurate locations for everybody why isn't it working for me? It happens in every online game.

In attached photo you can see roughly the difference between what I see and what server registered.

[MK14]

desync issue

What exactly do you mean by desync issue ?

How often does it occur ?

Does it show any patterns when it occurs, such as a particular time of day (I think you said it is usually during the day, rather than late at night) ?

[ultraknur]

desync issue

What exactly do you mean by desync issue ?

How often does it occur ?

Does it show any patterns when it occurs, such as a particular time of day (I think you said it is usually during the day, rather than late at night) ?

By desync I mean huge mismatch between what is happening on a server and what is happening on my screen. With desync you can forget about professional gaming where tenths of milliseconds matters and on my PC this is the severest case of it I've ever seen in my life.

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). I can feel some relief on early morning but it was never satisfying me when comparing to performance I saw on my own eyes (read: everything working perfect). It doesn't happen for my buddies using same ISP in different locations in my city what is interesting.

[MK14]

By desync I mean huge mismatch between what is happening on a server and what is happening on my screen. With desync you can forget about professional gaming where tenths of milliseconds matters and on my PC this is the severest case of it I've ever seen in my life.

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). I can feel some relief on early morning but it was never satisfying me when comparing to performance I saw on my own eyes (read: everything working perfect). It doesn't happen for my buddies using same ISP in different locations in my city what is interesting.

I'm just throwing ideas on the table for you. What if you used something like Wireshark, to keep a record of the communications between your computer and the game server. Ideally, do it both while it works perfectly (at a quiet time) and at a very busy time, when it desync's (shows your issues). Then try and compare them and/or post here or places, so people can study them (assuming there is no privacy concerns with the information, which there could be, if any unencrypted passwords or other private information was in it), so maybe don't post it ?
Ideally, you want it to show the timings and other details, I suspect. Maybe there are better packages to use. Hopefully it doesn't affect the gameplay characteristics, significantly ?
For your game, I don't know how readable the datapackets are.

The connection with congested internet periods, would tend to put internet connections, high up an the list of suspects, that might be causing this issue. Do you know if your connection to the ISP, is mostly/all optical fiber ?, or does it still use copper cables ?

[Nominal Animal]

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.

[MK14]

By desync I mean huge mismatch between what is happening on a server and what is happening on my screen. With desync you can forget about professional gaming where tenths of milliseconds matters and on my PC this is the severest case of it I've ever seen in my life.

That's sad, if you want to use the setup for serious gaming. It must be very annoying, to lose a match, frag or competition. Simply because of this desync issue. It probably throws you off course for a bit, I suspect, as well (disorientating).

Do you know what the most common list of causes of desync are for your game ?
I.e. A recommended list of things to check out and common (and uncommon) causes ?

[MK14]

For example, whenever I build a new desktop or server machine, I always run memtest over the weekend (48 hours or longer).

Very good advice, because bad memory is a somewhat common cause of hardware problems.
Compared to many other hardware issues.
What about if it was ECC memory. Would you still do the 48 hour tests ?
(I suppose you would, then you'd check the applicable error log, afterwards. If the Memory checker, doesn't pick up on it anyway). ECC gets confusing, because it can hide 1 bit (normally always correctable) errors, unless you look at the error logs.

Some memory faults take a lot longer to detect (hence needing to run it for a long time, like the 48 hours mentioned above), and the large memory capacities that modern machines might have, also seem to mean it takes that much longer, to go through it all.