What this covers: the cross-genre networking vocabulary — tickrate, server tick vs client frame, latency, jitter, packet loss, interpolation, extrapolation, prediction, lag compensation and rollback. Why it matters: these are the words in patch notes and pro complaints; knowing which one applies tells you whether the problem is infrastructure, a setting, or working as designed. Who should care: players in any genre, and anyone reading a netcode graph or a “128-tick” marketing line who wants the numbers behind it.

Netcode is a blanket term, most often used by players, for the way an online game keeps several machines agreeing on one shared world — and it is usually invoked as an accusation when they disagree. Underneath the accusation is a small set of measurable ideas, and almost every complaint maps to one of them. This glossary defines the cross-genre vocabulary — the server-authoritative shooters and MMOs, not the rollback-era fighting stack specifically.

The vocabulary at a glance

TermPlain meaningWhere you meet it
Tickone update of the game simulation“the server ticks 20 times a second”
Tickratehow many ticks the server runs per seconda “128-tick” server
Snapshotthe world stateworld state. The shared record of everything that has happened in the game world — who owns what, what's been built or destroyed. the server broadcasts after a tickpacket rate, cl_updaterate
Ping / RTTtime for a packet to reach the server and come backthe number in the scoreboard
Jitterhow much that round-trip time varies packet to packeta “spiky” ping graph
Packet losspackets that never arrivethe percentage in a net graph
Interpolationrendering other players slightly in the past, blending snapshots“interp” / Overwatch’s “IND”
Extrapolationguessing ahead when snapshots run outdead reckoning
Predictionthe client simulating its own input immediatelywhy your character moves instantly
Reconciliationthe server correcting a wrong predictionrubber-banding
Lag compensationthe server rewinding the world to the shooter’s view“I was behind cover”
Rollbackrewinding and re-simulating after a wrong guessfighting-game netcode

Tickrate: the server’s own frame rate

A single update of a game simulation is called a tick, and the rate at which the server runs that simulation is its tickrate — essentially the server’s framerateframerate. How many images (frames) the game shows per second; higher = smoother motion. 60 fps is a common target. with the rendering stripped out. The rate is limited by how long the simulation takes to run, and is often capped further to keep a fluctuating tickrate from introducing instability and to hold down CPU and bandwidth costs. A lower tickrate also lowers the precision of the simulation.

The number attached to a game is a design choice, not a quality score:

GameServer tickrateNote
VALORANT128 per secondRiot runs a fixed simulation 128 times a second
Counter-Strike: Global Offensive64Valve’s own default for CS:GO
Half-Life 2: Deathmatch / Garry’s Mod66Source’s default 15 ms timestep works out to 66.67 ticks per second
Team Fortress 2 / Counter-Strike: Source66fixed; Valve disabled the tickrate override in later builds
Overwatch60 HzBlizzard’s “high bandwidth” mode runs the server at 60 Hz
Fortnite / Battlefield V (console)30lower console tickrate
Call of Duty: Modern Warfare, Warzone, Apex Legends20among the lowest figures in common circulation

The trade is real: Valve’s notes put a Source server at tickrate 100 at roughly 1.5x the CPU load of the default 66, and advise against going above it. The tickrate line on a box is always a hardware-versus-precision bargain, and a game can move it after launch.

Server tick vs client frame

The number that confuses players most is that a server tick and a rendered frame are not the same event. Riot decouples them in VALORANT: movement and physics update on a fixed timestep “exactly 128 times per second” regardless of render framerate, so “a client running at 60 FPS will simulate multiple movement ticks per frame, while a higher framerate client might blend a single simulation update across multiple frames.” Overwatch does the same on a 60 Hz clock, with fixed 16 ms command frames; a client rendering at 30 Hz simply runs two simulation steps per drawn frame. Embark takes the opposite emphasis for THE FINALS, running movement and destruction server-side with only a “thin prediction wrapper” on the client, on the principle that “the server down the line is the truth of what’s happening.” A 128-tick server is a simulation rate, not your frame rate.

Latency, ping and RTT

Latency is the delay a packet experiences in transit. Valve defines the round trip — client sends a command, server responds, client receives — as the ping or round trip time (RTT), with one-way travel roughly half the ping. This is the term the others orbit: interpolation, prediction and lag compensation all exist to hide it. Low latency is a competitive advantage, which is why studios build private backbones to shorten the route rather than change a game rule.

Jitter: latency’s variance

Jitter is not the size of the delay but how much it moves. Standards prefer the precise term packet delay variation (PDV): the difference in end-to-end one-way delay between selected packets, ignoring lost ones. RFC 3393 warns the word “jitter” “causes confusion because it is used in different ways by different groups of people” and sticks to “delay variation.” The instantaneous version — between two successive packets — is what players mean. If packets leave every 20 ms and the second arrives 30 ms after the first, the delay variation is +10 ms (dispersion); if it arrives 10 ms after, it is −10 ms (clumping).

Jitter is why netcode buffers. Riot calls the internet “highly unreliable” and notes a game running against the newest data “would frequently find itself waiting on late or missing data.” A buffer smooths that, but “while buffering incoming movement allows us to smooth out network issues, it delays when the player will see incoming movement and effectively serves as extra network latency.” That is the trade in one sentence: pay in delay to buy in smoothness.

Packet loss: what TCP hides and UDP doesn’t

Packet loss is when packets fail to reach their destination — from transmission errors, typically on wireless links, or from congestion — measured as a percentage of packets sent. The Internet is best-effort, so routers may simply drop packets when a segment is busy. Here the transport protocol matters: TCP detects loss and retransmits to guarantee delivery, but its congestion handling also throttles throughput; UDP “provide[s] no recovery for lost packets,” leaving the game to handle it.

Action games build on UDP so a dropped packet does not stall newer ones, then add a custom reliability layer. Overwatch sends game data over UDP “with an optional custom reliability layer”; when the server is starved for a player’s input, it duplicates the last input and tells the client to recover. Valve’s servers normally send a delta (only what changed since the last acknowledged update), and fall back to a full snapshot when a client suffers heavy packet loss for a couple of seconds. 2XKO’s “Fair Play mode” gives each player’s inputs a short grace period and replicates the last input if they are late, so an opponent hammering a lag switch “probably won’t even” be noticed.

Interpolation: rendering the past on purpose

Entity interpolation keeps remote players from looking choppy. The server broadcasts snapshots at a steady rate — Source defaults to about 20 per second, one every 50 ms — so a client that drew players only at received positions would look jittery. Instead it shifts rendering backwards and blends between the two most recent snapshots. Source’s default interpolation period is 100 milliseconds: it renders the world as it was 100 ms ago, leaving a spare snapshot to blend across if one packet is lost. Valve notes this causes “a constant view ‘lag’ of 100 milliseconds,” and Overwatch exposes the cost as the stats readout “IND,” or interpolation delay — normally around 54–55 ms, dropping to about 20 ms once servers moved to a higher update rate. Blizzard rolled that mode out to everyone rather than opt-in because responsiveness “adversely affects you if the people shooting at you aren’t getting a high update rate.”

Extrapolation: predicting when the data stops

When more than one snapshot in a row is lost, interpolation has nothing to blend between, so the client switches to extrapolation: a linear guess that continues an object along its known path. Source enables it by default and caps it at 0.25 seconds of packet loss, “since the prediction errors would become too big after that.” Overwatch uses the same idea as dead reckoning and, above roughly 220 ms RTT, stops predicting hit impacts and extrapolates targets instead — partly so a victim does not feel yanked backwards. Extrapolation is always a bet that the trend continues, and it is most visible when the trend reverses.

Prediction and reconciliation: rubber-banding explained

Client-side prediction removes the delay from your own actions: the client runs the same code the server will run and moves you instantly. Valve’s example is a player at 150 ms latency who would otherwise see their own movement a full 150 ms late; with prediction the local player “will move instantly to the new location while the server still sees him at the old place.” When the real snapshot arrives the client compares the two — and a disagreement is a prediction error, corrected visibly as a jump that “can be quite noticeable.” Riot frames the same loop as the source of rubber-banding: “if the server ever disagrees with a client’s view, it issues a correction.” Overwatch adds the recovery: the client keeps a ring buffer of its own inputs and, on a misprediction, restores the authoritative state and replays every input since to catch up. The mismatch is not a bug; it is the price of letting the client feel fast while the server stays the referee — the same tension behind the architecture choices in our client-server vs P2P synchronization explainer.

Lag compensation: rewinding the world for the shooter

Lag compensation exists because the world you see is already old. When you aim at a moving target you are aiming where they were when the pixels were rendered, and by the time your shot reaches the server they have moved again. The server keeps a history of recent positions and estimates when a command was created. Valve’s formula:

Command Execution Time = Current Server Time − Packet Latency − Client View Interpolation

The server moves other players back to where they were at that moment, resolves the shot, then restores everyone. Source keeps one second of position and animation history and by default “only players are rewound.” Riot describes rewinding “the world state to what you were looking at when you pulled the trigger,” and stresses the limit: “without limits, a player with 500 ms latency could kill you a half second after you’d moved behind cover.” That bounded rewind is why “I was behind cover” can be true on both screens — Valve names the paradox of being hit by an attacker you can no longer see, because the server moved your hitboxes back in time to where you were exposed.

Rollback: the fighting-game word for a general idea

Rollback runs local input immediately and predicts the opponent’s, rather than delaying your input to wait for theirs (the older delay-based model). If the prediction was right, play continues; if not, the state is reverted and re-simulated, seen as a jump. It is most associated with peer-to-peer fighting games and the GGPO library, but rollback-style rewinding runs in client-server games too: 2XKO applies it as a hybrid, rollback on top of a client-server model, with a fixed three frames of input delay applied both online and offline so “combo timing and muscle memory built in offline practice should apply directly to online play.” The fighting-game stack has its own vocabulary; the cross-genre point is that rollback and lag compensation are both rewinds aimed at different problems — one at input, one at hit detection.

Reading a complaint: which term is underneath

What a player saysThe term underneathWhat is actually happening
“I shot them but no hit registered”prediction / lag compensationclient and server disagreed on positions, or the rewind clamped
“I got shot around a corner”lag compensationthe server rewound you to when the shooter could see you
“I rubber-banded back”reconciliationserver corrected a prediction error
“My ping is spiking”jitterdelay variation, often buffered rather than removed
“My shots disappear”packet lossinput packets never reached the server
“They hit me before I saw them”peeker’s advantage / tickrateinformation reached you later than it reached them
“The server feels choppy”tickrate / snapshot ratefewer simulation steps than the action needs

A note on misattribution

Not every stutter is netcode. The same symptoms can come from the machine rather than the wire — frame rendering time and inconsistent frame rates can cause lag-like artifacts on a perfect connection. That is a rendering problem, and the frametime glossary on 1% lows and frame pacing covers that half. The vocabulary above is for the half that lives on the network, and the fastest way to use it is to ask one question when a game feels wrong: whose copy of the world is being drawn, and how far in the past is it?

Next read