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

Everything about latency. This section is mainly user/consumer discussion. (Peer-reviewed scientific discussion should go in Laboratory section). Tips, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
jassine
Posts: 59
Joined: 21 Jan 2024, 10:38

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

Post by jassine » 26 Jul 2025, 14:21

hello, these are my packets, maybe someone can analyse them (i play PUBG )

orange: incoming packets
blue: outgoing packets
Attachments
delay, packet loss
delay, packet loss
bad.png (83.81 KiB) Viewed 1071 times
no delay
no delay
good.png (101.3 KiB) Viewed 1071 times

13n47
Posts: 26
Joined: 07 Sep 2022, 05:42

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

Post by 13n47 » 03 Aug 2025, 06:11

For Valorant the issue comes down purely down to netcode. The most consistent way I can fix my match is to change the FPS limit to very low(like 6fps) before joining the match. Let it sit for the first 15 seconds and then back to unlimited. It's not guaranteed to work but with this method I gained a shitton more consistency whereas before every match felt like shit. Also limiting to 128 fps is still giving more consistency.

There's something happening during match init that heavily impacts the game feel. Most likely network buffers or some interp calculations.

There is absolutely nothing wrong with your hardware or internet. And I'm pretty sure CS2 could have something similar although i haven't tested on that yet.

For example, if you introduce packet loss during a match or match init and then remove the packet loss, the hit reg might get slightly faster but enemy player models start moving much faster. I don't understand why the game engine cannot restore the game to a previous state.

Also duplicating outgoing packets to the server has similar effect but less wonky movement for enemy models. I'm assuming server now receives packets slightly faster because some are bound to arrive faster and thus lowers the network buffering on server side, making your shots register faster.

User avatar
Slender
Posts: 1513
Joined: 25 Jan 2020, 17:55

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

Post by Slender » 03 Aug 2025, 07:28

13n47 wrote:
03 Aug 2025, 06:11
For Valorant the issue comes down purely down to netcode. The most consistent way I can fix my match is to change the FPS limit to very low(like 6fps) before joining the match. Let it sit for the first 15 seconds and then back to unlimited. It's not guaranteed to work but with this method I gained a shitton more consistency whereas before every match felt like shit. Also limiting to 128 fps is still giving more consistency.

There's something happening during match init that heavily impacts the game feel. Most likely network buffers or some interp calculations.

There is absolutely nothing wrong with your hardware or internet. And I'm pretty sure CS2 could have something similar although i haven't tested on that yet.

For example, if you introduce packet loss during a match or match init and then remove the packet loss, the hit reg might get slightly faster but enemy player models start moving much faster. I don't understand why the game engine cannot restore the game to a previous state.

Also duplicating outgoing packets to the server has similar effect but less wonky movement for enemy models. I'm assuming server now receives packets slightly faster because some are bound to arrive faster and thus lowers the network buffering on server side, making your shots register faster.
you just lower power consumption with fix fps to 6. It like windows reinstall or full power off pc.
you are simply discharging the capacitors in psu

andrelip
Posts: 166
Joined: 21 Mar 2014, 17:50

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

Post by andrelip » 04 Aug 2025, 16:59

Nice topic, OP!
I noticed the same issue and did some testing with OpenWRT (Cake QoS, traffic control, and so forth).

Some observations:

1) Here, using Cake QoS and having some load, I get lower latency (by about 2 ms) compared to when the connection is idle. It's probably due to power saving on the ISP's fiber modem. If you enable the CS2 network graph, it's the difference between green spikes and a completely flat line.
2) It actually seems to perform worse when it's flat. The game feels smooth, but it really feels like everyone else suddenly got better.

Now, some points to consider:

1) We may be seeing some form of batching (like interrupt moderation), which could occur on your PC or at any other node. Small packets might be delayed until a batch is full or a time limit is reached. So larger requests may force packets to be sent or received immediately.
2) A "clean" connection might also mean your packets are reaching the server faster, so enemies’ reactions feel quicker too. That could make hitting them feel harder. It’s plausible—but I suspect that’s not the main cause.
3) The attacker might be experiencing connectivity issues, allowing them to see and shoot you before your game is updated. This gives them several milliseconds of advantage. You're basically seeing their past movements, so peekers' advantage gets amplified a lot.
4) I think there are some ways to check prediction and lag compensation/hitbox behavior. That might help troubleshoot what’s really going on.
5) When watching demos, we may or may not be seeing the "normalized" version. The server’s real-time view of a player might not match what’s shown in the demo.
6) CS2 left-down numbers are 100% network related and added by Valve to investigate some weird video. Maybe it can help identifying good and bad state. See more here: https://www.reddit.com/r/GlobalOffensiv ... _this_sub/

----

[cs2 network info in left-down]
Gameplay captures must include legible r_show_build_info 1
V = valve / S = dedicated / L = loopback

22 = receive latency, accurate jitter, counts buffering to smooth over packet loss
33 = latency average, send + receive, no buffering (lazy like the scoreboard value)
06 = client receive margin, spikes on interp
18 = send packet loss, this is actually 2% - more than 10% clamped to 99
09 = receive packet loss, this is actually 1% - more than 10% clamped to 99

1:0 = server issues like yellow on net graph when it can't keep up with the command queue

16 = render interpolation ms (correction: at tickrate)
07 = minimum frametime ms for the past few seconds
08 = maximum frametime ms for the past few seconds

Post Reply