Measuring…
The verdict for this game appears once the first full second of packets is in.
Comparing with other tests to this server…
Measuring…
The verdict for this game appears once the first full second of packets is in.
Comparing with other tests to this server…
Are you sure you want to delete all results?
| Date & Time | Duration | Avg Ping | Avg Jitter | Packet Loss | Actions |
|---|
You have low ping, but your shots aren't registering and you are teleporting. Why?
CS2 uses a new "sub-tick" architecture. Unlike CS:GO, where actions happened at the end of a tick, CS2 registers the exact microsecond you click. This means CS2 is incredibly sensitive to Packet Loss and Jitter. Even 1% packet loss will cause your shots to ghost or result in being killed behind walls.
What this test sends: 64 packets per second of 250 bytes, matching Counter-Strike 2 rather than a generic ping. verified
Valve runs official CS2 servers at 64 tick; sub-tick only timestamps inputs between those ticks, it does not raise the rate.
Use the live tool above to simulate CS2's exact 64Hz server traffic rate. Here is what to look for:
If you see vertical red lines on the chart above, your connection is dropping data. In CS2, this results in "teleporting" around corners, weapon swap glitches, or your gun firing but no bullet coming out.
If your jitter is above 10ms, your connection is unstable. This usually happens if you are playing CS2 on Wi-Fi instead of an Ethernet cable. It ruins the sub-tick timing precision.
Wi-Fi is terrible for competitive FPS games. It naturally drops packets due to interference from walls and other devices. CS2 requires a wired Ethernet connection for flawless sub-tick registration.
If your ping line spikes into the yellow or red randomly, someone on your network might be streaming 4K Netflix or downloading a large file. Enable QoS (Quality of Service) in your router to prioritize CS2 traffic.
Use the server dropdown above to test your connection to Frankfurt or New York. If only one server lags but the other is completely smooth, the issue is likely a bad routing node between your ISP and Valve's datacenters.
CS:GO's net_graph is gone. CS2 replaced it with the Telemetry HUD, in Settings under Game: switch on ping, packet loss, jitter and server tick and they appear at the edge of the screen during a match, colouring themselves once they pass a threshold you set.
Two of those numbers are worth separating, because they are routinely confused. Packet loss is data that left one end and never reached the other - your line, your router, or the path in between. Choke, the figure CS:GO players still look for, is the server deciding not to send you an update because it has hit its own bandwidth limit for you. The first is yours to fix; the second is not, and no amount of router configuration will change it.
The Telemetry HUD has one structural limitation, and it is the reason this page exists: it only runs while you are in a match, so it cannot tell you whether the connection was already dropping packets before you queued, and it keeps no history you can show anybody afterwards. The chart above runs outside the game, keeps the whole minute, and exports as a PNG or CSV. Run both - if the game's telemetry and this test disagree, the difference is the route to that particular relay, which the server picker lets you test directly.
What you see in game, and which number on this page explains it.
| What you see in Counter-Strike 2 | Look at | What it means |
|---|---|---|
| You die a full second after reaching cover | loss | Your position updates never arrived; the server still had you in the open. |
| Spray transfers land on one target and miss the next | jitter | Updates arrive unevenly, so the interpolated enemy position is wrong between them. |
| Rubberbanding while nothing else on the line is busy | loss | A correction replaced a gap in your movement history. The chart shows the gap. |
| Fine on one server, unplayable on the next | route | Not your line but the path to that entry point. Test both from the picker above. |
Counter-Strike 2 kept the 64 tick server loop that CS:GO had and added a timestamp to the inputs travelling into it. Before, an action was filed under the tick it arrived in, so two players clicking 15 ms apart could be resolved as though they had clicked together. Now the packet carries the microsecond and the server orders the two shots correctly. That is a real improvement, and it is a narrow one: it fixes the rounding of information that arrived.
A lost packet carries no timestamp, because it is not there. The server does not learn that a shot was fired, has nothing to place, and simply continues from the last state it received from you. This is why players who bought a faster monitor and a lighter mouse still report shots that do nothing - the precision at both ends of the connection improved and the hole in the middle did not.
The 64 packets per second in each direction are small, around 250 bytes with headers, which is why CS2 runs happily on connections that struggle with a video call. Volume was never the problem. The problem is that at 64 Hz a single packet is 15.6 ms of your view of the match, and two consecutive drops put you 31 ms behind a duel that is decided inside a tenth of a second.
There is a second path worth separating out. Competitive matches do not run to one address: Valve routes match traffic through its own relay network, so what your provider actually carries is the leg between you and the nearest entry point. A connection that behaves against one location and falls apart against another is telling you about that leg, not about your router - and the server picker above exists so you can see the difference instead of guessing at it.
No. Sub-tick timestamps your input between the server's ticks, so a shot fired 4 ms after a tick is no longer rounded to the next one. That removes rounding, not loss. A packet that never arrives carries no timestamp at all, and the server has nothing to place. Sub-tick makes a clean connection feel sharper; it does nothing for a lossy one.
Under 30 ms is where you can trade duels evenly. Between 30 and 60 ms is comfortable for everything short of a knife fight around a corner. Above 80 ms you lose most peeks before you see the model. Valve matchmaking picks a datacentre by ping, so a bad route usually shows up on one region only - use the server dropdown above to compare.
Rubberbanding is the server correcting your position after it stopped hearing from you. It is caused by lost packets or by jitter, not by bandwidth. A speed test moves one large file and reports an average; it never notices the 40 ms gap that pulled you back across the map.
No. Tick rate decides how often the server updates the world; packet loss decides whether your update arrives at all. At 1% loss you lose roughly one update every one and a half seconds either way - on a faster server the update you lost was simply a more precise one.