CS2 Margin Graph

[urikawa]

[Client] Source2 engine networking summary. 1124 seconds.
[Client] UPSTREAM (client->server):
[Client] Bandwidth . . . . . . . : Total:42779.1kb Reliable:117.9kb Voice:0.0kb
[Client] Kb/sec. . . . . . . . : Avg:38.1 P95:47.6 P99:53.1
[Client] Tick messages . . . . . : 71591 total
[Client] Arrived on time . . . : 71174 (99.4%) 994 (1.4%) below desired recv margin
[Client] Corrected/smoothed. . : 0 (0.0%) 0 (0.0%) dropped 0 (0.0%) late
[Client] Missed. . . . . . . . : 417 (0.6%) 0 (0.0%) dropped 0 (0.0%) late 417 (0.6%) non-network
[Client] Tick miss rate. . . . . : 278 measurement intervals 278 (100.0%) net-perfect 244 (87.8%) perfect
[Client] Distribution. . . . . : P75:0.0% P95:0.0% P99:0.0%
[Client] Receive margin (ms) . . : P1:5 P5:6 P25:7 P50:8 P75:10 P95:21
[Client] Network frames. . . . . : 71691 total
[Client] Size. . . . . . . . . : Avg:596 0 (0.00%) > MTU
[Client] Misdelivered lifetime : 0 (0.00%) 0 (0.00%) dropped 0 (0.00%) out of order
[Client] Jitter (ms) . . . . . : P50:0 P99:1
[Client] Packets
[Client] Misdelivery rate. . . : P50:0.0% P95:0.0%
[Client] Jitter, 1-sec max (ms): P50:1 P95:2
[Client] Network ping (ms) . . . : P5:17 P50:17 P95:18
[Client] DOWNSTREAM (server->client):
[Client] Bandwidth . . . . . . . : Total:121400.9kb Reliable:11035.3kb
[Client] Kb/sec. . . . . . . . : Avg:108.0 P95:180.2 P99:198.8
[Client] Netchan messages. . . . : Total msgs:282685 Avg size:429.5bytes
[Client] Messages/sec. . . . . : Avg:251.5 P95:420 P99:420
[Client] Tick messages . . . . . : 71702 total
[Client] Arrived on time . . . : 71578 (99.8%) 22674 (31.6%) below desired recv margin
[Client] Corrected/smoothed. . : 0 (0.0%) 0 (0.0%) dropped 0 (0.0%) late
[Client] Missed. . . . . . . . : 124 (0.2%) 0 (0.0%) dropped 0 (0.0%) late 124 (0.2%) non-network
[Client] Tick miss rate. . . . . : 278 measurement intervals 278 (100.0%) net-perfect 244 (87.8%) perfect
[Client] Distribution. . . . . : P75:0.0% P95:0.0% P99:0.0%
[Client] Receive margin (ms) . . : P1:-1 P5:2 P25:5 P50:6 P75:8 P95:14
[Client] Network frames. . . . . : 71748 total
[Client] Size. . . . . . . . . : Avg:1692 120 (0.17%) > MTU
[Client] Misdelivered lifetime : 0 (0.00%) 0 (0.00%) dropped 0 (0.00%) out of order
[Client] Jitter (ms) . . . . . : P50:0 P99:0
[Client] Packets
[Client] Misdelivery rate. . . : P50:0.2% P95:3.5%
[Client] Jitter, 1-sec max (ms): P50:0 P95:0

[SammYrai]

One of former CS pros stats on faceit after match while streaming:

Can you please share how your graph looks?

which pro player are you taking this from in your screenshot? please be specific this is public information it's not like we are talking about super secret stuff.

Here is a capture from former pro player scream (found it in a clip someone made on twitch a few weeks ago)

scream.PNG

Omg if someone told me how to replicate this I would be the happiest person alive all below 1% wtf

[vnb]

can you share what your margin graph looks like? i'm curious to see especially with your very high downstream recv margin.

[SammYrai]

Sure I'll test this weekend, I am just in the process of upgrading my CPU, can you share which pro you got this screenshot from? If not do you have any Info about their hardware location etc ?

[dervu]

One of former CS pros stats on faceit after match while streaming:

Can you please share how your graph looks?

which pro player are you taking this from in your screenshot? please be specific this is public information it's not like we are talking about super secret stuff.

Here is a capture from former pro player scream (found it in a clip someone made on twitch a few weeks ago)

scream.PNG

It was from pashaBiceps.

Mine is usually around 5 to 20% for downstream, upstream usually much better in single digits mostly. Graph depending on server is fully green and consistent. Only on some servers with intertwined yellow parts all the time and you can tell something is off right there.

I remember Scream complaining about some issues some time ago. Would be cool to have stats from that time. Maybe next time you see some good player say such things, tell them to check those stats and compare to the time when they don't complain and they play good.

It is interesting stat that it is hard to find any explanation what is supposed to be good value.

[vnb]

One of former CS pros stats on faceit after match while streaming:

Can you please share how your graph looks?

which pro player are you taking this from in your screenshot? please be specific this is public information it's not like we are talking about super secret stuff.

Here is a capture from former pro player scream (found it in a clip someone made on twitch a few weeks ago)

scream.PNG

It was from pashaBiceps.

Mine is usually around 5 to 20% for downstream, upstream usually much better in single digits mostly. Graph depending on server is fully green and consistent. Only on some servers with intertwined yellow parts all the time and you can tell something is off right there.

I remember Scream complaining about some issues some time ago. Would be cool to have stats from that time. Maybe next time you see some good player say such things, tell them to check those stats and compare to the time when they don't complain and they play good.

It is interesting stat that it is hard to find any explanation what is supposed to be good value.

From what i gathered the number "x% below recv margin" that is problematic is the uptream value. Basically if your value in the upstream is high, your inputs will be delayed because of ? jitter? packet loss? Instability? and they will reach the server a bit too late; which will make you feel like your inputs are delayed.

Now for the "downstream below recv value" imo it's less problematic, the main issue you will have are that enemy will have "erratic" movement on your screen because the server is constantly trying to re-sync the tick messages it sents to you.

in my case playing on different servers (face it, valve, community servs, etc) I noticed that the higher the downstream recv margin value is the harder i am to get hit by enemy, (they have a harder time hitting me) but at the same time i see them moving very erratically (so it's a double edged-sword)

however when the upstream recv margin is high, your bullets are just not hitting, your keyboard strafe are slower than usual, and you have this "heavy feeling" where your character feel like it's 300kg and moving in slow-motion.

I would definitely take a few "downstream below recv margin" than the "upstream below recv margin" because the downstream one is manageable while the upstream one is absolutely not

[vnb]

Someone on reddit asked the same question to FletcherDunn (engineer at Valve, working on networking) about the recv below margin here is what he replied

below recv margin fletcherdunn.png (85.93 KiB) Viewed 158 times

"He says that "below recv margin" means that the tick messages arrived before the deadline and that there is no negative impact on gameplay. "

He is surely more competent than me in that matter, but i hardly disagree... here is why :

1) If those numbers does not impact gameplay negatively as he wrote, then why integrate it in the latency breakdown?
2) why when those numbers are high IT IN FACT DOES AFFECT gameplay

[SammYrai]

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

[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 (183.03 KiB) Viewed 45 times

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)