Latency - Revision history

Cyan~Fire: posts -> article

2005-07-29T21:55:52Z

posts -> article

← Older revision		Revision as of 21:55, 29 July 2005
Line 1:		Line 1:
	'''~~[[Catid]] says~~:'''		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.

	~~Source: http://catid.ssihosting.com/files/addendum.txt~~		Since this latency can easily disrupt gameplay, both [[Subgame]] and [[ASSS]] have configurable [[Latency Settings]].
	~~----~~
	~~Most people wonder what causes lag. It's pretty simple. When your average ping~~
	~~(the mean of a series of round trip packet times) is very different than your current~~
	~~ping (the last time between when a packet was sent and when a response was received),~~
	~~you are "laggy" because when the SubSpace client predicts the next location of someone..~~
	~~ie.~~
	~~<pre>~~
	~~-> = your ship's position~~
	~~Your PC ->~~
	~~Server ->~~
	~~Remote client -> ->~~
	~~^^ ^^ Where your ship is on your screen.~~
	~~^^ What the remote client knows for sure~~, ~~the rest must be predicted.~~
	~~</pre>~~
	~~...that number is affected by your average ping~~ and ~~not your current (true ping).~~
	~~In the diagram above, your ship should be where that last arrow is on other clients'~~
	~~screens. However, the packet that was sent by you took a while to reach that other~~
	~~computer so the location remote machines see is different than your actual location.~~
	~~This is described by the equation:~~
	~~ActualXCoord = SentXCoord + (RateInXDirection * LagTime)~~

	~~Since it is impossible to know the time it took to send a packet (yes, it is impossible),~~
	~~all of the players on your screen are actually at their predicted position instead of~~
	~~actual. Using the loopback IP, 127.0.0.1, ping times less than 1 ms are very likely,~~
	~~but even then the time it takes to send a packet is impossible to determine~~.
	~~----~~

			== Timing ==

	~~'''[[Mr Ekted]] says:'''~~		There's no way to know one-way latency on a network; one can only estimate it. The Subspace protocol does this as follows:

	~~Source: http://forums.powerballzone.com/read.php?board=5&id=42371~~
	~~----~~
	There's no way to know one-way latency on a network; ~~you~~ 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.		*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 ~~(remember that the 2 internal clocks are not the same values)~~		Server time: 1000

	Round trip: 200		Round trip: (300 - 100) = 200
	Server time estimate (at client time 300): 1000 + ~~(300 - 100)~~ / 2 = 1100		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 me why.		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 ~~the C rounter (from my picture)~~, you would get something like this:		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 + ~~(1300 - 100)~~ / 2 = 1600		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]]

CypherJF: comments by catid added

2005-03-26T21:59:21Z

comments by catid added

@@ Line 1: / Line 1: @@
-Source: http://forums.powerballzone.com/read.php?board=5&id=42371
+'''[[Catid]] says:'''
 '''[[Mr Ekted]] says:'''
 ----
 There's no way to know one-way latency on a network; you can only estimate it. The Subspace protocol does this as follows:

Smong: changed format to match Door Sync

2005-03-26T21:23:48Z

changed format to match Door Sync

← Older revision		Revision as of 21:23, 26 March 2005
Line 1:		Line 1:
	~~'''~~Source:~~'''~~ http://forums.powerballzone.com/read.php?board=5&id=42371		Source: http://forums.powerballzone.com/read.php?board=5&id=42371

			'''[[Mr Ekted]] says:'''
			----
	There's no way to know one-way latency on a network; you can only estimate it. The Subspace protocol does this as follows:		There's no way to know one-way latency on a network; you 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.		*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.
	- 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".

	Example:		Example:
			<pre>
	Client send time: 100		Client send time: 100
	Client receive time: 300		Client receive time: 300
Line 15:		Line 17:
	Round trip: 200		Round trip: 200
	Server time estimate (at client time 300): 1000 + (300 - 100) / 2 = 1100		Server time estimate (at client time 300): 1000 + (300 - 100) / 2 = 1100
			</pre>
	The actual clients do not use 50%, but 60%. Don't ask me why.		The actual clients do not use 50%, but 60%. Don't ask me 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 the C rounter (from my picture), you would get something like this:		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 the C rounter (from my picture), you would get something like this:
			<pre>
	Client send time: 100		Client send time: 100
	Client receive time: 1300		Client receive time: 1300
Line 27:		Line 29:
	Server time estimate (at client time 1300): 1000 + (1300 - 100) / 2 = 1600		Server time estimate (at client time 1300): 1000 + (1300 - 100) / 2 = 1600
	Actual server time (at client time 1300): 2100		Actual server time (at client time 1300): 2100
			</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.
			----

CypherJF: Information about latency by Ekted -- needs a category and whatnots.

2005-03-26T20:36:00Z

Information about latency by Ekted -- needs a category and whatnots.

New page

'''Source:''' http://forums.powerballzone.com/read.php?board=5&id=42371

There's no way to know one-way latency on a network; you 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.
- 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 (remember that the 2 internal clocks are not the same values)

Round trip: 200
Server time estimate (at client time 300): 1000 + (300 - 100) / 2 = 1100

The actual clients do not use 50%, but 60%. Don't ask me 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 the C rounter (from my picture), you would get something like this:

Client send time: 100
Client receive time: 1300
Server time: 1000

Round trip: 1200
Server time estimate (at client time 1300): 1000 + (1300 - 100) / 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.