There is a thread on english aswell, about Connection Issues, and how you can use MTR to track down the problem, Error posted that several times.
MTR/winmtr is a good tool for this, which not only displays the traceroute, but also pings individual nodes, trying to measure packet loss between each hop your packets go through from A to B. It is actually fairly simple to understand, but sometimes also easy to misunderstand, but in a nutshell: if you have packet loss “from the start”, the problem might be on your end. If you have packetloss at “the end”, the problem is out of your hands, and you might want to report it. If there is only loss on one node in the middle but not anywhere else, you can usually ignore it, its usually a server blocking ping and a false positive.
I always mtr my connection issues, before complaining, and well, maybe as someone who actually writes misc. network protocols, servers and clients for a living besides administering my own stuff, like many others are too, I am pretty sure, I can state, that it is not always personal route problems for me, and SC always was more fluid on US server for me with their usually constant 200 ping, than on any ru server with ~70 ping. They cannot change the fact, that it seems, that russias connection to europe seems to have bottlenecks, and I just whish, the infrastructure between these worlds would be better, since it is hard to accept, for me, that while their servers are almost the same distance, still i get variable (so constantly changing) pingrates of +20-50ms. And I do agree, that it could be some US/EU/RU political thing going on, and honestly the whole thing is a sad story in itself, anyway, that our worlds cannot coexist a little bit more in a modern, peaceful and progressive sense.
Lag can be caused by several factors.
It always can be software issues.
Simulation spikes / overload in the server code; this can happen in singular instances (battles) run on the server, it can happen in new maps, with new mechanics, at any time; I do assume, devs monitor this; I am just not sure how well and often, because honestly, it sometimes feels dread battles have that issue.
It can happen with client desyncs aswell, even on total authorative code, which sometimes can be paradox in nature.
It can happen if you use tcp and udp from the same process, like master server syncs at the wrong time, e.g. larger database / state tcp transactions running besides the udp stream. While this phenomenon can be paradox aswell, simple timeout problems which are unhandled are usual microbugs and distinctive; like delays from central authority servers, like the account server, to the instance server. People were also complaining about that, btw. but it seems a bit better now, even if battle results still lag behind sometimes for a while.
And last but not least, it can be simple memory leaks, or other secondary bugs, but well, I think I can safely say, any dev would try to fix those, since they are the most obvious problems, and you always hope, once you fixed the leak, you wake up to a perfectly fluid software, which is unfortunately never so… and if you cant u just schedule server restarts.
But of course it can happen anywhere on the route aswell…
It can happen because the server hoster or your ISP has defective routers or their own traffic issues.
It can happen because of DDoS, or as said, surveillance.
It can happen, because the IPv4 network gets treated less and less prioritized over IPv6 traffic in general.
It can happen that there structural damage between two points, like weather stuff, floods etc.
And of course it can happen, because your Wifi is placed behind the door, and the metal of the doorframe interferes with your signal, and its totally your own fault for not using cable, or any other cause that you could fix at home.
Many of the major packet losses i had to “specific” servers, may it be EU, US or RU, turned either out to be my own ISP (then I shut up and cry), or europe wide (i reported that back then, that Ip4 had problems in europe, such global events are unusual, and that was because a specific company had a software bug in one of their larger router systems) or in fact however on SC’s server end (luckily i am one of the lucky guys, who usually has okay pings).
Since the cause can change in so many ways as i just described (last time i remember where mtr showed its not my fault, for 8 hours, the cloud network SC servers use had a bad connection between amsterdam and frankfurt, which is part of that cloud hosters infrastructure, so only me and a couple of other people had lag, while again other members of the corp from different areas in eu had no lag; unfortunately, i could not report that one in time, since i did not save the mtr logs)
In such cases, reporting it on the forum might be too slow anyway; but still, it would be the company who calls their server provider and reports that there is an issue.
Patience? Yeah. Always blame the reporter? Hell no. Stop such arrogant behaviour.