hello, these are my packets, maybe someone can analyse them (i play PUBG )
orange: incoming packets
blue: outgoing packets
The Game Feels Sluggish, Enemies Are Too Fast, and You Die in a Millisecond
Re: The Game Feels Sluggish, Enemies Are Too Fast, and You Die in a Millisecond
- Attachments
-
- delay, packet loss
- bad.png (83.81 KiB) Viewed 1071 times
-
- no delay
- good.png (101.3 KiB) Viewed 1071 times
Re: The Game Feels Sluggish, Enemies Are Too Fast, and You Die in a Millisecond
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.
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.
Re: The Game Feels Sluggish, Enemies Are Too Fast, and You Die in a Millisecond
you just lower power consumption with fix fps to 6. It like windows reinstall or full power off pc.13n47 wrote: ↑03 Aug 2025, 06:11For 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 are simply discharging the capacitors in psu
Re: The Game Feels Sluggish, Enemies Are Too Fast, and You Die in a Millisecond
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
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