The server is 300 kms away, (Zürich) the Ping is 8 ms, it's like I have the server in the same room as my game console. But the feeling of the game reflects a gameplay as if I was playing against a Chinese ( approximately 200 ms ) if I had a friend in Zürich and he would make a mtr on my public IP, could it be thought that it simulates the way back ?
Not really.... in networking the physical location of a server really just allows an estimate of the minimal path RTT based on euclidean distance, but there is no guarantee that the path to the servers does not go crazy wild (like when the swiss ISP Init7 had swisscom/deutsche telekom route through the US to get to its customers to make a point). Having a probe in the same city really only helps if packets to from that location share a noticeable number of hops with the path to the relevant game servers....
I am back with swisscom, am I affected by your quote? Would it concern the way back as it would pass through the US? This would explain a lot and a concrete reflection of this glaring discrepancy?
No, this was just to illustrate that physical distance between two points does not mean that "network distance" is the same, to explain why having a friend in Zurich is not likely to help all that much with diagnosting your network path to the game servers.
Your RTT of 8ms clearly demonstrates a rather direct path without scenic routes across different continents. As I said Init7 did that for a short while to make a point, not because they thought this to be a good way of handling inter-european traffic....
Thanks for sharing your experience!
I don't know in which direction to go anymore.
I'm going around in circles and I can't find any concrete and well-founded explanation on the network!
You've looked at the network left, right, and center... every way you could. And found nothing obvious.
So, let's change our model of what might be going on. The server itself somehow makes you lag. For example, you have a short 8ms ping to their data center, so they add you to a 200ms queue so that they equalize your delay with other people in the game... except they do this very poorly perhaps, so it only affects some players and not others... let's say people who have 30ms of ping, so some people have 30ms and other people who have 8ms of network delay instead get 200ms added delay because the programmers are lazy and don't have a number of different queues they can use, it's just "one that adds 200ms" or no queue...
could this be? yes. Is it? I don't know.
I suggested that he tries out introducing latency:
1 Like
But this is what game servers already do.... and there are little indications that his general traffic suffers from high delays or high jitter, so a local de-jitter buffer on his side would only help indirectly, in that it will also increase his static delay, which might or might not help with his issue.
By increasing his delay a number of things might change, like:
a) he might be matched with a different RTT group of players, like instead of being the 8ms outlier in a group of ~2ms RTT, he might end up being thhe 16ms outlier in a group of ~25ms.
b) or he might fall into an RTT range where no server side delay gets added.
c)...
Without reliable information what happens on the other end this is pure speculation....
Personally, I probably would look for avdifferent game with less strict realtime requirements, like correspondance chess 
I think you thought I had something different in mind.
This is indeed what I have in mind. Seems worthwhile trying set against the many other things tried here. If the server is in some sense punishing the poor boy for his good connection, then perhaps he can fight back with introducing delay and thereby restoring harmony.
How would he introduce say 30ms of delay? Is there a qdisc that can do this?
netem can be used to introduce delay, but it requires enough memory to store the data for the full delay, so depending on link speed and router memory this might or might not work. I think @dlakelan in the past actually had a script that allowed to set up netem delay to help gamers. However keep in mind that gamers tend to try to game everything, so some folks add delay to get graded by the server and then strategically disable the artificial added delay to gain an unfair advantage over their opponents... and that is why we can't have nice things...
1 Like
If all this is correct, it means that according to ISP we have some with the same ping of 8 ms server will be penalized and others not. The relevant question would be, why one part of the players and not the other... what is the network peculiarity that differentiates one from the other.
Yes you had transmitted me a command line to add latency, 30,60,90,120,200, 800 ms were tested, the only player penalized is me, I punish myself by adding latency unfortunately ... which leads me to think that I am not compensated by the server ... because it does not take into account my false latency of 200 ms
Yes I saw videos where the guy was using a Pc program : UnicornUdp to flood udp during matchmaking to have an advantage when he disables the program . I don't know if this practice is still functional it was in 2019.
How did you add the false latency? It wasn't me that transmitted any such command as I don't know how best to add latency. Seems like @moeller0 had a couple of good suggestions.
I also agree with @moeller0 to consider giving up and finding another hobby. Computer games, whilst not as bad as pornography, are bad for the soul. I should know as I wasted countless hours.
Life is short - a vapour - and precious, and we shouldn't ignore our loved ones and thinking about things that truly matter. Why are we here? What is the purpose of life? Why can we even question these things?
No matter your worldview, I am convinced that computer games can be damaging to life in a manner that is not so dissimilar to other addictions. Our brains get rewired to get hooked on short term pleasure and it dulls our senses to be able to appreciate beauty in life, relations and in nature.
I feel your pain with this thread, and can relate on a personal level given my past experiences, and I really hope the struggles with this aren't affecting your quality of life. Hence my well intentioned messages like this one.
1 Like
Change eth0 to your WAN device name
tc qdisc add dev eth0 root netem delay 50ms
or
tc qdisc replace dev eth0 root netem delay 50ms
Deprioritizing all streams except the game would be a trial alternative?
We do not even know whether it is network related at all....
If you use netem your packets will truly experience the configured delay, there is nothing fake in the delay (now your delay will not reflect your minimal path RTT anymore, but the delay itself is real).
Just a note, in the past people observed problems when combining netem with outher qidisc (IIRC) so one recommendation was to run netem on a box all by itself without any other fancy QoS stuff. But if you actually saw the configured delay in your measurements (so e.g. 58 ms instead of 8ms without the 50ms netem delay) I would say it does seem to work.
Luckily this is essentially equivalent with only prioritizing your game traffic. However you need to take care to only up-prioritize the game control/world-sate-update packets and not e.g. any voice chat also being used while gaming... let alone any video streams one might want to sent during one's gaming sessions.
According to the history of my thread here ..All the graphs of my network point to unexplainable spikes ... everything suggests that the many simultaneous connections cause or degraded the flow of the game, which could foreshadow that some flow would be parasitic, enough to distract and disrupt the priorities of the game set up
Independent of everything else maybe consider getting a free account at thinkbroadband.com and set up their broadband monitoring tool (this is a bit like smokeping except only from a single host):
https://www.thinkbroadband.com/broadband/monitoring/quality
You will get a graph similar to this for every day (for ~60 rolling days):
This shows the measured delay from pingbox1.thinkbroadband.com as well as the packet loss, in my example my ISP routed me through a nasty segment with 10-2-% packet loss, this is really rare, but I will get occasionally into a segment with 1-2% packet loss, which I would not immediately note without looking at the data (over short RTTs even 1-2% packet loss is not all that noticeable, yes peak download rates suffer, but most things limp on good enough to not stick out violently).
Now, I do not believe your ISP is at fault here, but such traces would make it easy to convince yourself that your ISP is innocent. If you already set something like this up, by all means post the links to exemplary result files.
1 Like