Re: [hlds] shots registering
On 8/10/05, Clayton Macleod [EMAIL PROTECTED] wrote: I give up. You're contradicting yourself, o.0 I would hope not, but never mind :) stating one thing and a little while later something else, disagreeing with me one minute, and agreeing the next while thinking you're still disagreeing, and even throwing in some condescension for good measure. (OK, that part I liked, heh) Have a good one. And you. I've lost interest trying to find out where we're both wrong and both right. On 8/9/05, James Tucker [EMAIL PROTECTED] wrote: snip -- Clayton Macleod ___ 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
Re: [hlds] shots registering
On 8/8/05, Clayton Macleod [EMAIL PROTECTED] wrote: I'm sure I miss some stuff quite often, we're all human. And, well, from the description Alfred just gave for server fps and from reading the Source netcode description page and associating the two, generating packets to send to clients and the rate that packets get sent at seem to have absolutely nothing to do with server fps and everything to do with tickrate. **Alfred just said that server fps does not change the game simulation.** The server doesn't send packets out for each server 'frame', it sends packets out after each tick, containing the data calculated for that tick. Every tick is a seperate moment in time, a seperate state of the game, a gamestate. Got a default 33 tickrate server, you get 33 seperate gamestates per second, no more, (and CPU not being a hinderance) no less. You just stated that a 500fps server will give you 500 updates per second, when clearly this is not the case. No I didn't, I said it is capable of processing a piece of client data in 1/500 seconds, as opposed to 1/33 seconds (the fact that it rewinds by cl_interp+latency and processes that tick is irrelevant for this discussion). When you do the calculations of the timeline of processing of packets vs. gameworld progression (tick's passing) you will find that server side FPS has a major impact on PROCESSING LATENCY. This has NOTHING TO DO WITH CLIENT LATENCY. Interpolation is not important here, it is merely affected, and moreso when a server is running at a low FPS. The REASON is simple - at 33 fps the server takes - 1 whole tick to process a frame - next update will happen in a minimum of 1 tick's time (no sub-tick udpates (client re-play will occur for corrected ticks) and so on. Forget about the gameworld rate - this is about how fast the server processes data WHEN IT HAS ARRIVED to WHEN IT LEAVES (the server). On a server that is only managing to process one frame per tick (or marginally worse as is common when fps is so low (typicall a machine which can manage 30-35 fps will only run at 30-31, however I have neither the time nor inclanation to explain that one) will send responses 1 tick later than optimal as the next update after a processed command will be 2 ticks after it arrived. Arrive mid-tick - tick completes, next frame makes new tick AND processes client data (can it do both in one frame?), data into queue, next tick - send. I hope this is more clear. :-) I also don't know why you're talking about client-side rendering interpolation, that has nothing to do with the server fps we're talking about. I think the fact that it has been called server fps is a little confusing, since we measure our graphics performance by this same term, fps. But the two aren't nearly the same thing. Client-side interpolation only serves to smooth out your view between server ticks, it's got nothing to do with the server. If your computer can give you 66fps and you're playing on a 33 tickrate server then you get one interpolated frame for every 'real' frame. The server is still only generating 33 seperate gamestates. Client-side interpolation is part of the whole seperation of netcode and graphics. If your computer's beefy enough to render graphics at a much faster rate than the server is generating seperate gamestates, well, no reason it shouldn't give you as smooth an experience as possible. But it does so by making up its own data that has nothing to do with the server's data, other than the fact that it is using the server's seperate moments in time to form its guess at what goes inbetween the server's moments in time. The server still only deals with its own rate of simulation. If there is any benefit to the server being able to process input faster than it is simulating the gameworld, I'm not sure I see what that might be. If it only simulates the gameworld 33 times a second, why would it need to process player input at a rate any faster than that? As long as it is capable of processing that input fast enough to feed the next simulation step, you're golden. It's not a continuously changing world like our world is. It is a world based on completely seperate instances in time, coming at a fixed rate, but each one a representation of the world only at that instant. It is not a continuous, uninterrupted flow of time. Being able to process more input data than there are simulation steps shouldn't mean anything, since it is still only those simulation steps that make up the world. Client side interpolation is affected if the updaterate is too low or more importantly the real packetrate. (As updaterate is merely a desired 'boot-time' variable, whereas packetrate is an observed variable of the run-time system). at cl_interp 0.1 the above scenario cuts a VERY fine line and will cause an extrapolation scenario relatively frequently. On 8/8/05, James Tucker [EMAIL PROTECTED] wrote: Clayton, honestly sir for someone with quite a
Re: [hlds] shots registering
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. 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. The amount of time it takes to handle that player input doesn't mean the next tick is delayed by that much. 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. 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. Again, the server fps tells you how quickly the code that handles input is running. If it is running faster than the tickrate, then this means that the tick calculations are not being starved 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. 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. Gamestate is king. Nothing happens faster or more often than the gamestate rate, since the only thing happening is that gamestate progression. On 8/9/05, James Tucker [EMAIL PROTECTED] wrote: No I didn't, I said it is capable of processing a piece of client data in 1/500 seconds, as opposed to 1/33 seconds (the fact that it rewinds by cl_interp+latency and processes that tick is irrelevant for this discussion). When you do the calculations of the timeline of processing of packets vs. gameworld progression (tick's passing) you will find that server side FPS has a major impact on PROCESSING LATENCY. This has NOTHING TO DO WITH CLIENT LATENCY. Interpolation is not important here, it is merely affected, and moreso when a server is running at a low FPS. The REASON is simple - at 33 fps the server takes - 1 whole tick to process a frame - next update will happen in a minimum of 1 tick's time (no sub-tick udpates (client re-play will occur for corrected ticks) and so on. Forget about the gameworld rate - this is about how fast the server processes data WHEN IT HAS ARRIVED to WHEN IT LEAVES (the server). On a server that is only managing to process one frame per tick (or marginally worse as is common when fps is so low (typicall a machine which can manage 30-35 fps will only run at 30-31, however I have neither the time nor inclanation to explain that one) will send responses 1 tick later than optimal as the next update after a processed command will be 2 ticks after it arrived. Arrive mid-tick - tick completes, next frame makes new tick AND processes client data (can it do both in one frame?), data into queue, next tick - send. I hope this is more clear. :-) Client side interpolation is affected if the updaterate is too low or more importantly the real packetrate. (As updaterate is merely a desired 'boot-time' variable, whereas packetrate is an observed variable of the run-time system). at cl_interp 0.1 the above scenario cuts a VERY fine line and will cause an extrapolation scenario relatively frequently. -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] shots registering
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 1,
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
Re: [hlds] shots registering
--
[ 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 1,
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
Re: [hlds] shots registering
I give up. You're contradicting yourself, stating one thing and a little while later something else, disagreeing with me one minute, and agreeing the next while thinking you're still disagreeing, and even throwing in some condescension for good measure. (OK, that part I liked, heh) Have a good one. I've lost interest trying to find out where we're both wrong and both right. On 8/9/05, James Tucker [EMAIL PROTECTED] wrote: snip -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] shots registering
On 8/7/05, Clayton Macleod [EMAIL PROTECTED] wrote: I have sent a description to the hlds_linux list two times in the last couple of months :) FPS is how quickly the input processing loop runs, tickrate is how often the game runs a simulation step. So FPS will be equal or greater than tickrate. A larger FPS will read packets faster but won't simulate the game differently. - Alfred That last sentence is rather nice. So, are you still worrying about 500fps when even 34 would be more than enough? (at least on a default 33 tickrate server...) Clayton, honestly sir for someone with quite a good knowledge of the source engine you do sometimes miss some really important stuff You will ALWAYS gain an advantage LOWERING LATENCY by increasing the server (and client) side FPS. No, this does not increase the tick rate you are correct, and again, it is correct that it doesn't change teh rate of gameworld simulation - IT DOES CHANGE THE TIME TO PROCESS PACKET AND THE TIME TO NEXT PACKET GENERATION - READ: LATENCY. Quick example: @500fps packet arrives at server at 0ms next frame comes in a max of 0.002 seconds frame takes 0.002 seconds packet put in outbound queue at t= 0.004s. Server processing latency: 0.004s. (update rate and rate also put limits on this, however you will see that there is an optimal, but it's not at the tickrate). @33fps packet arrives again at 0ms next frame comes in a max of 0.033s frame takes 0.033s seconds packet put in queue at t=0.066 Server processing latency: 0.066s. N.B. that at 33fps the server is starting to approach several of the source netcode latency limits already - and this is without RTT or DTT's completed. Yes there are adjustments made for this, however we haven't as I said, hit any networking yet. Remember too that a frame doesn't necessarily process the next tick! A frame can process any tick back to a maximum of the largest clients cl_interp (or it's cap). On 8/3/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Ask the guys that know directly -- Clayton Macleod ___ 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
Re: [hlds] shots registering
On 8/8/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] The reason I think that it is important to run at a high fps on the servers is, you have multiple clients, and assuming you have gone the whole high rate servers route, you will be receiving a whole lot of updates, in order of up to 100 per second from up to 40 different sources depending upon the player number. In fact I conjecture that now that tickrate has reduced significantly number of simulations run per second in SRCDS, it is all the more important to run with as high an fps as possible to ensure that each tick is simulating the word with the most up to date data as possible. It also seems that raising the fps on a server does not carry the same CPU impact that raising the tickrate does, I'm happy to be told I am incorrect, but that is what I see. I have made some big changes to http://forums.steampowered.com/forums/showthread.php?s=threadid=293285 to introduce a lot of definitions and bring them into a single location and attempt to explain how they relate to each other as well as deal with the god forsaken choke issue. One thing I am not sure about is this, will clients get choke if the servers fps falls beneath the servers tickrate? Yes - I have had the unfortuante experience to play on a high tickrate server that is only capable of 50fps - the results were large choke, common loss registration, rougly 30% of client bullets which render client side effects never in fact fired on the server (packets seemed to be simply dropped - maybe even entire ticks were dropped). Interestingly the optimal settings were not intuitively lower netcode settings to force a reduction in required processing - but in fact the opposite - to allow processing as soon and as fast as possible within the 50fps limitation. You could check this more thoroughly with the fps_max setting - however this may not affect ticks depending on the organisation of the threads + loops. On another very quick side note, I explained server side processing latency in the last mail on this thread - this is massively important to your snipers who need a complete round trip message with the server to get their scope out. For a sniper, waiting 0.2s (~40ms ping @ ~33fps on server side) is not acceptable. On 8/8/05, Clayton Macleod [EMAIL PROTECTED] wrote: I have sent a description to the hlds_linux list two times in the last couple of months :) FPS is how quickly the input processing loop runs, tickrate is how often the game runs a simulation step. So FPS will be equal or greater than tickrate. A larger FPS will read packets faster but won't simulate the game differently. - Alfred That last sentence is rather nice. So, are you still worrying about 500fps when even 34 would be more than enough? (at least on a default 33 tickrate server...) On 8/3/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Ask the guys that know directly -- Clayton Macleod ___ 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
Re: [hlds] shots registering
I'm sure I miss some stuff quite often, we're all human. And, well, from the description Alfred just gave for server fps and from reading the Source netcode description page and associating the two, generating packets to send to clients and the rate that packets get sent at seem to have absolutely nothing to do with server fps and everything to do with tickrate. **Alfred just said that server fps does not change the game simulation.** The server doesn't send packets out for each server 'frame', it sends packets out after each tick, containing the data calculated for that tick. Every tick is a seperate moment in time, a seperate state of the game, a gamestate. Got a default 33 tickrate server, you get 33 seperate gamestates per second, no more, (and CPU not being a hinderance) no less. You just stated that a 500fps server will give you 500 updates per second, when clearly this is not the case. I also don't know why you're talking about client-side rendering interpolation, that has nothing to do with the server fps we're talking about. I think the fact that it has been called server fps is a little confusing, since we measure our graphics performance by this same term, fps. But the two aren't nearly the same thing. Client-side interpolation only serves to smooth out your view between server ticks, it's got nothing to do with the server. If your computer can give you 66fps and you're playing on a 33 tickrate server then you get one interpolated frame for every 'real' frame. The server is still only generating 33 seperate gamestates. Client-side interpolation is part of the whole seperation of netcode and graphics. If your computer's beefy enough to render graphics at a much faster rate than the server is generating seperate gamestates, well, no reason it shouldn't give you as smooth an experience as possible. But it does so by making up its own data that has nothing to do with the server's data, other than the fact that it is using the server's seperate moments in time to form its guess at what goes inbetween the server's moments in time. The server still only deals with its own rate of simulation. If there is any benefit to the server being able to process input faster than it is simulating the gameworld, I'm not sure I see what that might be. If it only simulates the gameworld 33 times a second, why would it need to process player input at a rate any faster than that? As long as it is capable of processing that input fast enough to feed the next simulation step, you're golden. It's not a continuously changing world like our world is. It is a world based on completely seperate instances in time, coming at a fixed rate, but each one a representation of the world only at that instant. It is not a continuous, uninterrupted flow of time. Being able to process more input data than there are simulation steps shouldn't mean anything, since it is still only those simulation steps that make up the world. On 8/8/05, James Tucker [EMAIL PROTECTED] wrote: Clayton, honestly sir for someone with quite a good knowledge of the source engine you do sometimes miss some really important stuff You will ALWAYS gain an advantage LOWERING LATENCY by increasing the server (and client) side FPS. No, this does not increase the tick rate you are correct, and again, it is correct that it doesn't change teh rate of gameworld simulation - IT DOES CHANGE THE TIME TO PROCESS PACKET AND THE TIME TO NEXT PACKET GENERATION - READ: LATENCY. Quick example: @500fps packet arrives at server at 0ms next frame comes in a max of 0.002 seconds frame takes 0.002 seconds packet put in outbound queue at t= 0.004s. Server processing latency: 0.004s. (update rate and rate also put limits on this, however you will see that there is an optimal, but it's not at the tickrate). @33fps packet arrives again at 0ms next frame comes in a max of 0.033s frame takes 0.033s seconds packet put in queue at t=0.066 Server processing latency: 0.066s. N.B. that at 33fps the server is starting to approach several of the source netcode latency limits already - and this is without RTT or DTT's completed. Yes there are adjustments made for this, however we haven't as I said, hit any networking yet. Remember too that a frame doesn't necessarily process the next tick! A frame can process any tick back to a maximum of the largest clients cl_interp (or it's cap). -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] shots registering
I have sent a description to the hlds_linux list two times in the last couple of months :) FPS is how quickly the input processing loop runs, tickrate is how often the game runs a simulation step. So FPS will be equal or greater than tickrate. A larger FPS will read packets faster but won't simulate the game differently. - Alfred That last sentence is rather nice. So, are you still worrying about 500fps when even 34 would be more than enough? (at least on a default 33 tickrate server...) On 8/3/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Ask the guys that know directly -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] shots registering
-- [ Picked text/plain from multipart/alternative ] The reason I think that it is important to run at a high fps on the servers is, you have multiple clients, and assuming you have gone the whole high rate servers route, you will be receiving a whole lot of updates, in order of up to 100 per second from up to 40 different sources depending upon the player number. In fact I conjecture that now that tickrate has reduced significantly number of simulations run per second in SRCDS, it is all the more important to run with as high an fps as possible to ensure that each tick is simulating the word with the most up to date data as possible. It also seems that raising the fps on a server does not carry the same CPU impact that raising the tickrate does, I'm happy to be told I am incorrect, but that is what I see. I have made some big changes to http://forums.steampowered.com/forums/showthread.php?s=threadid=293285 to introduce a lot of definitions and bring them into a single location and attempt to explain how they relate to each other as well as deal with the god forsaken choke issue. One thing I am not sure about is this, will clients get choke if the servers fps falls beneath the servers tickrate? On 8/8/05, Clayton Macleod [EMAIL PROTECTED] wrote: I have sent a description to the hlds_linux list two times in the last couple of months :) FPS is how quickly the input processing loop runs, tickrate is how often the game runs a simulation step. So FPS will be equal or greater than tickrate. A larger FPS will read packets faster but won't simulate the game differently. - Alfred That last sentence is rather nice. So, are you still worrying about 500fps when even 34 would be more than enough? (at least on a default 33 tickrate server...) On 8/3/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Ask the guys that know directly -- Clayton Macleod ___ 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
Re: [hlds] shots registering
-- [ Picked text/plain from multipart/alternative ] This is how I understand it: tickrate = the amount of times per second a calculation of all player actions and physics is done fps or server fps = the amount of times per second Inputs and Outputs are monitored The reson for wanting a higher fps is that it gives you a finer granularity over I/O's than you would otherwise have, if left at Windows default of 60 times a second. It is also important in context of a server because there are multiple clients connected to it, thus the server needs to be able to deal with incoming data from multiple sources, and when running a high tickrate/high rate server, with clients who also run at equally high fps and rates, there is a hell of a lot more I/O going on than if server client was all running at default. In any case there is no reason to believe what I have just said, the important thing is how the server feels once the changes to tickrate, fps_max, sv_maxrate sv_maxupdaterate have been implemented. Those of you who have the hardware and connection to cope will know that playing on a well configured server with a great Internet connection with a client that also hardware capable, with a suitable Internet connection, and properly configured rates, is a vastly superior gaming experience than playing with defaults. The fact of the matter is, in many case, somewhere along the line a crucial part of this very precarious balancing act falls down and somebody (never the client god forbid) has to take the blame. Too many times a poor gaming experience can be attributed to either a poorly configured server for the resources available and/or a poorly configured client. People tend to forget that the Valve defaults tend to cater to the lowest common denominator, which provides for a reasonable, and more importantly hoped for trouble free experience, but these setups are less than optimal so long as all pieces of the puzzle can cope with optimization of Valves default setups. Cheers On 8/3/05, Scott Tuttle [EMAIL PROTECTED] wrote: I just joined the list group so I am not exactly sure what the below conversation is about. But I upped my sys_ticrate today and am running wmp on my windows 2003 server. I get the following. stats CPU In Out Uptime Users FPS Players 4.15 13.03 13.27 482 146 510.94 6 -Original Message- From: [EMAIL PROTECTED] [mailto:hlds- [EMAIL PROTECTED] On Behalf Of Morten Trydal Sent: Tuesday, August 02, 2005 8:18 PM To: hlds@list.valvesoftware.com Subject: Re: [hlds] shots registering what about if the server if almost full or full? i see it's empty when you got that high fps Morten - Original Message - From: [EMAIL PROTECTED] To: hlds@list.valvesoftware.com Sent: Tuesday, August 02, 2005 10:50 PM Subject: Re: [hlds] shots registering -- [ Picked text/plain from multipart/alternative ] CPU In Out Uptime Users FPS Players 1.56 0.00 0.00 7801 15 539.16 0 this is my server 66 tic -- ___ 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
Re: [hlds] shots registering
has valve ever explained how tickrate relates to server fps? I don't recall. I'd always thought that as long as server fps is greater than tickrate then you shouldn't notice any hiccups in the game at all. But if server fps falls below tickrate, then not every tick is producing new data. I don't know that that is correct, though. On 8/2/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] This is how I understand it: tickrate = the amount of times per second a calculation of all player actions and physics is done fps or server fps = the amount of times per second Inputs and Outputs are monitored The reson for wanting a higher fps is that it gives you a finer granularity over I/O's than you would otherwise have, if left at Windows default of 60 times a second. It is also important in context of a server because there are multiple clients connected to it, thus the server needs to be able to deal with incoming data from multiple sources, and when running a high tickrate/high rate server, with clients who also run at equally high fps and rates, there is a hell of a lot more I/O going on than if server client was all running at default. In any case there is no reason to believe what I have just said, the important thing is how the server feels once the changes to tickrate, fps_max, sv_maxrate sv_maxupdaterate have been implemented. Those of you who have the hardware and connection to cope will know that playing on a well configured server with a great Internet connection with a client that also hardware capable, with a suitable Internet connection, and properly configured rates, is a vastly superior gaming experience than playing with defaults. The fact of the matter is, in many case, somewhere along the line a crucial part of this very precarious balancing act falls down and somebody (never the client god forbid) has to take the blame. Too many times a poor gaming experience can be attributed to either a poorly configured server for the resources available and/or a poorly configured client. People tend to forget that the Valve defaults tend to cater to the lowest common denominator, which provides for a reasonable, and more importantly hoped for trouble free experience, but these setups are less than optimal so long as all pieces of the puzzle can cope with optimization of Valves default setups. -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] shots registering
Exactly what combination of tickrate/fps of a server would dictate a good registering server?As far as that goes what combination of cvars would effect a good registering server for 1.6? BeNt http://www.gorillazsouth.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] shots registering
-- [ Picked text/plain from multipart/alternative ] The higher the better. A tickrate of 100 means the server is theoretically running simulations every 10ms An fps of 500 means the server is theoretically doing I/O updates ever 2ms The only reason I have suggested that tickrate 600 be used is: a) Nothing seems to work to change the fps_max until a value greater than 500 is used b) I cbf working out exactly what the value greater than 500 is c) Nobody has provided any explanation whatsoever as to why it is impossible to change the *rcon stats* fps actual value unless you do change by at least this amount, nor has anybody disagreed with me and said, No, Whisper, you are incorrect. Since Values between 300 and 500 seem to only cause the same *rcon stats* fps value as a default 300 fps_max to output an fps value of around 250. I pontificate quite subtantially about all this here: http://forums.steampowered.com/forums/showthread.php?s=threadid=293285 as I finally got sick and tired of every other Windows SRCDS post asking about tickrate. On 8/3/05, Agent|BeNt [EMAIL PROTECTED] wrote: Exactly what combination of tickrate/fps of a server would dictate a good registering server?As far as that goes what combination of cvars would effect a good registering server for 1.6? BeNt http://www.gorillazsouth.com ___ 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
Re: [hlds] shots registering
where are you seeing this fps = i/o at? Because their network code description page says that i/o is part of each tick's calculation. On 8/3/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] The higher the better. A tickrate of 100 means the server is theoretically running simulations every 10ms An fps of 500 means the server is theoretically doing I/O updates ever 2ms The only reason I have suggested that tickrate 600 be used is: a) Nothing seems to work to change the fps_max until a value greater than 500 is used b) I cbf working out exactly what the value greater than 500 is c) Nobody has provided any explanation whatsoever as to why it is impossible to change the *rcon stats* fps actual value unless you do change by at least this amount, nor has anybody disagreed with me and said, No, -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
Re: [hlds] shots registering
-- [ Picked text/plain from multipart/alternative ] Ask the guys that know directly On 8/4/05, Clayton Macleod [EMAIL PROTECTED] wrote: where are you seeing this fps = i/o at? Because their network code description page says that i/o is part of each tick's calculation. On 8/3/05, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] The higher the better. A tickrate of 100 means the server is theoretically running simulations every 10ms An fps of 500 means the server is theoretically doing I/O updates ever 2ms The only reason I have suggested that tickrate 600 be used is: a) Nothing seems to work to change the fps_max until a value greater than 500 is used b) I cbf working out exactly what the value greater than 500 is c) Nobody has provided any explanation whatsoever as to why it is impossible to change the *rcon stats* fps actual value unless you do change by at least this amount, nor has anybody disagreed with me and said, No, -- Clayton Macleod ___ 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
Re: [hlds] shots registering
What kind of fps do you get from an rcon stats command? On 8/2/05, dexion [EMAIL PROTECTED] wrote: they may have poorly configured client settings, but its nearly impossible to get someone to configure their client correctly when they set it up perfectly dex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 8:21 AM To: hlds@list.valvesoftware.com Subject: [hlds] shots registering -- [ Picked text/plain from multipart/alternative ] Was just wondering if anyone has to deal with alot of peaple saying that there shots are not registering? i have went to 100 tickrate , pings are good and they still complain.. -- ___ 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
RE: [hlds] shots registering
well, whatever I like, I run the servers. I set them for default so roughly 250ish. dex keep in mind tickrate is only part of the puzzle...updaterate...rates all sorts of junk. http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html dex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ian mu Sent: Tuesday, August 02, 2005 11:56 AM To: hlds@list.valvesoftware.com Subject: Re: [hlds] shots registering What kind of fps do you get from an rcon stats command? On 8/2/05, dexion [EMAIL PROTECTED] wrote: they may have poorly configured client settings, but its nearly impossible to get someone to configure their client correctly when they set it up perfectly dex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 8:21 AM To: hlds@list.valvesoftware.com Subject: [hlds] shots registering -- [ Picked text/plain from multipart/alternative ] Was just wondering if anyone has to deal with alot of peaple saying that there shots are not registering? i have went to 100 tickrate , pings are good and they still complain.. -- ___ 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
Re: [hlds] shots registering
Yeah, sorry meant to the original post. Agree, its just a part of the pic, was just wondering if he was getting poor fps which was evidence of it. On 8/2/05, dexion [EMAIL PROTECTED] wrote: well, whatever I like, I run the servers. I set them for default so roughly 250ish. dex keep in mind tickrate is only part of the puzzle...updaterate...rates all sorts of junk. http://www.valve-erc.com/srcsdk/general/multiplayer_networking.html dex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ian mu Sent: Tuesday, August 02, 2005 11:56 AM To: hlds@list.valvesoftware.com Subject: Re: [hlds] shots registering What kind of fps do you get from an rcon stats command? On 8/2/05, dexion [EMAIL PROTECTED] wrote: they may have poorly configured client settings, but its nearly impossible to get someone to configure their client correctly when they set it up perfectly dex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Tuesday, August 02, 2005 8:21 AM To: hlds@list.valvesoftware.com Subject: [hlds] shots registering -- [ Picked text/plain from multipart/alternative ] Was just wondering if anyone has to deal with alot of peaple saying that there shots are not registering? i have went to 100 tickrate , pings are good and they still complain.. -- ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] shots registering
its probly a bit ott, our server is capped at 200, and it doesnt seem to deviate from it much at all. server runs smooth and reg's alot. nice sub 20 pings too (uk) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: 02 August 2005 22:00 To: hlds@list.valvesoftware.com Subject: Re: [hlds] shots registering -- [ Picked text/plain from multipart/alternative ] 539.16 fps is bad? -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: 28/07/2005 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
RE: [hlds] shots registering
I just joined the list group so I am not exactly sure what the below conversation is about. But I upped my sys_ticrate today and am running wmp on my windows 2003 server. I get the following. stats CPU InOut Uptime Users FPSPlayers 4.15 13.03 13.27 482 146 510.94 6 -Original Message- From: [EMAIL PROTECTED] [mailto:hlds- [EMAIL PROTECTED] On Behalf Of Morten Trydal Sent: Tuesday, August 02, 2005 8:18 PM To: hlds@list.valvesoftware.com Subject: Re: [hlds] shots registering what about if the server if almost full or full? i see it's empty when you got that high fps Morten - Original Message - From: [EMAIL PROTECTED] To: hlds@list.valvesoftware.com Sent: Tuesday, August 02, 2005 10:50 PM Subject: Re: [hlds] shots registering -- [ Picked text/plain from multipart/alternative ] CPU InOut Uptime Users FPS Players 1.56 0.00 0.00780115 539.16 0 this is my server 66 tic -- ___ 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
