Thanks for the knowledge, but it didn't quite answer my question.
Maybe my question was wrong.
When I run a cs 1.6 or tfc server or some other mod on the HL-1 engine, and
run it at sys_ticrate 100, the fps will never exceed 100 at default it wil
even sit on 64fps on windows machines.
If I were to set sys_ticrate to 200, fps will site around 150-170.
So no matter what I do, tic rate is always higher then the server fsp at
least in games running on the HL-1 mod, if I read your post this is a bad
thing.
Now my question is, is this normal in HL-1 or am I doing something wrong
here?
The second question that pops into my head is, if I'm not doing something
wrong, is u only referring to games running on the source engine, and in
what way does source differ from HL-1 on this subject?
Ok that was really 2 more questions :)
Could someone please explain this?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James Tucker
Sent: zaterdag 10 september 2005 4:46
To: [email protected]
Subject: Re: [hlds] Summary - Tickrate / FPS / Timer Resolution
(WMP|PingBooster)
A game tick is a game world state. In a gameworld state, a number of
things happen, people change velocities, collisions occur and bullets
are registered.
A client runs at the same tickrate as the server for it's internal tick
clock. When the client performs an action, this action is stamped with
the time (in ticks) that it happened. In order to get around latency and
interpolation delay issues, the server recieves this information,
rewinds the world to that tick, and processes the data.
The above I would imagine you already know, so here comes for the
slightly more interesting part...
A server has sv_maxunlag set to 0.5, that's a value in seconds. A client
has cl_cmdrate 6, a ping of 400ms, and cl_interp 0.1. I know these
settings and scenario are extreme, but this illustrates the point most
clearly. The server will process all incoming data relating to ticks up
to 500ms in the past. The client takes 100ms to present data to the
user, data takes 400ms to travel to the server (not including data
transfer time), and the client sends updates once every 166ms. Clearly
the client may overstep the 500ms barrier, and when this occurs you get
"lag" and bullets which will never be processed. Clearly this is normal lag.
Moving on, now on srcds, and hlds as I understand it, the server can
only process one tick per frame (correct me if I am wrong). Lets say
you're running at tickrate 100, and the server is doing 50fps. Two
clients are battling firing constantly. They have their rates set nice
and high so are sending 100 command packets per second, containing 100
individual updates per second. Assuming they are sending data at the
same time (their interp values are comparable) the server (and I am not
certain of this functioning of srcds) may be able to process the data in
pairs of command packets processing each tick 100ms behind (interp).
This would be fine, it starts processing from the back of the queue
forwards (to attempt to preserve all data, not letting the old stuff
fall if possible). After the first 50 updates, the whole sv_maxunlag
queue is full, there is a whole 500ms of data waiting to be processed.
The next update comes in, some old data must be expired to fill the
queue, in this event some data remains unprocessed.
Unfortunately the documentation available does not detail exactly how
source can deal with attempting to process multiple things in a frame,
my guess is that a frame processes a single tick in the past, or a new
tick, using all of the available data at the time. Data is probably
stored in a timeline. If someone from valve could correct me or verify
this I would be most obliged.
If this is the case, then in best case you will have everyone with even
pings, and even rates and interp settings, same data transfer times with
no delays, and you can get away with your fps equalling the tickrate and
all the data should get processed. In the scenario where many people
have different rates with different pings, so ticks have to be
reprocessed and reprocessed over and over, you will not be able to keep
up with the input demand, during these events you get what is called
"bad bullet registration" as command packets are dropped due to expiring
past the processing deadline set by sv_maxunlag.
blkraven wrote:
James, u say the tic rate must not exceed server fps, I don't have any
experience in running source, but on cs 1.6 and other hl1 mods, the tic
rate
always exceeds the server fps at least on the ones I've seen, is this
different in Source?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James Tucker
Sent: vrijdag 9 september 2005 20:41
To: [email protected]
Subject: [hlds] Summary - Tickrate / FPS / Timer Resolution
(WMP|PingBooster)
Ok. Here's the thing then, you wanted a summary, I will attempt to do
this as comprehensively as I can with the time I have available right now.
There is a general rule for proper bullet registration and game server
performance that essentially is: Your tickrate must not exceed the
servers FPS (frames per second). You can find out your servers FPS by
using the "stats" command, or from a client "rcon stats". N.B. From a
client just "stats" will display local FPS.
Now, the next thing to observe is that by default, on the windows
platform, srcds rarely (in fact theoretically never for a default
install) performs over around 60-68fps. This is due to something called
the kernel timer resolution, or in particular, the resolution is too
low. Timer resolution is measured either in frequency (Hz) or in time
(typically ms, or ns). srcds normally performs at 1/2 the timer
resolution, which on windows is around 7.8ms, or 128Hz by default.
Combine the two rules above, and you can see that there are potential
issues for high(er) tickrate servers. Furthermore, this FPS restriction
is generally harmful to server side processing latency, so in general
over a couple of hundred FPS is preferable for optimal feel at the
client (emprically tested by load). I try to deploy 300fps or higher
depending on client requests and purchase.
You can rectify the timer problem by loading an application which
increases the timer resolution (or decreases the timer latency, or timer
length). This can be achieved (most popularly) by loading either Windows
Media Player or a Macromedia Flash file. There are other solutions, many
of which are currently called "PingBooster" or similar in the srcds/hlds
community. It is possible to alter the default timer resolution
(pre-boot), detailed resources and more technical information is
referenced below.
---
Proper resource information regarding windows high res timers:
http://www.sysinternals.com/Information/HighResolutionTimers.html
How to find out your current timer resolution on windows:
http://www.sysinternals.com/Utilities/ClockRes.html
---
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
