Hi, i just found this document and i think EVERY admin should know about it. i followed this tutorial - and my servers ping decreased about 10ms - gameplay is the best i ever played on any server - no lags and very very smooth gameplay... i also tested the kernel patch thing - but with the patched kernel the hltv proxy (3.1.1.1c1) did no more start ;) anyway i switched back to hl 3.1.1.0...
here is the article: Zibbo explains HL server and latencies Date: Söndag, maj 25 @ 14:29:30 Topic Gaming There seems to be a lot of confusion about latency issues in a HL server. What exactly those pingboost options do, and when and why to use them. I'm the author of the original UDP Soft pingbooster, so I know a thing or two about this issue. I'm sure I will be repeating a lot of info for many of you, but I decided to write it all down once and for all. All of the recommendations I give here are of course just my opinions, but I like to think myself as being well informed about these things. First, what is wrong with a normal way a Half-Life server does things. HL server normally tries to work like this: sleep for 1ms while (it's not yet time for the next frame) sleep for 1ms receive and handle all incoming packets send updates to clients if updaterate and rate settings allow it repeat forever So basically a HL server always sleeps at least 1ms between every frame, and more if enough time has not passed (determined by sys_ticrate) since starting of the previous frame. This is supposed to keep a server frame rate exactly at sys_ticrate. The problem with this approach is the fact that you can't sleep for a 1ms in a normal Linux system. Trying to sleep for any amount of time takes at least 10ms or more. This is due to a scheduling frequency of the Linux kernel, which is normally 100Hz (for a slightly longer explanation check out the manual page of the nanosleep). So the way a HL server actually works, looks something like this: sleep for 10-20ms while (it's not yet time for the next frame) sleep for 10-20ms receive and handle all incoming packets send updates to clients if updaterate and rate settings allow it repeat forever This causes some serious latency, because a hl server is sleeping, while incoming packets from clients are stacking up and waiting to be handled. With this system, it's basically impossible to get more than 50fps out of a HL server, no matter how fast hardware you have running it. Now, what my pingbooster software, and all those -pingboost options do, is try to change the way the server behaves between frames, when it normally tries to do that "1ms sleep loop". I thought that if the server has some work to be done (incoming packets from clients), it should immediately start doing that work, and not sleep. So in my pingbooster I replaced the sleep call the HL server was using with a select call, which listens the network connection, and waits until there is incoming packets. I also set sys_ticrate to some crazy number like 10000, so a HL server would always think that it's time for the next frame. I also set sv_maxupdaterate to 100 from 60, because I like getting fresh updates for every frame in my client :) So a HL server loop was changed to: wait until there is incoming packets from clients receive and handle all incoming packets send updates to clients if updaterate and rate settings allow it repeat forever This turned out to be very effective in reducing internal latencies in a HL server. And replacing the sleep call with waiting for client packets is also exactly what -pingboost 3 option does. So if anyone is still using my pingbooster, you can get the same performance by using -pingboost 3, and setting sys_ticrate to some extremely high number (like 10000), and sv_maxupdaterate to 100. With that kind of settings, your server never waits when it has some work to do. So if you get a 99% cpu usage, it just means there is something to do all the time, and the server is as responsive as it can be with your hardware. I haven't checked lately what pingboost 1 and 2 options do, but at least a few months ago they just used different system calls to try to sleep that 1ms (and failing IIRC), and I wouldn't recommend using those options. Correct me if I'm wrong. There is also a way to "fix" Linux to work better with a default HL server configuration. You can increase the scheduling frequency of the Linux kernel by editing a file in the Linux kernel source, and recompiling it. The file is include/asm-i386/param.h, and you have to change the line "#define HZ 100" to "#define HZ 1000". I've been told that this is actually a default in 2.5 series of kernels. This should cause a HL server to behave more or less exactly as it was originally designed. However, I personally happen to disagree with that design, and recommend using -pingboost 3 option regardless :) At least with "one server/cpu" systems. When you want to run a quality server (and when I say a quality server, I don't mean a kind of crap that 99% of the hl servers out there are), number one priority for you should be getting it running at over 100fps consistently. No one cares if it runs 400fps, when there is no activity, and everyone is camping. It has to stay over 100fps when all shit hits the fan. When it really matters. Client input should be handled as quickly as possible, and the only way to do that is having a high frame rate on the server. Almost all of the cpu time HL server uses is caused by handling of incoming packets, and generating updates for clients. So a lot depends on what kind of settings your clients are using. If all your players are just average newbies with default cl_updaterate 20 and cl_cmdrate 30, you can get away with a fairly large number of maxclients on a relatively slow hardware. And they are not likely to recognize a good server if it bit them in the ass anyway :) On the other hand, if you have mostly more experienced players with fat pipes, and using settings like cl_updaterate 101 and cl_cmdrate 101, you have to have a significantly more powerful server to have it running at 100fps. Tips for increasing your server performance: 1. Use -pingboost 3 +sys_ticrate 10000 +sv_maxupdaterate 100 2. If you have more than 1 server/cpu, drop all except 1. 3. Decrease maxclients 4. Decrease amount of metamod mods, or remove metamod completely. They truly use up incredible amounts of cpu if you consider how little processing power all the features in those mods should require. Someone should really look into this.. 5. Decrease sv_maxupdaterate. For reference on what kind of a hardware you might need, I've been testing with a 1ghz amd processor, and without metamod I can run a 14 player server (with clients with fast connections) without any significant slowdown. With a metamod+some small mods that number goes down to about 10. Almost all of the information I have about the internal workings of a HL server, I got from using a very simple debugging utility called strace, and I recommend anyone with any interest in learning more about what makes these programs tick, to check it out. For example, performance differences between 3.1.1.0 and 3.1.1.1 versions are clearly visible by comparing strace outputs of different versions. It seems that in 3.1.1.1 version, generating an update for a client can take up to 3 times longer than it does in 3.1.1.0 version, and that's what causing it to perform so badly. Also, I would recommend Valve to test using sched_yield() call instead of usleep(), for purposes of releasing a cpu for other applications. - Zibbo This article comes from clanding.org | Home of clan [DING] http://www.clanding.org/ The URL for this story is: http://www.clanding.org/modules.php?op=modload&name=News&file=article&si d=6 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
