--
[ Picked text/plain from multipart/alternative ]
BTW, when any of you are fooling around with these settings, you need to do
a map change before you will see your new settings take effect. It can be
changed to the same map, the server simply must go through that map change
sequence or you will not see any difference on your server.
Cheers
On 8/10/05, James Tucker <[EMAIL PROTECTED]> wrote:
>
> On 8/9/05, Clayton Macleod <[EMAIL PROTECTED]> wrote:
> > pre-script (probably not an actual term, heh. Probably should be
> > 'foreword.'): I've rewritten this about 5 times now, trying to come at
> > it from different angles each time, heh. I still am not sure if it
> > comes across very well...
>
> :)
>
> > well, I don't know if I'm grossly misunderstanding something or if you
> > are. The server takes client input and calculates the next tick. Then
> > it sends that tick's data to clients.
>
> Actually, there are more processes going on - remember processing
> client data has nothing to do with the current tick (at least, not at
> first) as it rewinds by cl_interp+latency and processes that data
> (should also have a tick stamp). The next tick to be generated, as you
> say does always occur (by default) 33 times per second, no more and no
> less. Again, I agree that in rough theory it makes no difference to
> the gameworld processing efficiency having FPS from 33 to 10000,
> however this does not mean it has no effect on the system. As the
> system is a single unit, one would expect that effects cause affects,
> and indeed they do, as I described before. You see whilst ticks happen
> at specific intervals, they can only occur in a free frame (time slot
> for processing effectively, although multiple actions can complete in
> one time slot). As client data can only be updated every tick, no new
> data is ever released before the next tick, thus you are as you say
> limited to gameworld state transitions - however the code is operating
> on two timelines - real world and game world. It takes TIME to process
> a new tick, it takes TIME to process client data, it takes TIME to
> process a frame (yes, this is different to a tick, and is more
> important to netcode (changing tickrate may change the maximum
> packetrate, but don't forget THAT IS REALLY ALL!)). The time taken to
> process an incoming frame must not exceed the time to next tick for
> optimality (actually, you have more time, but specifics were explained
> before) - this is not the same as "average fps above tickrate".
>
> > The fact that there are 33
> > ticks per second doesn't mean the server is taking 1/33 of a second to
> > calculate a tick.
>
> No, it means the server WILL ACITVELY NOT make a new tick for 1/33 of
> a second, this is important as it is SET. Packet times are not set
> (although they aren't released (server outbound channel only!) until
> the next tick!), frame times are not set, and data transfer times are
> not set.
>
> > The amount of time it takes to handle that player
> > input doesn't mean the next tick is delayed by that much.
>
> Tick's don't delay, they are supposed to be a rugged timescale, if you
> miss a tick, you miss out completely - herin lies the issue.
>
> > The ticks
> > happen at a fixed rate. Not an approximate one. Not a loosely
> > governed one. They happen at regular intervals. This does not mean
> > that it takes 1/33 of a second to calculate them.
>
> No but at 33 fps it does! 1 tick per frame. 1 tick takes 1 frame to
> calculate, how long is a frame? 1/33rd of a second, so how long is the
> server taking to make a tick? 1/33rd of a second.
>
> > This only means
> > that 33 of them occur per second. It might only take 1/333 of a
> > second to calculate it. The rest of the time is spent doing
> > absolutely nothing.
>
> The time taken to calculate gameworld changes is governed by the
> current processing rate, of which the best measure we currently have
> is the servers FPS. A tick cannot be generated outside of a frame, and
> similarly a frame cannot happen outside of a previously played tick or
> it generates the next tick (once every {tickrate} per second). Spare
> frames which occur when there is no client data to be processed may
> well be wasted, but that's not what concerns me, as I am concerned
> when frames take too long to process.
>
> > Again, the server fps tells you how quickly the
> > code that handles input is running.
>
> Indeed it does! So, if it takes more than a tick to handle the input,
> does the input get processed 'on time', given that it's now missed the
> last update queue on the OUTPUT channel (which occurs once every tick,
> as you've been trying to remind me)?
>
> > If it is running faster than the
> > tickrate, then this means that the tick calculations are not being
> > starved for data.
>
> Ok, some 'OS' course style terminology then, I am not concerned with
> tick's being starved for data, but frames being swamped for data!
>
> > This means everything is happening fast enough for
> > the gameworld to continue onward without incident. This is why Alfred
> > (or if not Alfred, it was someone from Valve anyways) has said in the
> > past that as long as your server fps is higher than your tickrate
> > everything is hunky dory.
>
> I would expect that this statement was intended more generally and
> does not cover instances where you may be close to the line. The
> problems I describe are common to servers which manage sub 100fps
> however, so it's not even that close in reality.
>
> > How much higher it is is irrelevant, since
> > as long as it is higher the gamestate calculations aren't being
> > starved. As server fps gets higher and higher it only means that
> > there is a lot more idle time spent doing absolutely nothing.
>
> Indeed, time spent doing nothing, but why is it you cant remind
> yourself that for good performance we need data to be processed and
> leave as fast as possible so that ticks and new data can be processed
> (nearly) exactly on time, rather than one tick late?
>
> > Gamestate is king.
>
> If you are talking about time-geometry based calculations, then yes,
> of course gaestate is king, however it's not alone. Sadly, this is not
> what i'm talking about.
>
> > Nothing happens faster or more often than the
> > gamestate rate, since the only thing happening is that gamestate
> > progression.
>
> This isn't true. Gamestates are not played once ever and never touched
> again. Gamestates can be replayed up to sv_maxunlag seconds back in
> time. Client data is not processed on an ad-hoc when you feel like it
> fashion either, it has to be done before the next tick is generated if
> it's going to make the outbound channel queue on time. If it doesn't
> then it's going to be sent from the server 1 tick late, worst case
> scenario is that you have waited nearly 2/33rds of a second before the
> data even reaches the servers NIC to go out!
>
> Ok, the final statement then as I think I need to be next to you with
> a pen and a whiteboard to draw some timelines and architecture
> diagrams to really get my point accross. Go to one of your servers and
> set fps_max to 33 or 34. See how it feels. Play with your client rates
> then too, see how they react (try some of the 'common rates' including
> settings for cl_interp and cl_smoothtime). Check net_channels and see
> what's happening in there. Try reducing cl_cmdbackup and see how much
> more destructive it is with your servers fps limited, then ask
> yourself why.
>
> remember during a 'tick' the gameworld changes from one state to
> another, and time increments by 1 tick. The time taken for a tick is
> always 1/{tickrate} however there is no garuntee that all ticks will
> be processed or all ticks will result in a packet to the client.
> during a frame the gameworld state for some previous tick is changed
> based upon new data and subsiquent ticks are regulated with regard to
> this new information. A frame can have to deal with more than one tick
> of information before it has completed, and the time it lasts is
> unknown. New information is released upon the next tick (along with
> that tick's data) (which is why ticks specify the packetrate).
>
> _______________________________________________
> 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
