You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How to replicate the issue: Start a local server servertype 1 and join it connect localhost. Play a match and then download the demo. Now when you watch the demo you might see extreme lag on yourself (at least I do, but it can vary on different computers I guess). I get packet jumps that go above 100 or even 200 or more very often.
The reason that this happens seems to be that ENet throttles the network throughput on the client when the round-trip time to the server increases. This is done in function enet_peer_throttle in src/enet/peer.c. peer->packetThrottle is the variable, in the range [0, 32], that determines how many percent of network packets to be sent that are actually sent, where 0 is 0% and 32 is 100%. When that variable is down at 0, that means that no packets (more specifically unreliable packets like position updates) are sent at all. This is what causes the visible lag.
The problem is that that variable goes down to 0 very easily, especially when playing on servers with low ping time, like localhost. I think the reason for this is that when you have a low round-trip time to the server, the frame rate you get in the game will affect the RTT relatively much. Example, if I have 60 FPS, one frame is 16 ms. If my ping time is also 16 ms, a packet being received one frame later will double my RTT and that will cause ENet to quickly throttle down to 0.
Possible solutions: We can either disable throttling entirely, or only throttle if the RTT is >= 50 or 500 ms or something like that, or put a lower limit on the throttle value so that there will always be at least some packets sent.
You can read more about how this throttling works in the comment above the enet_peer_throttle_configure function in src/enet/peer.c.
The text was updated successfully, but these errors were encountered:
The new version of enet seems to make the situation better but not perfect. Now it usually doesn't lag when just playing normally unless you do something that makes the fps go down, like opening serverbrowser or playing on vorticity; when I do that I can still see throttle lag.
How to replicate the issue: Start a local server
servertype 1
and join itconnect localhost
. Play a match and then download the demo. Now when you watch the demo you might see extreme lag on yourself (at least I do, but it can vary on different computers I guess). I get packet jumps that go above 100 or even 200 or more very often.The reason that this happens seems to be that ENet throttles the network throughput on the client when the round-trip time to the server increases. This is done in function
enet_peer_throttle
in src/enet/peer.c.peer->packetThrottle
is the variable, in the range [0, 32], that determines how many percent of network packets to be sent that are actually sent, where 0 is 0% and 32 is 100%. When that variable is down at 0, that means that no packets (more specifically unreliable packets like position updates) are sent at all. This is what causes the visible lag.The problem is that that variable goes down to 0 very easily, especially when playing on servers with low ping time, like localhost. I think the reason for this is that when you have a low round-trip time to the server, the frame rate you get in the game will affect the RTT relatively much. Example, if I have 60 FPS, one frame is 16 ms. If my ping time is also 16 ms, a packet being received one frame later will double my RTT and that will cause ENet to quickly throttle down to 0.
Possible solutions: We can either disable throttling entirely, or only throttle if the RTT is >= 50 or 500 ms or something like that, or put a lower limit on the throttle value so that there will always be at least some packets sent.
You can read more about how this throttling works in the comment above the
enet_peer_throttle_configure
function in src/enet/peer.c.The text was updated successfully, but these errors were encountered: