12-08-2009, 08:16 PM
@ Chas
I have this SourceTV "problem" also. It might be related to "tv_autorecord 1" because BehaartesEtwas hasn't noticed the problem (he's got "tv_autorecord 0").
@ Behaartes, Monk
Have you ever considered that 5-6 us variation in 1000 us sleep means that the engine just does calculations 5-6 us later than in the optimal situation. The interrupts don't fire immediately from usleep or from network interface interrupts, but what's the real effect? You're talking about nanosecond scale without sensible relation to the real world.
The effect of fluctuating FPS around 1000 FPS is also negligible. A normal ~1000 FPS server's fluctuation means that some frames take longer than the 0.001 seconds to calculate. The server updates world every 0.01 seconds (100 tick). So if the server would happen to calculate some frames for 0.005 seconds, it would affect the lag compensation only momentarily. I'm quite sure that the ping fluctuation caused by the inaccuracy during the 0.005 seconds is averaged to hell in the lag compensation engine.
Other stuff...
I believe that fpsmeter.org's means of measuring the FPS are way too inaccurate to catch the real lag or real problems on a server. Srcds engine and its lag compensation can handle the FPS drops very well. The real problems start when the engine calculates multiple (by multiple I mean 10-100) frames consecutively longer than 0.001 seconds each.
I think Monk and BehaartesEtwas have both created some very cool usleep hooking system, which could be used to count the number of frames rendered by the engine in specific time interval. BehaartesEtwas tried to use the system to very accurately calculate *every* frame. I suggested calculating the average over number of frames, thus identifying when the server has not effectively reached 1000 frames per second. With this kind of system it would be possible to determine when the server has just momentarily "dropped" one frame and when it has *lagged* for multiple frames.
The ongoing debate over "stable" 1000 FPS servers is in a nutshell in this post:
http://forums.srcds.com/viewpost/79960#pid79960
I have this SourceTV "problem" also. It might be related to "tv_autorecord 1" because BehaartesEtwas hasn't noticed the problem (he's got "tv_autorecord 0").
@ Behaartes, Monk
Have you ever considered that 5-6 us variation in 1000 us sleep means that the engine just does calculations 5-6 us later than in the optimal situation. The interrupts don't fire immediately from usleep or from network interface interrupts, but what's the real effect? You're talking about nanosecond scale without sensible relation to the real world.
The effect of fluctuating FPS around 1000 FPS is also negligible. A normal ~1000 FPS server's fluctuation means that some frames take longer than the 0.001 seconds to calculate. The server updates world every 0.01 seconds (100 tick). So if the server would happen to calculate some frames for 0.005 seconds, it would affect the lag compensation only momentarily. I'm quite sure that the ping fluctuation caused by the inaccuracy during the 0.005 seconds is averaged to hell in the lag compensation engine.
Other stuff...
I believe that fpsmeter.org's means of measuring the FPS are way too inaccurate to catch the real lag or real problems on a server. Srcds engine and its lag compensation can handle the FPS drops very well. The real problems start when the engine calculates multiple (by multiple I mean 10-100) frames consecutively longer than 0.001 seconds each.
I think Monk and BehaartesEtwas have both created some very cool usleep hooking system, which could be used to count the number of frames rendered by the engine in specific time interval. BehaartesEtwas tried to use the system to very accurately calculate *every* frame. I suggested calculating the average over number of frames, thus identifying when the server has not effectively reached 1000 frames per second. With this kind of system it would be possible to determine when the server has just momentarily "dropped" one frame and when it has *lagged* for multiple frames.
The ongoing debate over "stable" 1000 FPS servers is in a nutshell in this post:
http://forums.srcds.com/viewpost/79960#pid79960
![[Image: banner.png]](http://css.setti.info/stats/server/78.46.42.232:27015/banner.png)