CS2 Margin Graph

[dervu]

I don't understand that wording, so below desired recv. margin, If 0.1% arrived below desired recv. margin then these packets did arrive late in that context.

In my case 70% - 90% arrive below desired recv margin which means they are late. Simulated ticks (server state) would catch them barley in time as he states (thats why they don't count as missed or out of order).
But that should still be an issue as in the simulated ticks get slammed to my client more often, which means I can be behind 2-5 ticks on the Server = 30-75ms.
I might be up to date but my updatetick gets skipped (so it doesn't count as missed or out of order) and then I have a 30-70ms delay in many occasions which further increases peekers advantage (holders disadvantage) and erratic model movement. So basically Input is still missing but predicted on the server. That's in my opinion the reason why everything feels so desynced.

This value is badly explained there has been a threat on reddit about netcode which I highly recommend
https://www.reddit.com/r/GlobalOffensiv ... 2_vs_csgo/

I will still test the recv. margin telemetrics I am just not done switching CPU and formatting @vnb

i agree with you, one thing for sure is that the wording is very bad, i don't really understand it either. One could agree that "below desired recv margin" could mean that it is below what the server expect to get from your client so faster = theoretically better.

imo the correct wording should be "above desired recv margin" not "below" as valve use...

Even tho i hate AI and avoid it as much as possible the explanation of ChatGPT makes more sense than the explanation we got above?

recv chatgpt.PNG


Also the fact that FletcherDunn says it "should not impact gameplay negatively" is just wrong? imho... then why integrate it in the latency breakdown?

I partly agree with him that when sometimes i have 3% or 5% it has almost no impact on my gameplay but when the number is above 20% it is literally unplayable (especially on upstream)

This one is more clear:
"“Below desired recv margin” = packets arrived late-ish, but still before the hard rendering deadline.

It does not mean “packets came too early.” It means they cut it close. Gameplay wasn’t forced to extrapolate, but your safety buffer was smaller than Valve would like."
So if any network or client hiccup happens, higher percentage player will be more prone to delays than 0% one.
If it's missed deadline you’ll see late/dropped/corrected.

If receive margin meant = late, then what would be the purpose of having another late parameter?

[vnb]

I don't understand that wording, so below desired recv. margin, If 0.1% arrived below desired recv. margin then these packets did arrive late in that context.

In my case 70% - 90% arrive below desired recv margin which means they are late. Simulated ticks (server state) would catch them barley in time as he states (thats why they don't count as missed or out of order).
But that should still be an issue as in the simulated ticks get slammed to my client more often, which means I can be behind 2-5 ticks on the Server = 30-75ms.
I might be up to date but my updatetick gets skipped (so it doesn't count as missed or out of order) and then I have a 30-70ms delay in many occasions which further increases peekers advantage (holders disadvantage) and erratic model movement. So basically Input is still missing but predicted on the server. That's in my opinion the reason why everything feels so desynced.

This value is badly explained there has been a threat on reddit about netcode which I highly recommend
https://www.reddit.com/r/GlobalOffensiv ... 2_vs_csgo/

I will still test the recv. margin telemetrics I am just not done switching CPU and formatting @vnb

i agree with you, one thing for sure is that the wording is very bad, i don't really understand it either. One could agree that "below desired recv margin" could mean that it is below what the server expect to get from your client so faster = theoretically better.

imo the correct wording should be "above desired recv margin" not "below" as valve use...

Even tho i hate AI and avoid it as much as possible the explanation of ChatGPT makes more sense than the explanation we got above?

recv chatgpt.PNG


Also the fact that FletcherDunn says it "should not impact gameplay negatively" is just wrong? imho... then why integrate it in the latency breakdown?

I partly agree with him that when sometimes i have 3% or 5% it has almost no impact on my gameplay but when the number is above 20% it is literally unplayable (especially on upstream)

This one is more clear:
"“Below desired recv margin” = packets arrived late-ish, but still before the hard rendering deadline.

It does not mean “packets came too early.” It means they cut it close. Gameplay wasn’t forced to extrapolate, but your safety buffer was smaller than Valve would like."
So if any network or client hiccup happens, higher percentage player will be more prone to delays than 0% one.
If it's missed deadline you’ll see late/dropped/corrected.

If receive margin meant = late, then what would be the purpose of having another late parameter?

i know, but still the wording is not ideal. the whole comment was more about why valve dev is saying that having "below recv margin " have no negative impact on gameplay. I partly disagree with that.

In my experience; That might be true if the numbers are low; i'd say less than 5%. But in the case those numbers are really high like above 30%, there is no way that it does not negatively impact the gameplay.

In my case if those numbers remains low my game is pretty ok, when i die; i feel like the duel was fair and i lost it.

However

When those numbers are high either my bullets are not hitting (high upstream recv margin) or opponents have erratic movements like moving very fast, skating, no leg movements (high downstream recv margin).

[SammYrai]

So here are my margins:

recvMarg.jpg (124.09 KiB) Viewed 212 times

margin.jpg (12.5 KiB) Viewed 212 times

fresh installed win25h2 Pro no tweaks
9800x3d
MSI X870E Tomahawk
Lexar 6000mhz cl26 32GB DDR
MSI 4070ti
Intel T210 NIC
1300W Titanium Pro from BenQ
Aorus 360hz OLED in 24,5'' mode
Wooting 80HE
EGG OP8Kv2 2000hz 1600dpi
WD8100 SSD on PCIEX5
Cyberpower OLS1500EA-DE Double Conversion UPS (pc,monitor,router,vdsl,modem attached)
VDSL Line with 0 errors (I manually adjust the SNR and monitor the modem so I know there is no correction)
CMOS reset done and only EXPO default PBO was used and onboard NIC SOUND WIFI and BT were disabled.
since it's stock FSO,DVR,Game Mode,HAGS and all the defaults were enabled.

I am curious can you play a round on the xplay.gg retake servers, these seem to be the only servers where I can get a constantly low margin, but the servers are hosted where faceit also hosts their ESEA servers in Germany so since it's the same AS (BGP Network) I have the same exact peering and routing there but the xplay servers feel perfect but faceits don't.

I will now start to apply ReviOS and all my default tweaks install my vpn again and test some more tomorrow.

[vnb]

So here are my margins:

recvMarg.jpg
margin.jpg

fresh installed win25h2 Pro no tweaks
9800x3d
MSI X870E Tomahawk
Lexar 6000mhz cl26 32GB DDR
MSI 4070ti
Intel T210 NIC
1300W Titanium Pro from BenQ
Aorus 360hz OLED in 24,5'' mode
Wooting 80HE
EGG OP8Kv2 2000hz 1600dpi
WD8100 SSD on PCIEX5
Cyberpower OLS1500EA-DE Double Conversion UPS (pc,monitor,router,vdsl,modem attached)
VDSL Line with 0 errors (I manually adjust the SNR and monitor the modem so I know there is no correction)
CMOS reset done and only EXPO default PBO was used and onboard NIC SOUND WIFI and BT were disabled.
since it's stock FSO,DVR,Game Mode,HAGS and all the defaults were enabled.

I am curious can you play a round on the xplay.gg retake servers, these seem to be the only servers where I can get a constantly low margin, but the servers are hosted where faceit also hosts their ESEA servers in Germany so since it's the same AS (BGP Network) I have the same exact peering and routing there but the xplay servers feel perfect but faceits don't.

I will now start to apply ReviOS and all my default tweaks install my vpn again and test some more tomorrow.

Thank you so much for sharing this!, actually you are one of the few who shared complete data, and i really appreciate you for that.
I should start to avoid responding to other users who enjoy steering the topic into another direction and come only to throw half an info then dip out...

Edit : @SammYrai can you share what is the third number after the letter bottom left corner? Ideal value should be 05 or below 07, thanks.

Anyways, i've had time to test further and i can confidently say that the most problematic metric is the upstream recv margin when this value is high the game definitely does not feel good, and this is a consistent feeling.

For the downstream margin i'm pretty confident in saying it is less impactful on the gameplay. Maybe this is what FletcherDunn meant after all, that the downstream recv should not impact negatively the gameplay.

In my case :

Game with HIGH upstream recv margin = unplayable (bullets not hitting, very slow hit reg, 300kg slow motion feeling)
Game with LOW upstream recv margin = perfect
Game with HIGH downstream recv margin = opponent have more erratic movement, but still playable
Game with LOW dowsntream recv margin = opponent movements are normal but i die faster when i get shot

[SammYrai]

buildNR.jpg (5.78 KiB) Viewed 175 times

Depending what happens on the server (player joining many grenades and stuff) I saw this number rise above 20. But I can test either late tonight or tomorrow again. But I think you got it wrong, the second number after the build date should be the ping / rtt.

top->bottom explained is left->right in r_show_build_info

Build date - V = matchmaking S = dedicated (community) L = local loopback

Send buffer to catch up under jitter/loss frequently delayed inputs above 15
Average send + receive latency = Ping not reflecting spikes nor buffering
Receive buffer to catch up under jitter/loss frequently out-of-sync above 05
Downstream packet loss, clamped to 9.9% frequently missing sv refresh above 10
Upstream packet loss, clamped to 9.9% frequently skipping inputs above 10

Command queue starve (too many behind) : bloat (too many ahead) often CS2'd above 0:0

Render interpolation = tickrate = 64/s (15) higher if server has performance issues
Min frametime = Max fps (1000 / 04 = 250) no decimals so actually less
Max frametime = Min fps (1000 / 12 = 83) no decimals so actually less

taken from https://www.reddit.com/r/GlobalOffensiv ... t/n23umpl/
aveyo is very knowledgeable in cs2 performance / netcode

[vnb]

buildNR.jpg

Depending what happens on the server (player joining many grenades and stuff) I saw this number rise above 20. But I can test either late tonight or tomorrow again. But I think you got it wrong, the second number after the build date should be the ping / rtt.

top->bottom explained is left->right in r_show_build_info

Build date - V = matchmaking S = dedicated (community) L = local loopback

Send buffer to catch up under jitter/loss frequently delayed inputs above 15
Average send + receive latency = Ping not reflecting spikes nor buffering
Receive buffer to catch up under jitter/loss frequently out-of-sync above 05
Downstream packet loss, clamped to 9.9% frequently missing sv refresh above 10
Upstream packet loss, clamped to 9.9% frequently skipping inputs above 10

Command queue starve (too many behind) : bloat (too many ahead) often CS2'd above 0:0

Render interpolation = tickrate = 64/s (15) higher if server has performance issues
Min frametime = Max fps (1000 / 04 = 250) no decimals so actually less
Max frametime = Min fps (1000 / 12 = 83) no decimals so actually less

taken from https://www.reddit.com/r/GlobalOffensiv ... t/n23umpl/
aveyo is very knowledgeable in cs2 performance / netcode

thanks. i never talked about second number but the third

check this : https://www.reddit.com/r/GlobalOffensiv ... 2_vs_csgo/ chapter 3.5 if you wanna understand the meaning behind those numbers

as said before

first number should be below 15
second number is your ping / rtt
third number should ideally be 05 (up to 07 is okayish)

[dervu]

Cybershoke. HSDM server with always green receive margin graph, perfect game.
Cybershoke KZ server, yellow parts intertwined with green all the time, and values in graph moving up and down, feels unplayable, every jump you feel like being moved into another position by server.

[Misha1337]

buildNR.jpg

Depending what happens on the server (player joining many grenades and stuff) I saw this number rise above 20. But I can test either late tonight or tomorrow again. But I think you got it wrong, the second number after the build date should be the ping / rtt.

top->bottom explained is left->right in r_show_build_info

Build date - V = matchmaking S = dedicated (community) L = local loopback

Send buffer to catch up under jitter/loss frequently delayed inputs above 15
Average send + receive latency = Ping not reflecting spikes nor buffering
Receive buffer to catch up under jitter/loss frequently out-of-sync above 05
Downstream packet loss, clamped to 9.9% frequently missing sv refresh above 10
Upstream packet loss, clamped to 9.9% frequently skipping inputs above 10

Command queue starve (too many behind) : bloat (too many ahead) often CS2'd above 0:0

Render interpolation = tickrate = 64/s (15) higher if server has performance issues
Min frametime = Max fps (1000 / 04 = 250) no decimals so actually less
Max frametime = Min fps (1000 / 12 = 83) no decimals so actually less

taken from https://www.reddit.com/r/GlobalOffensiv ... t/n23umpl/
aveyo is very knowledgeable in cs2 performance / netcode

thanks. i never talked about second number but the third

check this : https://www.reddit.com/r/GlobalOffensiv ... 2_vs_csgo/ chapter 3.5 if you wanna understand the meaning behind those numbers

as said before

first number should be below 15
second number is your ping / rtt
third number should ideally be 05 (up to 07 is okayish)

Can you tell me what's wrong here ?

My cs2 experience is very inconsistent with alot of out of order packets