The extrapolation offset works to smooth out someone with an inconsistent connection, it was bugged pre-patch and should be fixed. If it starts acting up it feels like you have really bad rubber banding.
Posting video of the issue would be best, as always.
Extrapolation offset
When you move, click a mouse button etc. these commands are ordered, timestamped, bundled and sent in the next update to the server. When the server gets the update it looks at the timestamps for each command and updates the gamestate. The gamestate update is then sent out to all the players at the next tick interval. When you get that update it's old data and an additional travel time from the server to you has been added. This travel time (UTT) has to be accounted for when the client renders all the other players commands. Thus the offset.
30ms ping == 15ms UTT. The offset is typically averaged and rounded in order to be more consistent.
Extrapolation in it's purest sense is "estimating or concluding something by assuming that existing trends will continue or a current method will remain applicable".
e.g. Player X running in x direction will be assumed to continue until the next update is received and animations, position, actions are corrected.
The offset basically smooths out player rendering versus warping players from A to B positions.
Extrapolation is a lag compensation method. Tickrate (update rate) determines its margin of error threshold. At 60Hz it's very very small...0.0001%.
High latency, Packet loss and server load are some of the biggest variables affecting the offset.
i see, anyhow... i have tested my pc on both my networks, wired,wireless and powerline and have come to a conclusion that its the servers.
being that one of my networks have a ping of 10ms 70 download and 20 upload and my other network has a ping of around 25 300 download and 20 upload.
if you guys have heard of thinkbroadband i use a bqm (broadband quality monitor) and this displays my average, lowest and highest ping. on my bqm it doesnt show any of this packet loss the servers are giving me. not one drop.
wired,wireless and wired to both networks- packet loss shows on server but not in traceroute, teamspeak or on bqm.
tried two pcs- same outcome.
tried different servers- some dont give packet loss as much but still give the exact same values when they do. which is either 1.7% or 3.3%.
UDP has an inherited 3% loss rate. This is because UDP packets don't follow the same route and they often arrive unordered. 3% is pretty much the norm, regardless if the icon or netgraph show it. Unordered packets can be discarded by the server and this will count as loss.
UDP -> Any route to end point.
As long as there is flow == virtual connection.
Packets received out of order can be discarded and counted as loss.
BQM can show 0% loss "technically". But if a packet arrives at the server too late, the server itself will classify it as late (can't use the data) ...aka a loss.
Join a few east coast USA servers. Let me know what results you get.
i went on a 5v5 private server, no packet loss, just ping variation jump. was in america
Then it's localized routing issue. Some of your packets are going on an obscure route to the server, then the server discards them do to out of order receival.
Comments
The extrapolation offset works to smooth out someone with an inconsistent connection, it was bugged pre-patch and should be fixed. If it starts acting up it feels like you have really bad rubber banding.
Posting video of the issue would be best, as always.
You should record this and post it, sounds like the extrapolation bug is still in there.
bf1 clip is only two mins long but i had a few full games last night and not one drop of packet loss.
bf1 video, sorry for the quality, thats youtube scaling for you -_-
i need to cut down the bf4 video.
Your connection looks fine, I'm saying record when the extrapolation goes crazy.
i have two internet providers, one cable one vdsl, im going to test both on the same server to rule out my internet.
i personally think its just bf4.
When you move, click a mouse button etc. these commands are ordered, timestamped, bundled and sent in the next update to the server. When the server gets the update it looks at the timestamps for each command and updates the gamestate. The gamestate update is then sent out to all the players at the next tick interval. When you get that update it's old data and an additional travel time from the server to you has been added. This travel time (UTT) has to be accounted for when the client renders all the other players commands. Thus the offset.
30ms ping == 15ms UTT. The offset is typically averaged and rounded in order to be more consistent.
Extrapolation in it's purest sense is "estimating or concluding something by assuming that existing trends will continue or a current method will remain applicable".
e.g. Player X running in x direction will be assumed to continue until the next update is received and animations, position, actions are corrected.
The offset basically smooths out player rendering versus warping players from A to B positions.
Extrapolation is a lag compensation method. Tickrate (update rate) determines its margin of error threshold. At 60Hz it's very very small...0.0001%.
High latency, Packet loss and server load are some of the biggest variables affecting the offset.
being that one of my networks have a ping of 10ms 70 download and 20 upload and my other network has a ping of around 25 300 download and 20 upload.
if you guys have heard of thinkbroadband i use a bqm (broadband quality monitor) and this displays my average, lowest and highest ping. on my bqm it doesnt show any of this packet loss the servers are giving me. not one drop.
wired,wireless and wired to both networks- packet loss shows on server but not in traceroute, teamspeak or on bqm.
tried two pcs- same outcome.
tried different servers- some dont give packet loss as much but still give the exact same values when they do. which is either 1.7% or 3.3%.
UDP -> Any route to end point.
As long as there is flow == virtual connection.
Packets received out of order can be discarded and counted as loss.
BQM can show 0% loss "technically". But if a packet arrives at the server too late, the server itself will classify it as late (can't use the data) ...aka a loss.
Join a few east coast USA servers. Let me know what results you get.
Then it's localized routing issue. Some of your packets are going on an obscure route to the server, then the server discards them do to out of order receival.
p1, p2 , p3, p4 .... p25 arrive
p32 arrives
p26 - p31 arrives -> discarded
60Hz is 60 packets a second. 3% packet loss is 1.8 packets per 60.
It's your connection.
Congested router traffic or playing over wifi can cause this.
Kinda.
The extrapolation offset is a value determined by network stability to smooth lossy connections.
So having high variance or jitter can cause this value to increase.
The factors to pay attention to are latency, latency variation, and packet loss.
Packet loss will ideally read as zero, latency variation will be less than 5 on a good stable connection and you want your latency as low as possible.