The Game Feels Sluggish, Enemies Are Too Fast, and You Die in a Millisecond

[rusihhh]

Here’s a capture from my recent FACEIT CS2 match on de_mirage. Ping during the entire match was between 45–55ms.

The game felt good — I’d even say above average. I was clearly seeing opponents and could take fights confidently. Hit registration felt consistent.

The recording covered the entire match, from warm-up to the final screen, capturing all network packets sent and received by the computer.

Here are the results:

Incoming and outgoing traffic graph:
Red — outgoing (OUT)
Black — incoming (IN)
The moment of ALT+TAB is marked separately.

Wireshark stats — udp.port == 27021 (both directions):
Total packets: 285,691
Average size: 720.42 bytes
Distribution:
- 640–1279 bytes: 148,316 packets (51.91%)
- 320–639 bytes: 100,834 packets (35.29%)
- 1280–2559 bytes: 15,110 packets (5.29%)
- 160–319 bytes: 18,473 packets (6.46%)
- 80–159 bytes: 2,958 packets (1.04%)

Wireshark stats — udp.dstport == 27021 (OUT):
Total packets: 136,088
Average size: 664.55 bytes
Distribution:
- 640–1279 bytes: 70,945 packets (52.13%)
- 320–639 bytes: 63,918 packets (46.97%)
- 160–319 bytes: 195 packets (0.14%)
- 80–159 bytes: 256 packets (0.19%)
- 1280–2559 bytes: 10 packets (0.01%)

Wireshark stats — udp.srcport == 27021 (IN):
Total packets: 149,603
Average size: 771.25 bytes
Distribution:
- 640–1279 bytes: 77,371 packets (51.72%)
- 320–639 bytes: 36,916 packets (24.68%)
- 1280–2559 bytes: 15,100 packets (10.09%)
- 160–319 bytes: 17,514 packets (11.71%)
- 80–159 bytes: 2,702 packets (1.81%)

[rusihhh]

# CS2 (Cybershoke Duels) - Wireshark UDP Packet Analysis

## Match 1:
Server: Cybershoke Duels
Ping: 50–60ms
UDP filter: udp.port == 27021

Inbound (udp.srcport == 27021):
- Avg: 746.50 bytes
- Min/Max: 60 / 1342
- Distribution:
• 640–1279 B: 57.75%
• 320–639 B: 27.70%
• 1280–2559 B: 6.90%

Both directions:
- Avg: 796.48 bytes
- Min/Max: 60 / 1342
- Distribution:
• 640–1279 B: 52.56%
• 320–639 B: 27.56%
• 1280–2559 B: 12.80%

## Match 2:
Server: Cybershoke Duels
Ping: 3–5ms
UDP filter: udp.port == 27030

Inbound (udp.srcport == 27030):
- Avg: 933.05 bytes
- Min/Max: 60 / 1327
- Distribution:
• 1280–2559 B: 36.53%
• 640–1279 B: 34.67%
• 320–639 B: 10.08%

Both directions:
- Avg: 783.13 bytes
- Min/Max: 60 / 1342
- Distribution:
• 320–639 B: 36.04%
• 640–1279 B: 29.87%
• 1280–2559 B: 22.22%

## Match 3:
Server: Cybershoke Duels (de_dust2)
Ping: 200–240ms
UDP filter: udp.port == 28022

Inbound (udp.srcport == 28022):
- Avg: 865.56 bytes
- Min/Max: 60 / 1328
- Distribution:
• 640–1279 B: 63.00%
• 320–639 B: 19.21%
• 1280–2559 B: 12.56%

Both directions:
- Avg: 824.88 bytes
- Min/Max: 60 / 1328
- Distribution:
• 640–1279 B: 70.80%
• 320–639 B: 19.55%
• 1280–2559 B: 6.70%

[n1ghtik]

I conducted tests on the same server at the same time on 4g and fiber ppoe connection
I turned on and off the 4g connection and ethernet devices in device manager

on 4g I had ping 20~ms higher than on fiber, 20-100ms jitter, game felt great, people on dm can kill me
360 spin by swiping mouse from the beginning of the mousepad to the end on the horizanotal mouse returned the aim to different positions, on 4g mouse sensor went a longer distance and did 1.2x of the distance on fiber.

on 4g connection I had unstable jitter, small packet loss, on fiber jitter is minimal with no packet loss
but the game is still better on 4g
I think we have no idea what we are dealing with here

[rusihhh]

I conducted tests on the same server at the same time on 4g and fiber ppoe connection
I turned on and off the 4g connection and ethernet devices in device manager

on 4g I had ping 20~ms higher than on fiber, 20-100ms jitter, game felt great, people on dm can kill me
360 spin by swiping mouse from the beginning of the mousepad to the end on the horizanotal mouse returned the aim to different positions, on 4g mouse sensor went a longer distance and did 1.2x of the distance on fiber.

on 4g connection I had unstable jitter, small packet loss, on fiber jitter is minimal with no packet loss
but the game is still better on 4g
I think we have no idea what we are dealing with here

Yes, that's actually an interesting observation — and I can confirm it.
I’ve had situations where the game felt **worse** with **no packet loss and minimal jitter**,
but actually **better** with **some packet loss and a bit of jitter**.

[TN_fun]

I conducted tests on the same server at the same time on 4g and fiber ppoe connection
I turned on and off the 4g connection and ethernet devices in device manager

on 4g I had ping 20~ms higher than on fiber, 20-100ms jitter, game felt great, people on dm can kill me
360 spin by swiping mouse from the beginning of the mousepad to the end on the horizanotal mouse returned the aim to different positions, on 4g mouse sensor went a longer distance and did 1.2x of the distance on fiber.

on 4g connection I had unstable jitter, small packet loss, on fiber jitter is minimal with no packet loss
but the game is still better on 4g
I think we have no idea what we are dealing with here

I'm sure if you play 1-2 days on 4g it will work as bad as fiber optic

[rusihhh]

---

I'll say it clearly: I **believe** — and my belief aligns with my tests — that what matters most is **what comes in the packet**, and **when**.

I tested this by recording my game and packet flow, then reviewing in slow motion.
Every time I died suddenly, it happened **exactly when a certain packet arrived** — everything was rendered instantly.

---

If a packet comes **with your death included**, then unfortunately — **you die immediately**. No reaction possible.

---

When the enemy appears and you die instantly, it’s not a performance issue.
It’s likely that:
- The game sent you *everything too late* in one packet.
- Or the internal game logic **batched actions together**.
- Or it skipped sending intermediate states.

Your CPU, GPU, and game client **react instantly** — they did their job.
But **what they received** — that’s the issue.

---

This might not be a network delay at all.
It could be a design issue.
For example:
- Someone might receive this in one tick: `['enemy movement', 'shots fired']`
- Another might get:
Tick N: `['chicken movement']`
Tick N+1: `['enemy movement', 'shots fired']`
→ He dies without ever seeing the enemy.

---

I also noticed similar behavior in Rainbow Six Siege —
some players receive larger packets, others smaller ones.
That might be by design to balance connections.

In CS2, I observed slight variations in average packet sizes.
Maybe that’s harmless. Maybe not.

But if CS2 uses a different **netcode logic**,
then **instant deaths** may be caused by the **order, grouping, or missing content in the packets**,
not by any external factor.

---

**Conclusion:**
The problem is **what’s inside the packets**, and **in what order they come**.
The game client only draws what it receives.
If it receives your death — that’s what it shows first.

---

*Sorry for my English — I might express things strangely, I’m using a translator.*

[ChristophSmaul1337]

Trying my luck here again to clear a few things up. Usually, I'm not including this in my replies, but as you've attacked me before, I'm going to say this upfront: I have hands-on experience with the Source engine as I've programmed plugins and server management tools for CS:GO before. In terms of Source engine, I do know exactly what I'm talking about as I've directly interacted with the engine before. So, what I'm about to type is true for the source engine (CS:GO, CS:S etc). Other games I didn't program for, but I still know a whole bunch of stuff about netcode in different games. Alright, let's see now.

- The game sent you *everything too late* in one packet.

This cannot happen without the game noticing that something is wrong. First off, the game won't just "send you everything too late in one packet". If that would be the case, it would be a "bug" or at least a known problem with a game's engine and how it handles its networking. If this were the case, every player would have the problem and not only some select players.

There are 2 main ways that your hypothetical scenario could manifest itself:

1. Packets have been delivered "out of order".
2. Packets have been delivere in order but are delayed.

Let's see if we can spot this.

Scenario 1. What's happening here is a little bit complicated. As I've said before, the game server sends your client a constant data stream, 64 packets per second. Each packet represents a "frame" of game state. The network protocol used for virtually any real-time online game is UDP, which "doesn't care" about delivery success of packets (oversimplified). UDP, as used in gaming scenarios, donesn't have mechanisms to check for missing packets, and it doesn't need to, because by the time a missing packet would be detected and re-transmitted, the information contained in that packet is already out of date. UDP works like a "fire and forget" cannon. The server fires data at your client and instantly upon firing out the data forgets about it. It has no means of telling that data has arrived.

Let's say you're receiving a constant stream of packets from the server. In an ideal world, it looks like this:

1-2-3-4-5-6-7-8-9-10

Each number represents a packet.Your client would display this as perfect, stutter-free, normal gameplay.


If there's a hiccup along the path, data packets can be delayed a little bit. In this theoretical scenario, it would look maybe like this:

1-2-3-6-5-7-4-8-9-10

As you can see, everything still looks like normal up to the 4th packet. Packet #4 has been delayed along the path somewhere, so it doesn't arrive in it's intended "location" inside of the data stream. Your client will now display a "jump": After packet #3, it sees #6, so it displays the game state as seen in packet #6. From now on, it waits on subsequent packets that are further forwards in time. After packet #6, packet #5 arrives at the client. However, packet #5 contains a game state that's older than what the client is already displaying at the current moment in time. The client has no idea what to do with this packet, as it contains outdated information - it is discarded. Now, here's the important part: As packets #4 and #5 are discarded, they'd show up as packet loss - in my example with 10 packets, 2 are discarded, meaning a loss of 20%.

The simple conclusion is that yes, out of order packets might cause this effect visually, but it would be diagnosable as packet loss. Game overlays would indicate that packets have been lost if out of order packets were to blame.

Scenario 2: This is infinitely more simple to understand. If there's some delayed data, it is the literal definition of increased latency, or ping. If this happens, it will show up in a game's diagnostic overlay as either high ping or excessive jitter.

- Or the internal game logic **batched actions together**.

As hinted at before, this could be possible and some games have done this in the past, namely Battlefield 3 and Battlefield 4. The reason these game have done that however are of a different nature. These games run on low tickrates, like 10Hz. Some actions you can perform within the game can "fit" multiple actions into one frame. For example, there are fully automatic machine guns and assault rifles that have a higher rate of fire than what would fit into one frame of game state. If you shoot your fully automatic MG3 at someone and you're hitting him 2 times, both of these hits occured within one frame of game state, meaning that both hits are transmitted to the opponent within one data packet. This simply would deal 2x damage than what would usually be possible within one gamestate frame.

However, this doesn't apply to modern games like CS, Siege and so on, and also doesn't fit the usual problems described on this forum, because of 2 main reasons: Number one, the reason this was done in BF was because of a technical necessity. The game's netcode was too slow to handle the situation otherwise. Modern games, especially the competitive ones, have such fast tickrates that this isn't a concern at all, so this isn't done. The only exception would be if the server would be stalling for some time and it would need to "catch up". However, most modern games also have diagnostic overlay symbols for slow server performance, so this should be visible. Secondly, this is hard-coded into the game, so everyone playing the game would experience this. The problems in this forum are niche however, there are people who can play CS, Rainbow or any other game without any problem. If such behaviour was hardcoded into the game, every player ever would experience it. We don't see this, so this can be ruled out.

- Or it skipped sending intermediate states.

Again, this can happen, but the only real reason for this happening would be the server stalling and "catching up" with the current game state. This would trigger a "slow server" warning in a game's diagnostic overlay.

It could be a design issue.

Again, if it were, everyone would have it. And we don't see that.

- Someone might receive this in one tick: `['enemy movement', 'shots fired']`
- Another might get:
Tick N: `['chicken movement']`
Tick N+1: `['enemy movement', 'shots fired']`
→ He dies without ever seeing the enemy.

This is impossible. This would mean that the server changes its tickrate and sendrate for one client, while being on another tick/sendrate for another client. It can't do that. Even if a game changes tickrate dynamically, at any moment in time, it's always the same for everyone.

Let's say tick N is a valid game state and depicts enemy movement. This gamestate exists on the server and is sent to the clients. If one player sees tick N as "enemy movement", every player sees tick N as "enemy movement". Clients can only see the game state the same way the server saw it. The same is true for tick N+1. It is a valid game state on the server and it's pushed to clients as such. If one player sees tick N+1 as "enemy movement, shots fired", every other player also sees this exact game state.

The only reason why one player might not have seen the game state from tick N is because it either arrived out-of-order or it was lost entirely. Both scenarios would show up on a game's diagnostic display.

then **instant deaths** may be caused by the **order, grouping, or missing content in the packets**,

Again, this can't happen, because if a packet is missing content, the client can't interpret it as such and it's simply discarded, again showing up on a game's diagonstic display.

So yeah, hope this helps a little. Out of order packets are a thing and it can cause problems, but these are simple to diagnose and track down. The premise of this post was that this could happen without showing up on a connection monitor, as with anything you've proposed so far, that's not possible. Any of your suggested "problems" would show up on a diagnostic display somewhere.

[MontyTheAverage]

Someone tell me what is going on here...

-Connect to new Ethernet: "sluggish/enemies too fast/ die in millisecond" issues significantly reduced for but the issues return after a match or two or middle of the match.

-change resolution: "sluggish/enemies too fast/ die in millisecond" issues significantly reduced for but the issues return after a match or two or middle of the match.

-Turn on or off Gsync: "sluggish/enemies too fast/ die in millisecond" issues significantly reduced for but the issues return after a match or two or middle of the match.

-Try an usb ground loop isolator: "sluggish/enemies too fast/ die in millisecond" issues significantly reduced for but the issues return after a match or two or middle of the match. (Works more inconsistently again after plugging and unplugging from the usb hub. Current testing this lead more)

-First match of the day: "sluggish/enemies too fast/ die in millisecond" issues significantly reduced for but the issues return after a match or two or middle of the match.

Connect to a VPN: "sluggish/enemies too fast/ die in millisecond" issues significantly reduced for but the issues return after a match or two or middle of the match.

Try change some other random windows settings: "sluggish/enemies too fast/ die in millisecond" issues significantly reduced for a match but the issues return after a match or two or middle of the match.

It is like when the problem is mitigated, the anomaly lag breaks it again causing the temporary mitigation to not work anymore until after awhile again. FYI: this behavior has been same across games, PC systems, networks and location and hard to correlate to one cause for the problems. That is why at this point I can not make sense of this anymore. Drives me crazy

[rusihhh]

...

I'm not attacking you — and I appreciate your insights. Many of your points are valid.
But I think there's more nuance based on what I've personally observed in real matches.

---

Engine-Level Behavior in Siege:
In Rainbow Six Siege, I've noticed a clear pattern:

→ When a packet is lost or delayed, the next packet from the server is significantly larger
→ Once the missing data is received, packet sizes return to normal

This suggests that the engine detects missing or dropped information and tries to include it in the next packet — not via retransmission (like TCP), but through a kind of soft fallback logic.
It's subtle — but repeatable.

---

About Tick Timing:
I'm not talking about dynamic tickrate changes.
What I mean is: the **gameplay event happened**, but **you received it too late to react**.

Here’s a simplified timeline:

Tick N: Enemy starts moving
Tick N+1~3: You should receive this info
Tick N+4: You receive... chicken movement behind a wall
Tick N+5: Suddenly receive: `['enemy moved', 'shots fired', 'you died']`

→ You die instantly — without ever seeing the enemy approach.
→ The movement existed on the server, but your client never rendered it.

---

Why I Think This Isn't Just Packet Loss:
- No loss/jitter warnings appear
- Teammates and HUD elements update normally
- You do receive data — just not the *right* data
- It feels like the packet contents were misprioritized

This leads me to suspect that:

→ Packets aren’t fully equal for all players
→ Server might prioritize different content per client (based on perceived relevance, region proximity, etc.)
→ So in your case: your packet had chickens and timers — but not enemy movement

---

Final Thought:
I believe those “sudden death” moments happen when your client receives a single composite packet that includes:

- Enemy appears
- Enemy fires
- You die

But earlier packets with crucial movement info never reached your screen — or were skipped/discarded internally.

It might not be a traditional bug, but it’s a flaw in how the engine chooses and bundles what data to send you.

Would love to hear if others experienced something similar.

[rusihhh]

Your sudden death often happens when a “magic packet” — let’s call it that — arrives.

That packet contains your death, possibly along with the first and only enemy movement you ever saw.

→ No prior movement
→ No buildup
→ Just: enemy appears + shoots + you die — all in one go

Because earlier packets (with the movement) were either skipped, delayed, or not shown — you had zero time to react.

This might not be packet loss in the traditional sense — but a flaw in how the game bundles and prioritizes events.