Your example is wrong. Server tries to run game tick as many times as time_to_previous_tick / TICK_LENGTH. So if it gets behind at 1 tick (which is bad) it'll try to compensate it.
I'm not sure how srcds handles the case where executing tick always takes more than TICK_LENGTH. It might skip ticks if there are too many of them to execute within a second. What I'm interested as a player is how many network updates can the server reliably transmit when server is running game/mod with 32 or 64 players on it. Frame count per second is totally irrelevant because ticks use most CPU not frames (frames during which there were no ticks executed). BTW I hate email quoting style used here. On Mon, Nov 15, 2010 at 7:25 PM, John <[email protected]> wrote: > I agree that a better explanation from Valve would be good to squash some of > the speculation on what FPS really means (the docs I've seen talk about > tickrate, but not FPS). Maybe there's an official one out there, and we just > need to find it. > > Gary, I'm not sure that you're right about seemingly small amounts of jitter > never representing a problem. Imagine a scenario in which a server runs at > 10fps and a tickrate of 5, with this timeline: > > Time marker - Network frame event and length of event - Tickrate event and > length of event > --- > 0ms - Network frame (10ms) - Tick (50ms) > 100ms - Network frame (10ms) > 200ms - Network frame (10ms) - Tick (50ms) > 300ms - Network frame (10ms) > 400ms - Network frame (10ms) - Tick (50ms) > 500ms - Network frame (10ms) > 600ms - Network frame (10ms) - Tick (50ms) > 700ms - Network frame (10ms) > 800ms - Network frame (10ms) - Tick (50ms) > 900ms - Network frame (10ms) > > In that run, with all frames and ticks fitting nicely together, the server > would have a smooth realized 10fps and 5 tick. Great! But, what if only one > of the ticks takes much longer than expected? > > 0ms - Network frame (10ms) - Tick (50ms) > 100ms - Network frame (10ms) > 200ms - Network frame (10ms) - Tick (390ms) > 300ms - It's still working on the last tick > 400ms - It's still working on the last tick > 500ms - It's still working on the last tick > 600ms - Network frame (10ms) - Tick (50ms) > 700ms - Network frame (10ms) > 800ms - Network frame (10ms) - Tick (50ms) > 900ms - Network frame (10ms) > > The realized FPS here in this case would be 7, and the realized tickrate > would be 4. This means that the FPS didn't dip all that much and still > exceeds the tickrate, and yet the client would have seen a (very noticeable, > at this resolution) glitch in gameplay. > > Scale this up to higher FPS and tickrate values, and it's quite possible > that a dip from 150 to 100, or 90 to 66, could represent a problem. Does it > always, and is it always noticeable? No, I wouldn't say that. But, realized > FPS is still the best measure of purely server-side performance that we > currently have at our disposal. > > I would like to see a realized tickrate number in addition to, or instead > of, FPS. Locking the FPS rate to the tickrate (as L4D/L4D2 servers do, by > default) also effectively gives us this, but presumably there is a benefit > to having a decoupled higher FPS, such as by splitting up some of the > network processing work into smaller chunks so that ticks take less time. > > (In the real world, what could cause a tick to take so long? Commonly, a > misbehaved plugin or long disk write. The latter can be caused by very heavy > background disk access when the server is flushing out a log.) > > -John > > On 11/15/2010 3:37 AM, Björn Rohlén wrote: >> >> Instead of hiding the server_fps, it would be better to explain it in >> detail. >> >> -TheG >> >> On Mon, Nov 15, 2010 at 9:51 AM, Gary >> Stanley<[email protected]>wrote: >> >>> I guess the new sales pitches are that when a server has FPS jitter (from >>> say, 100 to 150 or 66 to 90) that is bad and causes all kinds of issues. >>> >>> Can valve PLEASE PLEASE PLEASE remove FPS from rcon stats or do something >>> to prevent it's behavior from being altered? Or lock it at 1:1 so it >>> scales >>> with the tickrate? >>> >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> http://list.valvesoftware.com/mailman/listinfo/hlds_linux >>> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
