Network Latency
From Computing and Software Wiki
m |
(Much new content in gaming section) |
||
Line 26: | Line 26: | ||
===Quantum Computing=== | ===Quantum Computing=== | ||
===Real-Time Gaming=== | ===Real-Time Gaming=== | ||
- | [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' inputs and the game's response. Modern games of this type are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to mentally compensate | + | [[Image:Lag_compensation.jpg|thumb|right|600px|An example of lag compensation in Counter-Strike: Source. The man running shows the player's actual position on the server, whereas the coloured boxes show his position for gameplay purposes. The red boxes are what other clients see, and the blue boxes are the server's lag compensated position.]] |
+ | [[Real-time]] online multiplayer games suffer from network latency, causing a delay between the players' inputs and the game's response. Modern games of this type are typically designed to use a [[client-server networking]] model, though [[peer-to-peer]] implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to mentally compensate for the delay by performing input earlier than actually desired. | ||
- | == | + | Modern [[game engines]] such as Valve Software's Source Engine <sup>[x]</sup> implement a number of lag compensation techniques. To eliminate the apparent delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid [[desynchronization]] (this however can cause a sudden "jerking" effect known as "rubber-banding"). This method is known as '''client-side prediction'''. |
+ | |||
+ | Client-side prediction is based off the assumption that basing gameplay events off of clients' individual latencies as well as the server's authoritative state provides a smoother experience. Whenever a predicted effect | ||
+ | |||
+ | ==Compensating for latency== | ||
+ | When a noticeable latency is unavoidable, some method of hiding the latency from the user needs to be employed. One strategy for this is prefetching | ||
+ | |||
+ | Suppose that a piece of real-time software needs to communicate with a server acting as an authority on the application's state, and that the network has a round-trip latency of 100 milliseconds. | ||
===Prefetching=== | ===Prefetching=== | ||
+ | Some web browsers (such as Mozilla Firefox <sup>[x]</sup>) | ||
===Prediction=== | ===Prediction=== | ||
+ | |||
+ | |||
===Interpolation=== | ===Interpolation=== | ||
+ | [[Image:Interpolation.gif|right|]] | ||
+ | Programs which | ||
+ | |||
Line 40: | Line 54: | ||
==References== | ==References== | ||
{{reflist}} | {{reflist}} | ||
+ | http://en.wikipedia.org/wiki/Link_prefetching | ||
+ | http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking | ||
==See Also== | ==See Also== | ||
==External Links== | ==External Links== |
Revision as of 21:22, 12 April 2009
As an Engineering term, latency refers to the span of time taken from when some action is initiated to when it actually takes effect.
In the context of packet-switching networks, latency can refer to any of the following:
- The time from when a packet is sent to when that packet reaches its destination
- The round-trip time of a packet
- The perceived delay in communication between hosts
In online multiplayer games, the round-trip time of a packet is commonly known as ping.
Contents |
Causes
Traffic Congestion
Any packets which are prevented from reaching their destination for any period of time will result in an increase in latency. Heavy network traffic can therefore increase latency, as bandwidth limitations and routing issues contribute to the time that a message spends in transit.
Application performance
Since every packet must at some point be created and sent by an application, any time taken in processing the information necessary to create or read a packet will cause additional latency. The perception of latency is also created when communication is delayed due to packets being dropped (from events such as packet collisions), because the user will only see the time from when the request was sent to when the message was successfully received.
Distance
Communication is naturally limited by the speed of light. Therefore the round-trip time of packets is unavoidably linked to the distance over which the packets are being sent, subject to the laws of Relativity. This is particularly an issue in the field of Space Exploration, where the round-trip time of communication is commonly measured in minutes or hours. Because of this, rovers must be programmed with some level of artificial intelligence so that moment-to-moment decisions can be made autonomously.
Measuring Latency
Due to fluctuating network conditions, the latency of individual packets within the same session of communication can vary wildly. Because of this, the latency of any single packet may not be meaningful. Another issue is the fact that any latency measurements exchanged between hosts will themselves be subject to delay on the network.
A simple solution to both of these problems is calculating latency using average round-trip time. Finding the round-trip time of communication can be done from a single host, and taking the average latency over several packets provides a more stable and representative estimate of the expected delay in future packets. Extra steps may need to be taken, as dropped packets and temporary disconnections can skew the average latency measurement much higher.
Note, the time that a remote host takes to process a packet is typically not included when calculating a round-trip time.
Effects
Quantum Computing
Real-Time Gaming
Real-time online multiplayer games suffer from network latency, causing a delay between the players' inputs and the game's response. Modern games of this type are typically designed to use a client-server networking model, though peer-to-peer implementations are also possible. Latency means that the players' instructions to the game do not reach the server instantaneously, and the server's description of the current gamestate is slightly outdated by the time it reaches the players. During the infancy of online gaming the only workaround was for players to mentally compensate for the delay by performing input earlier than actually desired.
Modern game engines such as Valve Software's Source Engine [x] implement a number of lag compensation techniques. To eliminate the apparent delay on a client, character animations and other responses which do not affect gamestate are played immediately. Actions which do affect the gamestate (such as a player walking forward) have their outcomes predicted on the client's end as if they have already happened, causing the player to immediately see themselves walking forward. The client is therefore seeing a real-time approximation of the server's current gamestate at any given moment. If any discrepancy is found once the server finally responds to the client, the client adjusts itself to match the server's new state in order to avoid desynchronization (this however can cause a sudden "jerking" effect known as "rubber-banding"). This method is known as client-side prediction.
Client-side prediction is based off the assumption that basing gameplay events off of clients' individual latencies as well as the server's authoritative state provides a smoother experience. Whenever a predicted effect
Compensating for latency
When a noticeable latency is unavoidable, some method of hiding the latency from the user needs to be employed. One strategy for this is prefetching
Suppose that a piece of real-time software needs to communicate with a server acting as an authority on the application's state, and that the network has a round-trip latency of 100 milliseconds.
Prefetching
Some web browsers (such as Mozilla Firefox [x])
Prediction
Interpolation
Programs which
<ref>Template:Cite journal</ref>
References
Template loop detected: Template:Reflist http://en.wikipedia.org/wiki/Link_prefetching http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking