Whisper wrote:
But you can run rcon stats pretty fast, but in any case as the rcon stats line you have posted here illustrates the problem.
Fast but unreliable. The method for generating this information also may not be compatible with this kind of action. (How do you judge how many frames are going per second if your being asked more frequently than every frame? Should that say INF?
The CPU is just above average, but not abnormally high and not what you would expect to see if your server fps crashes.
So the SRCDS process itself isn't using the time, or so it claims.
Oh well, looks like we are all in the same boat and have to wait for Valve to come out with a fix.
:)
Hmmm, and if I read your notes correctly then the sort term fix is to set the sv_minupdaterate back to default i.e. 0.
It should help yes, and good deduction :)
I'll give it a try.
Also might want to try dropping back to default tickrate to reduce the effects of the lag.
I threw the map thing in as I thought it might have something to do with de_nuke or the running of de_nuke on the same box causing the all SRCDS processes across the server to lag, without actually showing anything in CPU stats.
No worries, totally understandable, but in terms of the server it's procesing concern wiht maps is geometry, which is not significantly changing in complexity. The server doesn't do HDR :)
Also the lag lasts a lot longer than the resolution of most of the monitoring tools we use, i.e. Several Seconds.
The client side effect lasts that long, but that's got little to do wiht the server side effects. Have you observed the client effects of the slow data with cl_interpolate 0, cl_smooth 0?
Its still annoying as hell, for obvious reasons
yup, I feel sorry for many providers that are getting it in the neck on this one. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
