BumFlannel wrote: ↑31 Jan 2025, 05:11
In response to some posts. This is going to be very long, it's based on a decade of observation and testing in CS.
CS2 like CSgo uses 1200mtu/max routable. Packet sizes can be larger than this due to packet headers. I forget the exact size but they max around 1330 or 1350 bytes with headers I think.
CS2 and CSgo of the last few years sends way too much data for the type of game it is. Fletcher Dunn admitted CS2 sends too much data because of the unoptimized networked anim graph which wasn't used in CSGO, and they are working to fix it, but it's a long job. This was about a year ago. However, CS2 doesn't really send that much more data compared to CSgo in its later years so I really don't think it's just the networked anim graph that is the issue.
In modern CSGO in a 5v5 official 64 tick server you would be receiving an average of about 86 packets per second. Some ticks you'd be receiving 2 packets because the data exceeded the max routable size, so the server needed to send 2 packets which are recombined on the client.
The issue here is that those 2 packets are sent on the same tick so pretty much at the same time/very little (0.0001ms) time between them and on route they can very easily become out of order. Valves fix for this was to add an artificial delay of 1ms to give all packets in the tick time to be delivered before being processed and recombined.
Now I don't know if this 1ms delay is total for each tick despite how many packets are sent for the tick, but I would imagine it would need to be 1ms for each packet received because on a full official DM server for example you receive on average about 140 packets per second.
Using wireshark I've seen as many as 9 packets being received in a single tick in cS2, and probably an average of about 4 packets per tick, at least half of which being full (1300+ bytes) packets. If the artificial delay was a total of 1ms for all packets to be received then if a single packet hit after that 1ms then every packet after it, outside of ones delivered out of order before it, would be classed as dropped and therefore not processed.
Csgo official DM used to send between 1 to 3 packets per tick, with large numbers on things like match start and end etc.
I believe the packets are out of order quite a lot so are being dropped but the telemetry isn't reporting it. I also believe SDR, steams own protocol, is implementing some form of retransmission to alleviate this problem but ironically makes the problem worse because it means more data has to be sent.
Because of the amount of data sent per tick being apparently too large for the type of game CS is, I believe any data lost between the relay and the client is being resent within the packets for the next tick, inflating the packets sent for that tick meaning more packets get dropped and then again the next tick has to pick that up. This would explain the excessive data sent from the server. I believe this, plus the extra latency inherently needed for lag comp to be able to handle this late/retransmitted data it what is making the game so unresponsive and inconsistent to play. And because you are technically receiving all packets, and the game is restructuring them into the correct order based on built-in latencies for compensation, telemetry doesn't show it as packet loss or our of orders. It also doesn't show as jitter because the deltas of packets are low but the actual contents/content order, rebuilding, and compensation of the packets is where the jitter comes from, after networking.
It's common when you get peeked or peek someone the server sends more packets for that burst of activity. This seems to be when desync mostly kicks in with erratic fast moving enemies, stutters, rubber banding, missed shots and delayed kills. So imagine someone peeks you so the server bursts 5 packets for a few ticks. Now imagine half those packets don't get received. Your client notifies the relay of the packets it did receive, relay says "ok you didn't receive packets a, b and c, I'll package those into the next tick that passes through me to be resent". What you would expect from this is stuttery enemy movement as they appear around the corner. But with extra buffering to compensate what you'd actually see if the enemy peek smoothly, just faster because now they need to catch up to their old position. You'd also see shots mistimed to movement, running and gunning. Combined together it looks like you're getting running prefired with inhuman reactions/insane peekers advantage, and because this is being caused by retransmission, the states you see never occured that way in the simulation on the game server, meaning your hit reg is going to be screwed up too because the server can't lag compensate accordingly.
My issues started in CSGO in 2015 right before they did the reanimated update (started in Operation bloodhound). This is also exactly when the widespread choke problem started for a lot of players but not for everyone, which I believe was caused because of the now inflated packets being sent and increased rate to handle the new animation system, which they were most definitely testing on the server side before they rolled it out as a patch as with Operation bloodhound this is when you started seeing all the animation anomalies. Enemies teleported around corners in a single frame, ragdolls were jittering through meshes but not solid geometry/bsp due to disagreeing server and client side collision models, the new animation systems hit capsules in the server side while the client side was still running the old hit box system. This is also when you started seeing third party ragdolls corrected to the server side position when killed which was inherently part of the new animation and lag compensation system that hasn't yet been rolled out. That came out months later, in September of that year I believe.
We saw choke in the net graph at this time because there were no systems in place to compensate for it. I believe these systems were added in 2017 where they released a patch with a note in it somewhere along the lines "fixed choke for some users, particularly on dsl connections". The choke went away with this patch, peekers stopped teleporting around corners but now what we had instead was the Ferrari peek insane inhuman peeks and shitty hitreg, aka, desync.
So I think 2017 was their first iteration of mitigating, not fixing, a very common problem causing choke, which many people still suffer with to this day and it's just masked so you don't see any actual indication of it in the telemetry.
Another thing supporting this is that after this patch you could force choke with clumsy and netgraph just wouldn't report it even though you 100% knew you had it, because you were forcing it. You could force like 50% loss and not see any indication of packet loss whatsoever in gameplay. Your own movement, enemy movement all still looked smooth, as in not stuttery or teleporting, just moving outside of game mechanics. The only indication was huge variation in the server response for hits, some could be instant some could take half a second. This is direct evidence that even though there was huge packet loss, somehow packets were still getting through but heavily delayed which suggests crazy lag compensation and retransmission. Once you forced about 75%+ loss this is when you would suddenly start teleporting all over the map and everything went to shit, showing there was some very high packet loss threshold before compensation just outright turned off.
You can still force packet loss in cs2 with clumsy and not see it in the telemetry but the threshold does seem to be much lower now. You will see packet loss in the steam overlay but not in the in game telemetry and not as much as you know you've forced in the SDR stats.
I think the fix for networking issues is to make sure packet sizes never exceed the max routable size ensuring a single packet per tick.
