In the past Valve argued in a very reasonable way why they forced the tickrates
for other Source-Engine Games.
We also know from the CS:GO changelog that we already had Bugs related to
Tickrates higher than 64.
One of the causal conclusions from Vitalys explaination could be that it is
generally better to leave it on 64.
Valve is running their own Servers on Tickrate 64.
So the question is why are the logical arguments for other Source-Engine Games
not taken into consideration for CS:GO?
Unfortunately the last real information regarding netcode is more than a year
old (a tweet from Chet Faliszek via the csgo_dev Account) and that CS:GO uses
an updated Version from the Netcode done by Kirsch (who also did the original
Code for 1.6)
If this “updated” means that arguments for other source-engine games are not
effective for CS:GO and that documentation like the Latency Compensation
Methods from Bernier or other older informations from Kirsch are obsolete
related to this specific subject... i am fine with that...
I just want to know where is the technical difference between other
Source-Engine Games and CS:GO
So please stay cool....it’s generally just a legitimate question after reading
Vitalys Mail ....not an attempt to start an unnecessary discussion ;-)
Cheers
From: Saul Rennison
Sent: Thursday, May 02, 2013 9:56 PM
To: csgo_servers@list.valvesoftware.com
Subject: Re: [Csgo_servers] csgo update
Let's not start a "discussion" on tick rate, please!
On Thu, May 2, 2013 at 7:02 PM, Timur 'grammaton' Celikkesen
<gramma...@gmail.com> wrote:
This is really a very good explaination and as i understand it – you can take
this also as an argument to finally force CS:GO to a specific tickrate.
I was always a bit confused why the argumentation for the tickrate 66 force
at CS:S (which is logical) was not used for CS:GO (with 64 Ticks).
Related to this i want to call up one specific point in a previous
changelog...
-Limiting physics timestep to 64 to eliminate high tickrate physics bugs,
such as bouncing guns
As long as you give the choice to select the tickrate, the community will
always choose the higher value – regardless if it makes sense or not. The
competative part of the community will always discuss about it.
...but as we all should remember.......it took just some few days after the
tickrate force or fps cap... to end years of unnecessary discussions.
just my 2 cents
Cheers
From: Vitaliy Genkin
Sent: Thursday, May 02, 2013 6:56 PM
To: csgo_servers@list.valvesoftware.com
Subject: Re: [Csgo_servers] csgo update
The value for sv_maxusrcmdprocessticks specifies maximum user commands that
server will handle from a client in a single server frame tick.
E.g. if you run a 128-tick server with max 3 usr cmds per tick, but your
client runs at sub-64 fps then the client might experience incorrect prediction
on movement and what you refer to as “lag”. The solutions here would be to:
1) disable the user commands limit completely on the server with
sv_maxusrcmdprocessticks 0
This would use old behavior and allows clients with any low framerate or high
packet loss to fully execute all queued up movement packets on the server and
allows clients to maliciously inject additional movement packets for execution
on the server thus possibly attaining a higher than maximum movement speed or
movement speed bursts observed by other players.
2) increase the user commands limit to allow slack for clients running with
low fps with e.g. sv_maxusrcmdprocessticks 16
The higher the value the higher “movement burst speed” can be observed by
other clients and can be attained on a single server tick by a cheater or user
with severe packet loss or low fps.
When running 64-tick server with default setting of max 3 user commands per
server tick clients might observe incorrect prediction on movement when running
with sustained fps below 25 fps or when running at 64 fps but dropping 30% of
packets or a combination of these unfavorable conditions. Even when a local
client encounters incorrect prediction on movement all other players in the
server still see their movement as smooth and from other players’ perspective
the movement speed is always within max movement speed.
To diagnose the case of clients being affected by the setting of max user
commands you can use “sv_maxusrcmdprocessticks_warning” convar, setting it to 0
will spew all server ticks and clients for whom user commands are being
dropped, setting it to 1 will spew no more than 1 message per second, setting
it to default -1 disables the spew. Once you narrow it down to the client you
can disable competitive min spec on the server and capture the client statistic
with “net_graph 5” on the client. Let us know if you encounter clients running
at sustained fps >= server tickrate without any packet loss that experience
dropped user commands and we’ll be able to investigate further from here.
Thank you,
-Vitaliy
From: csgo_servers-boun...@list.valvesoftware.com
[mailto:csgo_servers-boun...@list.valvesoftware.com] On Behalf Of Loïc Péron
Sent: Thursday, May 02, 2013 9:23 AM
To: csgo_servers@list.valvesoftware.com
Subject: Re: [Csgo_servers] csgo update
sv_maxusrcmdprocessticks "3" makes players lag when moving.
sv_maxusrcmdprocessticks "0" fix it.
------------------------------------------------------------------------------
_______________________________________________
Csgo_servers mailing list
Csgo_servers@list.valvesoftware.com
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
--------------------------------------------------------------------------------
_______________________________________________
Csgo_servers mailing list
Csgo_servers@list.valvesoftware.com
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers_______________________________________________
Csgo_servers mailing list
Csgo_servers@list.valvesoftware.com
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
