At 06:07 PM 12/1/2009, Nephyrin Zey wrote: > I really dont want to get involved in this, but beware basically all >the advice you're receiving (including mine). There's tons of BS >regarding tickrate, RT kernels, fpsmeter.org, 'hit registration', and a >bunch of other useless nonsense by people who really just are echoing >what they read in that one old article about high FPS and what that one >wiki says about linux kernel configuration.
I agree. You do not need RT kernels at all.. they are for real time systems, since gameservers estimate everything anyways it's pointless to run a RT kernel on something that gives the best guess. The engine can only respond as fast as the users ping to and from the server, with socket latency etc.. >If I were you: >Setup a kernel with hi res timers and a 300hz interrupt, enable HPET if >your system doesn't have a stable TSC. Bind each srcds instance to a >core. Set it to sched_fifo (sudo chrt -f -p 98 <pid>). Set fps_max to 0. >Use host_profile 1 to watch effective FPS. Fill server. Play with other >tweaks and compare them to your test case. Just because someone says >that X or Y will make your server better dont believe it until you see >it. net_graph 4 is the best measure of how well your server is doing. If >its a solid graph with no gaps, getting 66/s updates, and low var, I >would say its near perfect. Others might whine. Decide for yourself. SCHED_RR gives the same latency as SCHED_FIFO, in my tests. Under load, this will be different, though. (send me a message and i'll send you some code) >Miscellaneous nonsense: >- On a system with hi res timers and TSC/HPET, sleep() will return >independent of the interrupt timer, enabling 1000FPS to be hit >regardless of system ticrate. In this case, a 1000hz interrupt timer >will not have any effect, and possibly a negative one. AFAIK select()/poll() on older kernels do not use hrtimers at all. Only nanosleep()/usleep() do. You don't need 1000hz anyways as that can cause cacheline pingpongs etc (Hurt NUMA performance) >- On linux/tf2, the stats command calculates fps in a very useless >manner. A single slow frame will make it show '40fps', while the >engine's own internal counter (what you see in the green banner in those >windows srcds windows) as well as host_profile disagree. >- fpsmeter.org uses the stats command. >- I've talked to and worked with many people and never seen a linux TF2 >server above 20 slots get 'stable' FPS, much less according to fpsmeter. >I've seen many TF2 linux servers that perform very well and lag free. >- RT kernels chug CPU like no tomorrow for very little benefit, vs FIFO >scheduling and hi-res timers. >- If your var is <10ms and your updaterate is stable 66, to hell with >anyone whining about FPS (flamewar lol). Its worth noting that windows >servers are tuned to run at 66fps originally. By valve. The 'booster' >came later. >- My linux TF2 servers are among the best stability in updaterate and >var i've seen anywhere, yet many people have 'more stable FPS' than me. >See previous point. >- SourceTV is a massive buggy resource hog. >- Anyone that brings up 'hit registration' probably doesn't know wtf >they're talking about and read some old article about it with >questionable logic. As long as you run Low Latency in the kernel with little interrupt behavior, and without CPUspeed/ACPI Processor you should be okay. Realtime kernels chug too much cpu because the scheduler has more overhead etc etc - _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
