good things can't be posted often enough - its like having sex... ;) -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Kevin J. Anderson Gesendet: Montag, 16. Juni 2003 17:48 An: [EMAIL PROTECTED] Betreff: RE: [hlds_linux] Tuneup your hl server...
good info, but old news. ; ) ->-----Original Message----- ->From: [EMAIL PROTECTED] ->[mailto:[EMAIL PROTECTED] Behalf Of ->[EMAIL PROTECTED] ->Sent: Monday, June 16, 2003 11:41 AM ->To: [EMAIL PROTECTED] ->Subject: [hlds_linux] Tuneup your hl server... -> -> ->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 -> _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
