FPS Explanation

[Monk]

(03-12-2010, 08:11 PM)BehaartesEtwas Wrote:  

(03-09-2010, 02:30 AM)loopyman Wrote:  Over LAN or WAN?

WAN. it was on my clan servers some time ago.

(03-10-2010, 11:51 AM)Monk Wrote:  Post technical proof. Not graphs. Proof.

err... how do you proof that the hits are not so well recognized with lower fps as with higher?
a scientific proof would work like this:
- some script or so decides randomly per day how many fps the server runs with. to make sure nobody knows the actual fps, the stats command should be disabled. the script writes the actual fps for each day into some private place that can be viewed only after the test is completed.
- a number of players plays on the server every day and reports for each playing day a judge how good the server runs (e.g. on some scale from 1=good to 6=bad). this report is kept private until the test is over.
- finally when the test is over, the mean quality judge will be plotted against the actual server fps.

Still this is only a proof if you believe the tester did what he says. But you can to the same and see if the result reproduces.

I cannot provide you with this, because I didn't do it precisely that scientific. What I did (a very long time ago, more than a year) is the following:
- a predecessor of the fps meter recorded the fps of my clan public server all the time (similar to the long time measurements of now). the server was running at 500 fps in those days, but very stable after some optimizations. as I considered the optimizations to be finished, I did no longer observe the fps, but I kept the "fps meter" running.
- we (my clan) decided to install a hlds war server. our cs1.6 team played on it from time to time, but as I did not had contact to anyone of the team I did never know when they played on it.
- when a war was going on the hlds server, all css servers suffered from fps instabilities. they fluctuated between 100 and 500 fps, but usually stayed above 100 (= the tickrate). I did not know this, because I did not watched the fps anymore.
- I (and other css clan members) noticed that the css server did not run very well anymore, but only in certain times.
- only then I started watching at the fps graphs again and noticed the fluctuations.
- it took some time to realize the problem (hlds and srcds don't run well together on the same root server), so I could observe for quite some days a strong correlation between the observed loss of quality and the fps instabilities. as I could not watch the fps while playing on the server at the same time, it continued to be a "double blind" test, meaning I did not know if the fps were stable or not while I made the actual observation.

nowadays I know the reason why lower fps are a problem, see the first and second post of this thread. in fact it does not really matter if the fps are constantly low or fluctuating only some times to lower fps. the latter will have a less likely but more severe effect on each command.

if you don't believe this, make the test yourself. of course you should use good players to judge the server quality. it will probably take some experience in the game to be able to see the difference (someone who does not precisely aim will not know whether the server did not recognize a hit or he simply missed his target).

that there is some effect can be proofed very easily: go on a server running at 1000fps and run "rcon status" (it's important to run the status command on the server not on the client!). there will be a ping shown in the status display. run the command several times and write down the average ping. then run "rcon fps_max 100" and again determine the average ping using some "rcon status" commands. it will be 5ms higher, just as predicted by our theory (that says, 100fps will add equally distributed some time between 0ms and 10ms to the ping; 1000fps will only add something up to 1ms => average ping will be 4.5ms higher at 100fps).

Listen, I am going to say this. You *cannot* prove that it affects anything, AT ALL, considering the game is closed source and there is zero technical proof that it does help anything at all. I've had the engine up to 4,294,000,000 FPS (about the max size of an unsigned long) and it doesn't do anything (not even busy wait, just sits there and calls nanosleep so many times over in a loop). The users that were playing at 100,000FPS didnt noticed a different compared to 100fps. However, they did notice when they were set to SCHED_OTHER instead of SCHED_FIFO, probably due to the slop of the scheduler, as the tree list in the queue have process latency as OTHER gets ran last in that queue.

sleeping very accurately has no effect and doesn't make precision any better in the game, since everything is estimated. The best way to get a good server is to have low latency, and low interrupt latency (hardware specific)