Forums » Bugs
Thanks for the explanation Incarnate.
From my long expirience with VO i can conclude this:
- when my ping is around 150 i can play OK, heck i can even beat shape sometimes
- when my ping jumps over 150 lagdeaths start
Some other things that routinely appear:
- sometimes i get server timeout in the middle of fight or when flying thru a storm or doing BP = instadeath /this is the most annoying part/
- every day at exactly 11 am GMT i get a server timeout so i have to really check time because if i find myself in a bot sector or in a fight = instadeath
If my memory serves me well, i think i have around 200 server timeout deaths on my chars so far.
From my long expirience with VO i can conclude this:
- when my ping is around 150 i can play OK, heck i can even beat shape sometimes
- when my ping jumps over 150 lagdeaths start
Some other things that routinely appear:
- sometimes i get server timeout in the middle of fight or when flying thru a storm or doing BP = instadeath /this is the most annoying part/
- every day at exactly 11 am GMT i get a server timeout so i have to really check time because if i find myself in a bot sector or in a fight = instadeath
If my memory serves me well, i think i have around 200 server timeout deaths on my chars so far.
One thing you can always try is to change the single network option in the game: set MTU Discovery to "Compatibility mode" if you suspect there is packet loss. It *may* improve the situation but it will make things worse in really busy sectors.
[Here comes another characteristically overly-technical post from a1k0n]
The game constantly tries to adjust for packet loss and round-trip time, and there's a pretty aggressive heuristic for retransmitting lost packets (it's actually equivalent to the one Van Jacobson recommended for TCP). These retransmits might actually get in the way over a certain threshold. The network code would also work a little (maybe a lot) better if we threaded it. I also didn't implement slow-start, so there's probably a lot of untapped throughput available (but at the potential cost of increased deadly latency). So there is room for improvement, and I will spend some time on that when I get a chance.
I want to collect some data on what's going on in the extreme cases. Packets being lost is almost always a sign of congestion, and unfortunately, as a UDP stream our game probably has a relatively low priority on a congested router. But just because you see a * on a traceroute doesn't necessarily mean there is packet loss -- there could be multiple load-balanced paths at that point and traceroute doesn't always work with those. There are also, in our net code, frequent cases of suspected packet loss which just turn out to be a late acknowledgement.
So anyway, I'll come back to this and think about it some more. I might add some kind of signal you can send to the server to complain about lag, so I can log the characteristics of your network link to the server at that time.
One thing that's important is if you're going to report your ping, also include the mean deviation (the +/- numbers shown in the /ping command).
[Here comes another characteristically overly-technical post from a1k0n]
The game constantly tries to adjust for packet loss and round-trip time, and there's a pretty aggressive heuristic for retransmitting lost packets (it's actually equivalent to the one Van Jacobson recommended for TCP). These retransmits might actually get in the way over a certain threshold. The network code would also work a little (maybe a lot) better if we threaded it. I also didn't implement slow-start, so there's probably a lot of untapped throughput available (but at the potential cost of increased deadly latency). So there is room for improvement, and I will spend some time on that when I get a chance.
I want to collect some data on what's going on in the extreme cases. Packets being lost is almost always a sign of congestion, and unfortunately, as a UDP stream our game probably has a relatively low priority on a congested router. But just because you see a * on a traceroute doesn't necessarily mean there is packet loss -- there could be multiple load-balanced paths at that point and traceroute doesn't always work with those. There are also, in our net code, frequent cases of suspected packet loss which just turn out to be a late acknowledgement.
So anyway, I'll come back to this and think about it some more. I might add some kind of signal you can send to the server to complain about lag, so I can log the characteristics of your network link to the server at that time.
One thing that's important is if you're going to report your ping, also include the mean deviation (the +/- numbers shown in the /ping command).
Cool. Sounds promising. Thanks Andy. :)