Leaderboard

Some maps lag way worse than others from my experience and Erdenberg is absolutely the worst culprit. It's impossible for me to get a stable 200ms ping there. I have also noticed that the latency spikes are aggravated the more players there are. My theory has been that it's due to two things: 1. Bandwidth bottleneck somewhere in the network path. Bandwidth saturation produces knock-on effects like elevated or unstable latencies. 2. Map geometry is not well sectioned (or has leaks) so you end up with far more server traffic than necessary to update invisible players. (2) is maybe testable by recording a demo and playing back using r_showNormals 1. From the EU, network bottlenecks really shouldn't be a problem. To check this, you could maybe run Speedtest (https://www.speedtest.net/) from your computer and picking the ISP the main ETL1 server is on. One misconception behind network issues is that the problem lies on one end or the other i.e. the ISP or the game server in this case. In reality, it very much depends on the routing between the two endpoints and the problematic node on the path could belong to an intermediary. As far as client tweaks is concerned, there is the setting of packet duplication to off (cl_packetDup 0), reducing snaps, reducing rate and reducing cl_maxPackets. Except for cl_packetDup, the ETL1 server is unfortunately too restrictive for any of the above to work. I have always wondered if it would be better to set a range of acceptable snap and rate values rather than fixing it to 40 and 35000 respectively. On a sidenote: regarding traceroutes (or tracert on Windows), you have to be careful with interpretation. 1. Most service providers will ask you to provide traces in both directions because the forward and reverse paths may not be the same. 2. It is alright for intermediate nodes to not respond to traces. Pings and Traceroutes use a different protocol (ICMP) and are considered 'control traffic' instead of 'data traffic' and switches/routers prioritize forwarding data. The right way to interpret Traceroute results is to look at the trace in reverse, beginning from the destination. Note down the latency and losses, then work backwards to the earlier nodes to observe the progression.