Fast-forward: 36 causes and who fixes them

Also called: everything at once, speed-up, catch-up

A frozen screen starts moving again, and the backlog of movement, hits, and damage plays out all at once at high speed.

Monsters and players move as if on fast-forward, and damage numbers and effects pour out all at once.

Packets piled up somewhere and were released all at once. Typical causes are waiting on a TCP retransmission, the server catching up, and a processing backlog on the client.

Causes of this symptom

L1 Client game process

Packet processing bottleneck on the main thread: If the client processes only a fixed amount of received packets per frame, a flood of packets keeps getting pushed to the next frame. (Game team (Client development))
Fixed-timestep catch-up spiral: After one stall, the game runs its backlog of calculations all at once, and that extra work puts it behind again. (Game team (Client development))

L2 Client OS and device

Background processes taking up CPU: When an antivirus scan, Windows Update, streaming software, or a browser video takes over CPU cores, the game thread has to wait for CPU time. (External (External))
Receive buffer overflow: If the game is busy and pulls packets out of the socket (the network send/receive interface the OS provides) late, the OS buffer overflows. (Game team (Client development))
Other apps on the same device using up bandwidth: When cloud sync, a large download, or a game patch runs on the same PC, game packets have to wait in a queue. (External (External))
Throttling when the window is minimized or unfocused: When you switch to another window or minimize the game, the game and Windows slow it down to save power. When you come back, the backlog of packets floods in, or you’ve already been disconnected. (Game team (Client development))

L3 Home network

Bufferbloat (router queue): When someone in the household uploads a video or downloads a large file, hundreds of ms worth of packets pile up in the router’s queue, and game packets wait behind them. (External (External))

L6 Server network card

Cloud host maintenance and live migration: When a cloud provider performs maintenance on a physical server (host), it moves VMs to another host (live migration) or pauses them briefly. The whole server freezes during that time, and if the pause is long, connections drop. (Infra team (Server infrastructure))

L7 Server OS (kernel)

Kernel socket buffers too small: With small send and receive buffers, a burst of traffic makes the kernel drop packets arriving over UDP, and TCP sends block because the buffer has no room left. (Infra team (Server infrastructure))
System clock jump (NTP step): When the server clock is moved forward or back by several seconds in one step, timers that depend on the system clock fire all at once or stop. (Game team (Server development))

L8 Sockets and protocols

TCP head-of-line blocking: To keep data in order, TCP holds back every packet that arrived after a lost one until the lost packet is received again. (Game team (Server development))
Reliable UDP retransmission settings: When the retransmission rules you built on top of UDP are too conservative, recovery is slow; when they’re too aggressive, they clog the connection even more. (Game team (Server development))
Sending rate plunges under congestion control: TCP treats loss as a sign of congestion and cuts its sending rate by 30–50%. It reacts the same way to Wi-Fi loss. (Infra team (Server infrastructure))

L9 Server game process

Broadcast fan-out overload: Sending one player’s movement to everyone who can see them creates updates on the order of the square of the crowd size. (Game team (Server development))
Combat concentrated on one target (world boss): When hundreds of players hit one boss at the same time, the computation for that single boss piles up in one place, and hit information goes out to everyone watching. (Game team (Server development))
Spawn burst when entering a crowded area: When you teleport into a town packed with players, the server has to send the appearance, gear, and status of hundreds of newly visible players all at once. (Game team (Server development))

L10 Memory

Server GC stop-the-world pause: While a Java or C# server halts every thread to collect garbage (stop-the-world), the whole server stalls. (Game team (Server development))

Netcode design

Events played on arrival without timestamps: If server events carry no timestamp and play as soon as they arrive, network jitter carries straight through into uneven animation timing. (Game team (Client development))

Problems only some players hit

A lagging player moves in bursts on others’ screens: Inputs from a player with a bad connection reach the server unevenly, in bunches. If the server applies whatever arrived on each tick, other players see that character hitch and then cover several steps at once. (Game team (Server development))
Fast-forward on servers that process on arrival: On a server that processes and broadcasts packets as soon as they arrive, a lagging player’s bunched-up actions run back to back immediately. (Game team (Server development))
A lagging client controls the monster: Some games hand monster movement to one nearby player’s client to reduce server load. If that player’s connection is bad, the monster moves strangely on everyone’s screen. (Game team (Server development))
Background window throttling: For a client in a background window, the game, engine, and OS cut its frame rate and processing. Received packets aren’t processed in time, so they back up or overflow. (Game team (Client development))

Root causes of TCP retransmission

Wireless link loss: Wi-Fi and mobile networks retransmit a few times on the wireless link and drop the packet if that still fails. TCP resends the dropped packet only much later. (External (External))
Bottleneck queue overflow (congestion loss): When the queue at the narrowest point fills up, such as a home router, a link between ISPs, or a data center uplink, newly arriving packets are dropped. (Infra team (Network infrastructure))
Send bursts overflow shallow buffers: When a server sends a whole tick of updates for thousands of players in one instant, a switch’s small buffer or a cloud instance’s short-term limit overflows in under 1 ms and some packets are dropped. (Game team (Server development))
Policer drops excess traffic: ISP plans, cloud instance limits, and DDoS protection devices sometimes drop packets over a set rate right away, without queuing them. (Infra team (Network infrastructure))
Physical errors (bad cable, optics, connectors): Damaged cables, dirty fiber connectors, and worn-out optics cause bit errors, and network equipment silently drops the corrupted packets. (Infra team (Network infrastructure))
Duplex mismatch: If one end autonegotiates while the other has speed and duplex hard-set, one side runs half duplex and loses packets to collisions whenever load picks up. (Infra team (Network infrastructure))
Packet drops on the receiving host: Packets reach the server but get dropped, because the NIC’s ring buffer (which briefly holds arriving packets) overflows or the kernel cores that handle receive processing are saturated. (Infra team (Server infrastructure))
Middlebox over capacity (firewall, IPS, DDoS protection): Firewalls, intrusion prevention systems (IPS), and DDoS protection devices inspect every packet passing through. The moment traffic exceeds their inspection capacity, they drop the packets they can’t process. (Infra team (Network infrastructure))
Route change / bad ECMP path: Packets vanish for a few seconds while an internet route changes, or steadily on connections assigned to a faulty path among several ECMP paths. (Infra team (Network infrastructure))
Spurious retransmission from latency spikes: A packet that isn’t lost, just very late for a moment, still gets retransmitted if the delay is longer than the RTO, because the sender treats it as lost. (External (External))
RTO settings that don’t fit the environment: Set the RTO minimum too low and even small delays cause spurious retransmissions; leave the default (200 ms) and it’s too long for games, so every loss means a long freeze. (Infra team (Server infrastructure))
Slow recovery on thin streams: When a game sends small packets sparsely, the RTO fires before “three following packets” can pile up. The same loss causes a much longer freeze than it would on a bulk transfer. (Game team (Server development))
Middlebox strips TCP options: When some firewalls or accelerators remove or rewrite TCP options, multiple losses get recovered only one per round trip, or the window (how much can be sent at once) shrinks, and everything slows down. (Infra team (Network infrastructure))
Zero window (a stall that looks like retransmission): When the receiving program doesn’t read its socket in time and the buffer fills up, the sender stops sending and sends only zero window probes. The network itself is fine. (Game team (Client development))

View the illustrated symptom guide