FPS Explanation

[loopyman]

A lot of people swear they can... Most of the time its an excuse for their failure to play a game.

Meh, they just pay more

[BehaartesEtwas]

I've done double blind tests. There is a difference.

[loopyman]

Over LAN or WAN?

[Terrorkarotte]

Same here with blind testing from 100 to 500 the people realised. Above 500 only a few. Above 1000 nobody.

[loopyman]

I suppose 100 to 500fps makes a difference... I believe there is a net graph that shows server side FPS and anybody with that turned on would notice an FPS difference than advertised

[Terrorkarotte]

With orangebox it is netgraph 4. Down on the left there is sv. That is somehow the server fps. But it neither the same to host_profile nor stats fps. Only similar. But if stats and host_profile drop it drops too.
The blind testing was on css and nobody got rcon to execute the stats command

[loopyman]

Sometimes people just blame it on the FPS or tick rate because they are bad and don't want to admit it

[Terrorkarotte]

I now. Best is if they mess up their netconfig and blame the server or the others even its their client that is out of sync.

[loopyman]

Classic ;D

[Monk]

(03-08-2010, 09:34 PM)BehaartesEtwas Wrote:  I've done double blind tests. There is a difference.

Post technical proof. Not graphs. Proof.

[BehaartesEtwas]

(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).

[css]

@ Behaartes
Your test is only one-way. Did you ever check that when you didn't notice any lags that there weren't anybody playing on the war server? Maybe you can spot some instabilities when the server is lagging, but how often does that happen? How many false-positives you got? And how many times you didn't notice lag when there actually was lag? Did you check only when you noticed lag?

I've also noticed several reasons why my server sometimes lags. I got very good explanations why it happens. It happens periodically sometimes. Even so I wouldn't make conclusions about whether the FPS is noticeable or not. Everybody can surely notice when it lags and you jump 0.5s back in time, but all the smaller lags and not-lags thought to be lags are not "documented". The test should cover all the possible scenarios better.

About three months ago on my server there was a brief moment when the server was working super-smooth. It was crashing all the time for couple weeks, but then out of the blue there was this 2 hour moment between crashes when the server registered everything super-accurately. Today I'm not so sure that it was in fact more accurate. Maybe it was just a feeling. Maybe it was true. Others said too that it was more accurate then. I'm not so sure. I have no proof

[BehaartesEtwas]

in those days I checked the fps graphs every time after I played on the server. there was a 100% correlation between fps instabilities and that kind of low-quality problem.

the ideal test-scenario I described (but I did not perform) is not one-way: if there are other problems, players will also report a bad quality if fps are high. you can calculate the correlation coefficient if you want to know how strong the influence of the fps is relative to all other possible causes. you can even distinguish between client problems / player feeling and server problems, if you look at the fluctuations of the player rating for the same fps settings. of course you need a large enough player-base for this.

I don't say fps variations are the only source of problems. Network problems can cause lags as well of course. But usually you can do nothing about them unless you are the ISP :-) I believe, fps variations are the only common software problem causing a bad quality. I can imagine other reasons but they are very unlikely...

[loopyman]

Sorry sir, but that previous post has not lived up to its legacy of 5 paragraph posts...

Haha

[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)