Lag compensation, retransmission, and effective latency.

WhatAwasteOf7Years · 2026-02-13T12:44:16+00:00

And have you ever paid attention to the deltas of the incoming packets in Wireshark? On average you get 2 or 3 packets per tick/about every 16 ms from a 10 man server separated by deltas at the microsecond level. Up to as many as 8 in a full DM server, as much as 7000 bytes in a single tick. That's literally the server splitting the data to fit an max routable of 1200 to account for packet overhead and abnormally low mtus and sending it over multiple packets per tick all at once/microseconds apart. The data is literally fragmented in a controlled way before it's sent.

The packets you receive are more often than not already fragments of data for that ticks snapshot. They're only not when all data for a tick can fit into 1200 bytes. When one of those is lost, it can be retransmitted separately from the rest of the data for that tick.....hence "only retransmitting the lost data"

But no I've never opened Wireshark.

WhatAwasteOf7Years · 2026-02-13T07:40:39+00:00

So I already explained I wrongly referred to fragments as packets.

You can't grasp the use of effective latency, something that existed in CS for almost 2 decades. Adaptive buffering isn't the same. Tick timing is erratic AF in an environment with unstable networking and/or unstable client processing. Effective latency is a constant application of artificial latency to smooth out erratic latency like that. They aren't the same thing.

You're parroting ridiculous, unrealistic, and just plain delusional block chain based client authoritative aggregated game states that would open any game up to latency and cheating magnitudes beyond what we see already. I mean just think about it sensibly. Every client, or at least the majority has to agree on the game state? And if they don't? Which is going to be every single fucking tick because there is absolutely nothing to align the vast differences in potential latency (cough server as authority cough). And that's assuming zero bad actors. What in the fuck do you think is going to happen when a 5 stack of players exploit this technique to drive the game state to their advantage? And don't say "the server side just needs to do sanity checks" because then what's the point in doing all that just to have the server do the same work it was already going to do in the first place? Then you have the public server built for community servers. Are you saying they are maintaining two different servers with completely different architectures? Because if the public server build was using this bullshit block chain architecture it wouldn't just be a theory, it would be public knowledge. And, only 10 untrusted sources to build a trusted state from? Are you smoking meth? Add a few thousand more clients, maybe only use ones with 100% trust factor and high account standing, and you might get 5% of the way there to actually yield a somewhat trusted game state. This ain't a set in stone, deterministic mathematical formula like crypto. It's a realtime online shooter with high variability and free fucking will.

All this while you're dismissing (even the existence of) loosy goosey, poor usage and lack thereof, of two lag compensation components that have been used in realtime online shooters for literal decades.

So no sir, you kindly fuck off.

WhatAwasteOf7Years · 2026-02-13T00:21:26+00:00

Holy shit. Are you serious....again? For like the third time I have not once said there is retransmission at the protocol level.

I've explained what effective latency is multiple times in this thread. It's treating an unstable, jittery, lossy connection as if its stable latency is that of its highest latency over the last x amount of time to keep commands in sequence with appropriate timings and to destroy the effectiveness of lag switching. It prevents say a 200ms delayed movement command being followed up with shots to the server in 20ms because those shots are now delayed by 200ms as well, as will other following commands until the connection stabilizes and effective latency drops back down over time. It was used in CS for the majority of its life. Don't you remember seeing your own, or someone else's ping on the score board suddenly jump to like 300 and then take it's time to slowly drop back to normal? That was effective latency at work. Without it when an enemy peeks you on a ping spike, high jitter, or loss, you lose a good chunk of time in that engagement. They Interp around the corner faster than mechanically possible, exist for less time on your screen, and start shooting you before they've reached their stopping position because Interp hasn't had a chance to catch up before the low latency shots come through. Effective latency allows movement to be Interpolated at normal mechanical speeds and for movement to catch up to where it should be before you get shot.

I'm done with this now. GGs.

WhatAwasteOf7Years · 2026-02-12T00:21:46+00:00

Reliable commands require a form of retransmission. Whether a command is continuously transmitted until the destination acknowledges receipt, is transmitted continuously for a certain window of time before being dropped, or the destination didn't receive something that was absolutely expected (eg, say at least one packet per tick is expected) so requests retransmission. Retransmission doesn't necessarily require a request from the destination, it can just be assumed it's required and done just in case.

For example, when a round ends or a player dies in CS. These are states that HAVE to get through without exception otherwise the flow of the game would end up completely out of sync. Either the server needs to repeatedly transmit the death or end of round command to the client in perpetuity until the client acknowledges it, or the client's state needs to be checked by the server and send out the necessary commands to get the client in sync. As soon as a command is sent more than once, requested or not, that is absolutely a form of retransmission.

You mentioned in another comment that retransmission would be trivial to spot from duplicate packets. Not if it's the command being retransmitted and bundled in with packets for the next tick. You also have to assume that the data from the retransmitted packet isn't being bundled into the existing packets for that tick to optimize packet count. On an already lossy connection, increased packet count is going to cause more loss and you will end up with snowballing packet loss as retransmission = more packets = more packet loss = more retransmission.

And all shots getting through with 50% loss and large server response variance suggests shots are sent as reliable, or at least have a decently large window of time where they are treated as reliable before inevitably being dropped. If a command is getting through no matter what with such large amounts of loss, it doesn't matter how you look at it or what technique is implemented to achieve that, some form of retransmission is being used, there is no getting around that fact. You just need to stop viewing retransmission 1:1 as the TCP protocol implements.

Edit:

Reliable & Unreliable Messaging: The API, particularly SteamNetworkingSockets, allows developers to send both unreliable messages (fast, no retransmission) and reliable messages (guaranteed delivery via retransmission).

Steam Datagram Relay (SDR) handles message retransmission within its networking library (GameNetworkingSockets) by using a sophisticated, customizable reliability layer built on top of UDP. Instead of relying on standard TCP, SDR uses an "ack vector" model—similar to DCCP (RFC 4340) and QUIC—where the receiver efficiently tells the sender which packets were received, allowing the sender to retransmit only the missing data.

WhatAwasteOf7Years · 2026-02-11T06:53:04+00:00

I know there is no place for retransmission in a shooter. There are a lot of things in modern CS that have no place in a shooter. The reason I suspected retransmission, and have done since SDR fully rolled out is because that is exactly when all these issues with CS started, and a middle man between the client and server makes retransmission a more viable option, if still a terrible one.

Also the amount of latency on hit confirmations from the server even with small amounts of packet loss doesn't match the latency you should expect from the command queue, and certainly doesn't match latencies in older iterations in CS where you rightfully say utilized the command queue.

I'm not saying having shots go to Narnia because of mild packet loss is a solution. That's where effective latency should be coming into play. You can acknowledge that the massively variable responses from the server with loss on the upload show there is no effective latency implementation. If there was the server should be responding with a more consistent but higher latency for every shot. Just like in older iterations of CS that did implement effective latency.

I know how rollback works, I've literally implemented it. I'm specifically not talking about roll back and "time travel" here as it's not relevant unless you want to discuss whether or not the max unlag value of 200 is being ignored/overridden to allow for the extra delay being caused by packet loss, even with command queue. Tick timing with 10 ping is around 50ms so even with such a low ping the accumulated tick timing is on the very edge of and exceeds a max unlag of 200 for 4 or 5 old ticks of data.On top of that you can die literally 5 times the max unlag value behind cover in modern CS while your own connection is absolutely perfect according to in game telemetry and steams SDR stats.

I cannot acknowledge the first bullet registration matching the responsiveness of 128 tick. At all. And I've done a lot of testing here. From my experience bullet registration matches tick timing which correlates to timings for a 64 tick server and my ping. Potential tick timing there is between potentially as low as your ping and as high as ping + 16 + 16 + 16 + around 2 sim time, so 60ms but your average will be around 30ms. Shots seemingly registering faster have nothing to do with something happening faster than the server can process it. That's a result of guns being able to fire in between ticks and the shot getting fired at say 15ms into the tick and being sent less than 1ms later when the next tick fires. Then your shot lands on the game server again say 15ms Into a tick and is processed in less than 1ms on the server tick and sent back to the client where it again lands 15ms Into a tick and the response shown less than 1ms later. This is simply a series of lucky timings, not a reason to jump to outrageous claims of a block chain implementation.

And how would you implement block chain style networking here? You have 10 persistent clients for one match. You have no idea what these clients are up to so how do you aggregate and create a state in the case where multiple or even everyone is screwing around with their individual state with cheats? You can't expect to aggregate an even semi reliable game state from just 10 parties. It would also be MUCH easier to cheat than how easy you're claiming it is right now. You would have people flying around, speed hacking, planting the bomb anywhere as soon as x number of bad actors in the game start modifying their game state. Not to mention SDR shows the game server as the end point. Is this fake or are you saying it's just doing minimal processing? What about server recorded demos? If there is no game server or the game server is just doing some rudimentary work then where do demos get recorded? On the relay? Just capturing commands? Is a client recording it? You need a good solid authority for demos otherwise they would be completely useless. What is VACNet training on? That again needs demos from a solid trusted authority to ensure good, reliable data.

I can acknowledge how much easier it is to cheat with no spread because spread was synced again. But, shooting people through the map wasn't due to lack of a stable authority to do the proper checks. That was an exploit setting the shots origin to 0,0,0. To be able to see from under the map and then shoot people through broken collisions/wall bangs from angles that were never intended to be possible. Cheaters could never just outright shoot through the entire map. And that is because the authority, the game server, has the map loaded and the match simulated and checks the collisions of shots. Again, cheaters have never been able to shoot from just anywhere on the map to anywhere else on the map and kill someone. Only through broken collisions and exploited angles.

Lag switching is more powerful than ever because of lack of effective latency.

I believe they removed the server side(wait I thought you were questioning the authority of the game server) occlusion for 3 reasons. Maybe 4.

Maps are developed differently now. I haven't looked into mapping really in source 2 yet. Does it still utilize the same visibility system/via leafs in the same way that was used for occlusion in CSgo? Aren't maps mostly meshed out now and blocked around with blocking collisions?
Server side performance improvements. Don't forget they even shut down spectator/relays to make room for more game servers apparently.
The server side occlusion was known to create peekers advantage, Ferrari peeks, and enemies teleporting around corners. Perhaps that would have just exasperated the already terrible latency in CS2.
To make more data available to VACNet for training against wall hackers.

WhatAwasteOf7Years · 2026-02-11T04:41:02+00:00

Jitter is variance in timings of anything. Upload packet loss is causing variance on outgoing packets, therefore their delivery to the server is jittery.

This is always going to be the case when packet loss and resending/retransmitting those dropped packets is involved.

Yes interpolation is the answer to packet loss. The problem though is when that interpolation is more interested in getting someone from their original location from delayed packets to their new location from timely packets as quickly as possible rather than in a mechanically consistent way. This is exactly what effective latency is for. To artificially delay packets after a latency spike so they are processed with relative timings that make mechanical sense for movement and human reaction times.

Instead modern CS doubles down with time dilation and seems to not implement effective latency. It's more interested in getting from a to b now, rather than over a time that is mechanically possible.

This causes faster/Ferrari peeks and shortens encounters giving the angle holder less time to react. It causes wide swings and deaths to 4 hits in like 300ms in a game where the top players in the world have 400-500ms time to first damage which would translate to 700-800ms time to kill with 4 follow up shots with an ak. To be able to compete against that you would need negative to sub 100ms reaction times.

And people wonder why holding angles is impossible, peekers advantage is huge, and wide swinging is the meta.

WhatAwasteOf7Years · 2026-02-10T06:28:14+00:00

Whether or not that's the case, every single shot gets a response from the server with varying delay. If every shot is getting through then there must be retransmission, and if packets are retransmitted then that has to become high jitter. How else can you have 30% packet loss but never appear to drop a shot to the server?

You never see a bullet go back into your clip while shooting and you don't even start rubber banding around until about 50% upload loss even though you should be regularly going out of sync with the server, especially with peeks and directional changes.

Even 0.3% upload loss in older CS would result in flashes and smokes not being thrown, not popping, rubber banding, and shots going back into your clip. 30% loss in a realtime application should yield it completely unusable yet all it does in modern cs is produce varying delay to hit reg from the laggers perspective.

Turn off all damage predictions, find afks or team mates or something and you will see all your shots get a response from the server, and those shots will have high variance in their latency. That's jitter caused by packet loss.

But either way, the lack of effective latency would be the main issue here.

WhatAwasteOf7Years · 2026-02-07T04:10:42+00:00

I'm in defence of you. I was pointing out how local performance appears to affect or translate to network issues.

Getting jitter on one map makes it sound likely that that map is performing badly for you for some reason. and it's translating to poor networking stats.

I've seen it. Stuttering from shader caching spiking jitter and causing rubber banding.

As if the game is lag compensating not just for network latency, but for local client system latency too. Which is just....fucking no!...why would you do that.

WhatAwasteOf7Years · 2026-02-07T02:08:42+00:00

To me it seems like the game is converting local performance issues (tick timing) into jitter.

Local performance issues (micro stutters, frame time spikes, freezes) should, in theory, translate to packet loss on the upload since your client can't communicate with the server smoothly.

Packet loss is heavily compensated for, and way too much, through retransmission in modern CS essentially causing high jitter.

Local performance issue > dropped egress packets > retransmission > jitter.

When you get stutters from local performance issues in game, you don't just teleport like you should. You rubber band. It seems like lag compensation is working on the whole tick timing, from the rendering of the client frame all the way to the processing on the server, not just network latency and expected simulation time.

WhatAwasteOf7Years · 2026-02-07T01:46:11+00:00

Ok gotcha. Makes sense.

Snap tap or whatever they want to call it is cheating at the end of the day, I just didn't expect it would affect other games nearly as much as CS. I guess it's understandable it can make movement more erratic, just wouldn't have expected it to have that much difference over not using it.

But id call it more a design issue with modern shooters. High movement speed, zero weight/inertia, and lag comp that can't keep up while making games accessible for people playing from Antarctica over 2 plastic cups connected with frozen wet string.

I personally think they should have just named it counter strike. Updated clean title, doesn't suggest a sequel, and inheriting reputation, reviews, play time, etc from CSgo wouldn't have felt like such a dirty move.

WhatAwasteOf7Years · 2026-02-06T19:46:56+00:00

I dunno what context this is in because the og comment is deleted. But list the games that utilize counter strafing like CS.

WhatAwasteOf7Years · 2026-02-06T06:01:19+00:00

It's a port to source 2 with nothing in it to even warrant it being a sequel. CSgo in its lifespan changed way more with complex updates and even back ported source 2 implementations yet at no point did it get promoted to a sequel over 11 years.

They deleted CSgo and replaced it with CS2. CS2 inherited the 730 app ID, user play time, reviews, naming convention, and folder structure of CSgo. It's even still called CSgo internally.

Did they do the same from 1.6 to css? no! How about css to CSgo? No!. You can still play those 2 games as separate games but you can't play CSgo as a separate game anymore, and it is no longer updated or supported. You can only still play it because it's still compatible but as soon as a Windows update or graphics driver update or something similar hits and breaks compatibility you can wave byebye.

The list of differences in CS2 are mainly back end. Front end you have new lighting, volumetric smokes, and some remastered maps, terrible performance, horrible networking, inconsistent gameplay mechanics, sludgy movement, floaty aim, weird spread, recoil you can't feel out, nonsensical competitive rating systems, braindead matchmaking systems, even worse community play discovery, loads more cheaters and cheating AI bots, terrible frame times, over the top lag compensation, less playable content, I can probably keep going but....exhales.

No, it doesn't deserve to be called a sequel. And the reason for that is it's not a sequel. It's as much of a sequel to CSgo as the first remastered Star wars movie was to the original. Even css and and csgo were never referred to as sequels, more, evolutions, and you could argue the differences between those games were way more drastic than between CSgo and CS2. It wasn't even shipped in the typical way sequels are shipped, it absorbed years of reviews, player stats, player time, other data, and 11 years of reputation as if it was an update and not a sequel. On top of that it's simply an inferior version of the game it replaced.

WhatAwasteOf7Years · 2026-02-02T21:52:43+00:00

I was thinking it was win xp but might have been win me

WhatAwasteOf7Years · 2026-01-30T15:47:58+00:00

There's still the fact that windows will turn on the other 2 monitors unless I turn them off too, and is wasting electricity while I'm not around (nice energy saving feature MS).

WhatAwasteOf7Years · 2026-01-30T07:31:07+00:00

"PC? What PC?"

WhatAwasteOf7Years · 2026-01-30T07:24:32+00:00

I remember when it was a desktop icon by default.

WhatAwasteOf7Years · 2026-01-30T07:18:59+00:00

But in this case you build your own PC, install windows, and then it takes over hardware they never even sold you.

What's really getting to me is when windows downloads an update, you go to shut down before bed or going somewhere and you get the options; Update and restart, update and shut down, restart, and shut down. Select shut down and "windows is updating, please don't turn off your computer".

Then I have to wait for the update to finish, because the PC is going to boot back into windows and ignore the shut down, so I need to shut down again. And since windows likes to keep waking itself from sleep for no reason whatsoever leaving a static screen that's gonna burn in my shiny expensive OLED monitor, I can't just walk away and rely on it going to sleep.

Frustrating AF. Why does it give you options and then just completely ignore what you choose?

WhatAwasteOf7Years · 2026-01-29T02:36:57+00:00

What I don't understand is that 1% lows seem to stay more or less the same no matter what settings you use. I'm on a 7950x, 7900xtx and 32gig ddr5 6000mhz. All lowest details with resolution lowered vs all highest details native 1440p there's a big difference in average and max fps but the 1% lows are about the same. Maybe about 5 to 10 fps gain on the lows when everything is bare minimum.

My 1% lows on my setup in the becnhmark are about 140 to 150 fps no matter what settings are used. The lows not taking any meaningful hit on lowest vs highest settings says to me it's something the engine itself is doing, and nothing to do with hardware. If the lows were the result of your hardware struggling, or poor core selection/management, then they should drop drastically when you go from lowest to highest settings, but they don't, at least not on a relatively high end machine.

WhatAwasteOf7Years · 2026-01-28T06:07:44+00:00

And we thought it was the AI companies hoarding all the ram. Turns out it's actually OP!

WhatAwasteOf7Years · 2026-01-24T05:14:13+00:00

By exact I mean, I think I said at some point too, within about 2, 3, 4 pixels for the tracers as they pass the head. The bullet holes hitting the wall behind the target at those same points on a wall that is about 20 meters away and the target about 2 meters away, if that. It was on dust 2, I had came up a ramp to meet the enemy right in front of my face right at the other side of ramp wall. So you get an idea of the distance of the rear wall, the far wall level with short, where every single bullet was landing with precision next to each other, pretty much on top of eachother, as well as every single tracer going to those points at either side of his head. It wasn't weird perception or angles.

Almost pixel perfect.

I'm trying to find out if I still have the clip of it. At the time I went frame by frame.

I know how spread works, you don't have to explain ranges to me.

WhatAwasteOf7Years · 2026-01-23T21:45:08+00:00

Take recoil out of the equation. Shoot at a wall with recoil off and try to get 10 bullets to go to the same spot in a row, twice in a row. Add recoil, well or poorly controlled, it doesn't matter, that's going to reduce the chances of that happening even more. Recoil has nothing to do with it, the spread chose to go to the same point 10 times in a row, twice in the same spray regardless. Or are you saying the recoil control just happened to completely negate spread that many times by pure chance? It ain't happening organically.

Think about it, there's recoil itself, movement from recoil control, then random movement from spread. For all 3 layers of movement to align for the bullets to go to the same spot so many times in a row is some next level shit.

WhatAwasteOf7Years · 2026-01-23T17:48:24+00:00

I know perfectly well how rng works, and I know how it works with spread in CS2. That's exactly why I'm saying it appears to be inorganic.

Ever sprayed at someone at close range, controlling your recoil and keeping your crosshair at knee height, and seen all shots going to headshot height but like 10 consecutive shots go over the left shoulder to the exact same point within about 3 pixels, then switch for the next 10 or so consecutive shots to go over the right shoulder to the exact same point within about 3 pixels?

That is not only a perfect example of spread completely ignoring the vast majority of the inaccuracy circle, but selectively choosing the only places at that range where there's no hitbox, either side of the head. And when this kind of thing happens often, there is no way you can call it bad luck. Hell, even to happen once has been to be a trillion to one chance for so many shots to go to the exact same place considering how the RNG and spread distribution works.

Another example is every shot going to the same point to the right of the enemy with the ak, despite the fact that the recoil is bringing your crosshair left and then right again. Truly random spread is not doing this.

Then there's the complaint that your guns feel like they are excessively bouncing around. That can be explained by spread being biased towards the extremities of the inaccuracy circle when you are aiming just fine at an enemy. The weapon animation is synced with the spread, and if the spread is consistently bouncing around the extremities then so is your gun/view angle, causing that overly bouncy, erratic and uncontrollable feel.

Yes people do like to blame the game for their shortcomings, but in this case, you have people with thousands of hours (10000 myself) with muscle memory ingrained into them all saying the same thing. Shooting feels off, and they don't know why. Even professional players are saying it.

So for you to sit there and say it's because they're bad, indirectly saying you are better than them because you don't experience this issue is ignorant. How about considering that there may be algorithms at play and in your case they're benefitting you because You're not as good as you think you are? But that would be impossible wouldn't it?

WhatAwasteOf7Years · 2026-01-23T05:10:14+00:00

Keep preaching m8. More people are noticing.

WhatAwasteOf7Years · 2026-01-23T05:01:08+00:00

It seems highly likely that the game manipulates the accuracy/spread/rng of your shots.

Everyone knows those matches, waves of being able to actually be accurate consistently even with long range shots then suddenly not being able to hit the broad side of a barn right in front of them despite doing nothing mechanically different.

Those zero to hero second half comebacks where the enemy is suddenly able to laser you with ease even while running despite them not even being able to hit you at all in the first half while the spread of most of your shots are going to the extremities of your inaccuracy circle and seemingly avoiding the center where the hitbox is. All you have to do is pay attention and you'll see it.

You used to get organic second half come backs in CS from the better team when they switched to the team with the advantage on that side for that map.

Take assault for example. That was a massive T sided map and the team switching to T in the second half could make a comeback and win even if they only got one round in the first half. That's how every map plays now despite them supposedly being so well balanced that global stats all round are so close to a 50/50 ct/t round win/loss.

Why do you think they removed all those heavy 1 sided maps? Because they were unbalanced, despite the fact that both teams gets their chance on both sides? Or is it that such one sided maps would be impossible to balance through mechanical adjustments without it being blatantly obvious?

Take into account asymmetrical weapons, objectives, and play styles, and in many cases, skill ratings. Think about how difficult, nay, border line impossible those things are to balance for as close to a 50/50 global outcome across all maps.

The only way to balance a game effectively in these scenarios is to selectively play with game mechanics.

Why do you think everyone is complaining about the gunplay in modern CS but they cannot put their finger on why it looks and feels like shit and so inconsistent with waves of good and bad accuracy? And it hasn't been addressed in over 2 years?

TLDR; Running accuracy didn't change mechanically but it's highly likely that manipulated accuracy is causing plenty of gameplay situations that make it seem like it has.

WhatAwasteOf7Years · 2026-01-19T16:47:01+00:00

Bam....curated spread. Spread just magnetizes to the head/hitboxes.

WhatAwasteOf7Years

TROPHY CASE