Difference between revisions of "Latency"
(comments by catid added) |
(posts -> article) |
||
| Line 1: | Line 1: | ||
| − | ''' | + | Latency (or lag) occurs when a client's average ping is very different from its current ping. This happens because clients that receive a laggy client's position packets can incorrectly predict the lagger's position, as per the following equation: PredictedXCoord = SentXCoord + (RateInXDirection * LagTime). Now this will work fine as long as the laggy ship is flying at a constant velocity, and it usually does, since some lag always exists, and ships are ''always'' at predicted positions and not actual ones. But if the ship changes velocity (either speed or direction), the equation will predict incorrect positions and the ship will "jump around" on other clients' screens as the true positions are received. |
| − | + | Since this latency can easily disrupt gameplay, both [[Subgame]] and [[ASSS]] have configurable [[Latency Settings]]. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | == Timing == | ||
| − | + | There's no way to know one-way latency on a network; one can only estimate it. The Subspace protocol does this as follows: | |
| − | |||
| − | |||
| − | |||
| − | There's no way to know one-way latency on a network; | ||
*The client sends a packet with its current time (in milliseconds) to the server every 5 seconds. | *The client sends a packet with its current time (in milliseconds) to the server every 5 seconds. | ||
| − | *When the server receives this packet, it immediately replies, sending back the client's time and the current server time. | + | *When the server receives this packet, it immediately replies, sending back the client's time and the current server time, which is different from the client time. |
*When (if) the client receives this reply, it now knows: how long it took (round trip) for the sync exchange, and the server time at some point in the "middle". | *When (if) the client receives this reply, it now knows: how long it took (round trip) for the sync exchange, and the server time at some point in the "middle". | ||
| Line 44: | Line 15: | ||
Client send time: 100 | Client send time: 100 | ||
Client receive time: 300 | Client receive time: 300 | ||
| − | Server time: 1000 | + | Server time: 1000 |
| − | Round trip: 200 | + | Round trip: (300 - 100) = 200 |
| − | Server time estimate (at client time 300): 1000 + | + | Server time estimate (at client time 300): 1000 + 200 / 2 = 1100 |
</pre> | </pre> | ||
| − | The actual clients do not use 50%, but 60%. Don't ask | + | The actual clients do not use 50%, but 60%. Don't ask why. |
| − | All packets that require time use the server time. This includes movement, weapons, and ball packets. If the sync packet exchange suffers an extra delay of 1000ms at | + | All packets that require time use the server time. This includes movement, weapons, and ball packets. If the sync packet exchange suffers an extra delay of 1000ms at a router, you would get something like this: |
<pre> | <pre> | ||
Client send time: 100 | Client send time: 100 | ||
| Line 57: | Line 28: | ||
Server time: 1000 | Server time: 1000 | ||
| − | Round trip: 1200 | + | Round trip: (1300 - 100) = 1200 |
| − | Server time estimate (at client time 1300): 1000 + | + | Server time estimate (at client time 1300): 1000 + 1200 / 2 = 1600 |
Actual server time (at client time 1300): 2100 | Actual server time (at client time 1300): 2100 | ||
</pre> | </pre> | ||
This creates "fake" C2S latency. So for the next 5 seconds, the client will send estimated times that are early by about 500ms, making the server think they were sent much further in the past than they were. If the client were allowed to continue to play under these circumstances, their ship would be displayed incorrectly by about 160 pixels at full speed in PB, and even more for weapons. Even though this latency is "fake", the sync issue is still bad enough that the client cannot be allowed to stay in game. | This creates "fake" C2S latency. So for the next 5 seconds, the client will send estimated times that are early by about 500ms, making the server think they were sent much further in the past than they were. If the client were allowed to continue to play under these circumstances, their ship would be displayed incorrectly by about 160 pixels at full speed in PB, and even more for weapons. Even though this latency is "fake", the sync issue is still bad enough that the client cannot be allowed to stay in game. | ||
| − | + | ||
| + | == Source == | ||
| + | This document was compiled by [[catid]]'s [http://catid.ssihosting.com/files/addendum.txt addendum] and [[Mr Ekted]]'s [http://forums.powerballzone.com/read.php?board=5&id=42371 latency post]. | ||
| + | |||
| + | [[Category:Game Intricacies]] | ||
Latest revision as of 17:55, 29 July 2005
Latency (or lag) occurs when a client's average ping is very different from its current ping. This happens because clients that receive a laggy client's position packets can incorrectly predict the lagger's position, as per the following equation: PredictedXCoord = SentXCoord + (RateInXDirection * LagTime). Now this will work fine as long as the laggy ship is flying at a constant velocity, and it usually does, since some lag always exists, and ships are always at predicted positions and not actual ones. But if the ship changes velocity (either speed or direction), the equation will predict incorrect positions and the ship will "jump around" on other clients' screens as the true positions are received.
Since this latency can easily disrupt gameplay, both Subgame and ASSS have configurable Latency Settings.
Timing
There's no way to know one-way latency on a network; one can only estimate it. The Subspace protocol does this as follows:
- The client sends a packet with its current time (in milliseconds) to the server every 5 seconds.
- When the server receives this packet, it immediately replies, sending back the client's time and the current server time, which is different from the client time.
- When (if) the client receives this reply, it now knows: how long it took (round trip) for the sync exchange, and the server time at some point in the "middle".
Example:
Client send time: 100 Client receive time: 300 Server time: 1000 Round trip: (300 - 100) = 200 Server time estimate (at client time 300): 1000 + 200 / 2 = 1100
The actual clients do not use 50%, but 60%. Don't ask why.
All packets that require time use the server time. This includes movement, weapons, and ball packets. If the sync packet exchange suffers an extra delay of 1000ms at a router, you would get something like this:
Client send time: 100 Client receive time: 1300 Server time: 1000 Round trip: (1300 - 100) = 1200 Server time estimate (at client time 1300): 1000 + 1200 / 2 = 1600 Actual server time (at client time 1300): 2100
This creates "fake" C2S latency. So for the next 5 seconds, the client will send estimated times that are early by about 500ms, making the server think they were sent much further in the past than they were. If the client were allowed to continue to play under these circumstances, their ship would be displayed incorrectly by about 160 pixels at full speed in PB, and even more for weapons. Even though this latency is "fake", the sync issue is still bad enough that the client cannot be allowed to stay in game.
Source
This document was compiled by catid's addendum and Mr Ekted's latency post.
