-- [ Picked text/plain from multipart/alternative ] fps on a server is the amount of times per second SRCDS checks for I/O fps is set by the fps_max command fps is decoupled from tickrate in SRCDS, except in the fact that fps should not fall below tickrate for obvious reasons. i.e. If there is no I/O for a tick, then there is no new data for that tick to run a simulation on. James it seems that fps_max now works for all values now, and is not locked at multiples of the kernel timer resolution that it used to be. Did not see that one in the release notes. On 9/10/05, James Tucker <[EMAIL PROTECTED]> wrote: > > 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
