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 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 > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
