Posts: 2,031
Threads: 27
Joined: Nov 2008
Reputation:
17
some time ago I did some double blind test regarding the influence of fps on the gameplay. actually it wasn't an intentional test. I installed an hlds server in parallel on the same machine and the srcds fps got instable everytime there were players on the hlds server (btw. that was the birth of the fps-meter ;-)). that test has proven that in those times (it was before the orangebox update of course) the fps had a strong influence on the game play even if they constantly stayed above the tick rate.
btw: you do not need different OSses, data centers, hardware machines etc. for this test. on the contrary, if you want to study the influence of the fps you must not change any other condition, else the test is completely worthless.
so (if this fact hasn't changed by the orangebox update, which I cannot tell at the moment) constantly high fps are one condition to be fulfilled for a good server quality. BUT, "high" does not mean as high as possible. in particular it is not the fps number that is important. important is the time between two frames. at 100 fps this time is 10 ms, at 1000 fps it is only 1 ms. this means that the difference between 100 fps and 1000 fps is 10 times larger than the difference between 1000 fps and infinite fps! this means, anything beyond 1000 fps is only to impress people for sure. that single millisecond is below many other factors (like ping variations) that limit the precision of the engine, so it really doesn't matter.
regarding the orangebox update, I am no longer sure if there is actually any difference if the fps are higher than the tickrate. before the orangebox update the overall round trip time ("ping") displayed by "rcon status" (and only by that particular command - all other methods display only some parts of the round trip time) increased when lowering the fps right as one would expect it, if the engine only receives network packets at the beginning of the frame. this causes an additional, random time added to the ping, e.g. between 0ms and 10ms for 100fps, i.e. 5ms on average. for 1000fps this is only 0.5ms on average. with the orangebox update this effect is gone. this might indicate that the engine always reads the packets right when they arrive (i.e. using a separate thread). but this might also mean that they only changed what the "rcon status" command prints out...
maybe someone has an idea how to find out if srcds uses a separate thread to receive the network packets? still I think I will repeat this double blind test one day, when I have time for this. there could still be some "high order" effect influencing the game play even if srcds uses a network thread... (remember that valve even neglected the influence for the old pre-OB engine, probably because in theory there should not have been any influence)
I hope this was not too technical ;-) and I hope this will not start a flame war again. I am only interested in the truth...
Posts: 504
Threads: 9
Joined: Oct 2009
Reputation:
3
As you have written the gameplay got worse when you mixed HL1 and HL2. Are you 100% sure it was because of less stable fps?
It also possible that the mixture is/was the problem and a less stable fps measurement is only a side effekt. I am asking that because I had complains when I mixed HL1/HL2. With my setup on both servertypes the "stats" fps were stable at +-10fps even if on both where players. From the stats/fps raw data both servertypes should have been fine. But they were not.
Some time ago I made a test with dods (orangebox) and changed the fps_max values to see if there is an impact on the ping. The result was: I could not see a difference. If there was one, the fluctuation of my latence was larger than the improvement and making it impossible to see the improvements.
Also I havent had any complains on servers when I let the fps less stable at 400-490 or 200-300. There were only HL2 based server running. When I did that for testing porouse I told the people they were playing on 1000 fps 100% stable servers (even when it was 200-300) and only got compliments about the servers.
Other things I noticed:
Even if the "stats" command shows me a fluctuation from 200-300 or 700-970 the fps shown with host_profile are stable.
If you use SourceTV "stats" is telling you your serverfps is going up and down. Still host_profile ist stable (but 20-30fps lower)
With the bumpy "stats" fps and STV on still no complains and only compliments.
Later I changed the setup and got 970-980fps. I told the people that I made some changes like less fps to increase the troughput to run more servers/slots on the host (even if I did the opposite).
Very fast I got complains like we need more FPS from the people I told the lie. People that weren`t told still sayed good servers.
So I told the people that I switched back to the old setup even if I did not. Soon they were like "The server is now great again!"
One week later I really switched back to not 99%-100% stable setup cause I needed to increase the throughput to run very large servers. Nobody noticed the change.
Posts: 2,031
Threads: 27
Joined: Nov 2008
Reputation:
17
as I said: for orangbox servers I have reason to believe this behavior has changed (though not a proof yet).
apart from that, I am very sure that there are only two things that influence the server quality on software side: fps and settings. (Let's forget about settings, as they are easy to make them right.)
This is for the simple reason that there is no "magic" in the system. During a frame the server is receiving network packets (at least before orangebox), calculating the world update, and sending updates to the clients. The calculations itself are in no way affected by anything outside of the game server. Unless you have some really mad bug in the kernel or so, receiving and sending packets isn't affected as well (apart from microsecond delays or so -> we can safely forget that). So the only thing that remains is the time when the server renders a frame.
I don't know what host_profile exactly does, but stats prints the inverse of the time elapsed between the beginning of two consecutive frames. I verified that using a preload-lib. As this is exactly what I want to know, I rely on stats and nothing else. Better would be probably a preload-lib that does the measurement, and actually I am thinking of building one that works in conjunction with the fps meter.
But this might really be all wasted effort, if the orangebox engine uses a network thread... :-) at the very least this would reduce the influence of the fps very strongly (as long as the fps are at least the tickrate of course).
Posts: 504
Threads: 9
Joined: Oct 2009
Reputation:
3
And as I said on my orangebox server (DODS) nobody was able to feel out of the gameplay how much fps were set up as long as they are above tickrate ofc.
Since nobody can feel a difference my conclusion going for high and as stable as possible fps with orangebox servers is just a waste of time.
Posts: 2,031
Threads: 27
Joined: Nov 2008
Reputation:
17
I did not contradict that :-)
Posts: 104
Threads: 2
Joined: Jun 2011
Reputation:
1
If you search google for the HL2 source code leak of 2004 and read up on how the frame rate and the tick rate works you'll see almost all of the researched data by people is true. But check the thread at viewtopic/15263 to get more than 1000 FPS. Scroll down to the bottom and read my comment.
Posts: 2,031
Threads: 27
Joined: Nov 2008
Reputation:
17
please don't raise old threads with this crap. since the orangebox engine fps higher then 200~300 or so are a waste of resources in any case. in fact running with fps = tickrate is optimal.
