Re: [hlds_linux] Linux Distribution and Kernel
As a rhel fan I suggest Redhat MRG. http://www.redhat.com/mrg/ Of course 64bit (I'm assuming your have servers with at least 16gb of ram... so there's absolutely no doubt in choosing the 32/64bit version... 32bit PAE results in too much overhead) Il 30/08/2010 21:17, Alon Gubkin ha scritto: What linux distribution and kernel would you suggest for running source dedicated servers? Currently I use Ubuntu Server 10.04 x86 and 2.6.33.7-rt29. By the way, is there any reason to use Ubuntu Server 10.04 x64 instead of x86? As far as I know, srcds doesn't support 64-bit. ___ 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
Re: [hlds_linux] Linux Distribution and Kernel
Since you can tune and change every distro as you like (kernel/gcc/and so on), there is no point in arguing about distros. Just choose the one you like most and modify it to your needs. With 8+GB ram and supporting CPU choose the 64bit version. In other cases you are fine with 32bit too. Am 01.09.2010 14:12, schrieb Marco Padovan: As a rhel fan I suggest Redhat MRG. http://www.redhat.com/mrg/ Of course 64bit (I'm assuming your have servers with at least 16gb of ram... so there's absolutely no doubt in choosing the 32/64bit version... 32bit PAE results in too much overhead) Il 30/08/2010 21:17, Alon Gubkin ha scritto: What linux distribution and kernel would you suggest for running source dedicated servers? Currently I use Ubuntu Server 10.04 x86 and 2.6.33.7-rt29. By the way, is there any reason to use Ubuntu Server 10.04 x64 instead of x86? As far as I know, srcds doesn't support 64-bit. ___ 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
Re: [hlds_linux] Linux Distribution and Kernel
+1 On my Systems I go for the largest throughput and not highest/most stable fps. Without preemtion, RT and such nobody complained about the servers so far. Am 31.08.2010 07:56, schrieb Nephyrin Zey: +1 to Everything Gary said - RT kernels are generally a waste. They might ensure more accurate wakeups, but the sleep(1) call really limits how accurate those can be anyway even with hires timers, a ld_preload to mess with sleep() could get you much more accurate/efficient wakeups, but that's more involved and only really helps CPU usage when the server is not under load. Non-hi-res kernels tend to use a bit less CPU (though again, usually only under low loads) because they wake up less often and waste less time waking up and going back to sleep for the next tick. The expense of this would be slightly less accurate gameframe times, but on the order of1-2ms so its not really significant. The main thing I would worry about, then, is kernel version - newer kernels have a better CPU scheduler, and a lot of work has been done on this recently. Also keep in mind that FPS is largely bogus - a server pulling 10k FPS can be crapper than one pulling 100. The reasons behind this are complicated, but do yourself a favor and dont even look at FPS - join the server and throw up net_graph 4. If you're getting 66 updates per second (or whatever your tickrate is) and var: is pretty stable below 10-12ms or so, your server is essentially lag-free. The number of variables that go into effective lag is so complicated that anyone claiming to notice a difference of 2ms from kernel wakeup timings is full of it. You'll also find plenty of people who claim to know better, or have complex (and wrong, unsourced) explanations about why 1000FPS is good - which is why its that much more important to just use net_graph and sane judgement, and don't believe any of the voodoo unless you see real results - Neph ___ 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
Re: [hlds_linux] Linux Distribution and Kernel
In actual response to the original question, Ubuntu is fine, I find it a lot easier to use than a lot of other distributions. As for your question about x86 or x64, if your box can run the 64-bit version there really isn't much of a reason not to. On Tue, Aug 31, 2010 at 12:34 AM, Ulrich Block ulbl...@gmx.de wrote: +1 On my Systems I go for the largest throughput and not highest/most stable fps. Without preemtion, RT and such nobody complained about the servers so far. Am 31.08.2010 07:56, schrieb Nephyrin Zey: +1 to Everything Gary said - RT kernels are generally a waste. They might ensure more accurate wakeups, but the sleep(1) call really limits how accurate those can be anyway even with hires timers, a ld_preload to mess with sleep() could get you much more accurate/efficient wakeups, but that's more involved and only really helps CPU usage when the server is not under load. Non-hi-res kernels tend to use a bit less CPU (though again, usually only under low loads) because they wake up less often and waste less time waking up and going back to sleep for the next tick. The expense of this would be slightly less accurate gameframe times, but on the order of1-2ms so its not really significant. The main thing I would worry about, then, is kernel version - newer kernels have a better CPU scheduler, and a lot of work has been done on this recently. Also keep in mind that FPS is largely bogus - a server pulling 10k FPS can be crapper than one pulling 100. The reasons behind this are complicated, but do yourself a favor and dont even look at FPS - join the server and throw up net_graph 4. If you're getting 66 updates per second (or whatever your tickrate is) and var: is pretty stable below 10-12ms or so, your server is essentially lag-free. The number of variables that go into effective lag is so complicated that anyone claiming to notice a difference of 2ms from kernel wakeup timings is full of it. You'll also find plenty of people who claim to know better, or have complex (and wrong, unsourced) explanations about why 1000FPS is good - which is why its that much more important to just use net_graph and sane judgement, and don't believe any of the voodoo unless you see real results - Neph ___ 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
Re: [hlds_linux] Linux Distribution and Kernel
Okay guys, you convinced me - I will use the 2.6.35.4 kernel without any patches. I'm going to configure the kernel like so: - *General setup*: - *RCU Subsystem* *(ignore if not present)* - Enable *RCU Implementation (Preemptible RCU)* - Disable *Enable tracing for RCU* - *Processor type and features*: - Disable *Tickless System (Dynamic Ticks)* - Enable *High Resolution Timer Support* - Select your processor under *Processor family* - Change *Preemtion Mode* to *Complete Preemption (Real-Time)* - Enable *Enable priority boosting of RCU read-side critical sections* *(ignore if not present)* - Disable *Enable tracing for RCU - currently stats in debugfs* *(ignore if not present)* - Enable *Machine Check Exception* and select Intel or AMD depending on your CPU - Change *Timer frequency* to *1000 HZ* - *Power management and ACPI options* - Enable *Power Management support* - Disable *Power Management Debug Support* - Disable *Suspend to RAM and standby* - Disable *Hibernation (aka 'suspend to disk')* - Enable *ACPI (Advanced Configuration and Power Interface) Support* - Disable *CPU Frequency scaling* - Disable *CPU idle PM support* - *Networking support* - *Networking options* - Enable *Packet socket: mmapped IO* - Optionally disable *Network packet filtering framework (Netfilter)* (*Warning*: this will disable your firewall!) - Disable *QoS and/or fair queueing* (Unless you need and use it...) - *Device Drivers* - Disable *Watchdog Timer Support* - Enable *Real Time Clock* - Enable *PC-style 'CMOS'* - *Kernel hacking* - Disable everything Note that I changed *time frequency* to 1000 HZ and disabled *Tickless System (Dynamic Ticks)*. In the orginal articlehttp://wiki.fragaholics.de/index.php/EN:Linux_Kernel_Optimization it was 100HZ time frequency and tickless system enabled. 1. Do I really need to mess with the kernel default configuration for stable 1000fps kernel? 2. Should I use 100HZ and no tickless system instead of 1000HZ and tickless system enabled? 3. What would you suggest to do more? (For example to enable x, disable y, or dont do z) On Tue, Aug 31, 2010 at 11:46 AM, Craig H robolea...@gmail.com wrote: In actual response to the original question, Ubuntu is fine, I find it a lot easier to use than a lot of other distributions. As for your question about x86 or x64, if your box can run the 64-bit version there really isn't much of a reason not to. On Tue, Aug 31, 2010 at 12:34 AM, Ulrich Block ulbl...@gmx.de wrote: +1 On my Systems I go for the largest throughput and not highest/most stable fps. Without preemtion, RT and such nobody complained about the servers so far. Am 31.08.2010 07:56, schrieb Nephyrin Zey: +1 to Everything Gary said - RT kernels are generally a waste. They might ensure more accurate wakeups, but the sleep(1) call really limits how accurate those can be anyway even with hires timers, a ld_preload to mess with sleep() could get you much more accurate/efficient wakeups, but that's more involved and only really helps CPU usage when the server is not under load. Non-hi-res kernels tend to use a bit less CPU (though again, usually only under low loads) because they wake up less often and waste less time waking up and going back to sleep for the next tick. The expense of this would be slightly less accurate gameframe times, but on the order of1-2ms so its not really significant. The main thing I would worry about, then, is kernel version - newer kernels have a better CPU scheduler, and a lot of work has been done on this recently. Also keep in mind that FPS is largely bogus - a server pulling 10k FPS can be crapper than one pulling 100. The reasons behind this are complicated, but do yourself a favor and dont even look at FPS - join the server and throw up net_graph 4. If you're getting 66 updates per second (or whatever your tickrate is) and var: is pretty stable below 10-12ms or so, your server is essentially lag-free. The number of variables that go into effective lag is so complicated that anyone claiming to notice a difference of 2ms from kernel wakeup timings is full of it. You'll also find plenty of people who claim to know better, or have complex (and wrong, unsourced) explanations about why 1000FPS is good - which is why its that much more important to just use net_graph and sane judgement, and don't believe any of the voodoo unless you see real results - Neph ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To
Re: [hlds_linux] Linux Distribution and Kernel
On Tue, Aug 31, 2010 at 4:46 AM, Craig H robolea...@gmail.com wrote: In actual response to the original question, Ubuntu is fine, I find it a lot easier to use than a lot of other distributions. As for your question about x86 or x64, if your box can run the 64-bit version there really isn't much of a reason not to. There really isn't much of a reason to run x64 either. An x86 kernel with PAE can address all the RAM your motherboard can support anyways. Also, HLDS is only x86, so it's not going to take advantage of x64 anyways. On Tue, Aug 31, 2010 at 12:34 AM, Ulrich Block ulbl...@gmx.de wrote: +1 On my Systems I go for the largest throughput and not highest/most stable fps. Without preemtion, RT and such nobody complained about the servers so far. Am 31.08.2010 07:56, schrieb Nephyrin Zey: +1 to Everything Gary said - RT kernels are generally a waste. They might ensure more accurate wakeups, but the sleep(1) call really limits how accurate those can be anyway even with hires timers, a ld_preload to mess with sleep() could get you much more accurate/efficient wakeups, but that's more involved and only really helps CPU usage when the server is not under load. Non-hi-res kernels tend to use a bit less CPU (though again, usually only under low loads) because they wake up less often and waste less time waking up and going back to sleep for the next tick. The expense of this would be slightly less accurate gameframe times, but on the order of1-2ms so its not really significant. The main thing I would worry about, then, is kernel version - newer kernels have a better CPU scheduler, and a lot of work has been done on this recently. Also keep in mind that FPS is largely bogus - a server pulling 10k FPS can be crapper than one pulling 100. The reasons behind this are complicated, but do yourself a favor and dont even look at FPS - join the server and throw up net_graph 4. If you're getting 66 updates per second (or whatever your tickrate is) and var: is pretty stable below 10-12ms or so, your server is essentially lag-free. The number of variables that go into effective lag is so complicated that anyone claiming to notice a difference of 2ms from kernel wakeup timings is full of it. You'll also find plenty of people who claim to know better, or have complex (and wrong, unsourced) explanations about why 1000FPS is good - which is why its that much more important to just use net_graph and sane judgement, and don't believe any of the voodoo unless you see real results - Neph ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Linux Distribution and Kernel
Some people have suggested to myself to use a *Zen-Kernel* and base my compilation off of that. However, my system at the moment is broken so I haven't been able to test any new kernels. As for your settings, if you're looking for throughput (And what has already been stated). 100hz, Tickless, No Preemption is the way to go. PAE is moronic when it can be avoided, there is some unneeded performance loss. Cheers, Kyle. On Tue, Aug 31, 2010 at 4:36 AM, Alon Gubkin alon.gub...@gmail.com wrote: Okay guys, you convinced me - I will use the 2.6.35.4 kernel without any patches. I'm going to configure the kernel like so: - *General setup*: - *RCU Subsystem* *(ignore if not present)* - Enable *RCU Implementation (Preemptible RCU)* - Disable *Enable tracing for RCU* - *Processor type and features*: - Disable *Tickless System (Dynamic Ticks)* - Enable *High Resolution Timer Support* - Select your processor under *Processor family* - Change *Preemtion Mode* to *Complete Preemption (Real-Time)* - Enable *Enable priority boosting of RCU read-side critical sections* *(ignore if not present)* - Disable *Enable tracing for RCU - currently stats in debugfs* *(ignore if not present)* - Enable *Machine Check Exception* and select Intel or AMD depending on your CPU - Change *Timer frequency* to *1000 HZ* - *Power management and ACPI options* - Enable *Power Management support* - Disable *Power Management Debug Support* - Disable *Suspend to RAM and standby* - Disable *Hibernation (aka 'suspend to disk')* - Enable *ACPI (Advanced Configuration and Power Interface) Support* - Disable *CPU Frequency scaling* - Disable *CPU idle PM support* - *Networking support* - *Networking options* - Enable *Packet socket: mmapped IO* - Optionally disable *Network packet filtering framework (Netfilter)* (*Warning*: this will disable your firewall!) - Disable *QoS and/or fair queueing* (Unless you need and use it...) - *Device Drivers* - Disable *Watchdog Timer Support* - Enable *Real Time Clock* - Enable *PC-style 'CMOS'* - *Kernel hacking* - Disable everything Note that I changed *time frequency* to 1000 HZ and disabled *Tickless System (Dynamic Ticks)*. In the orginal articlehttp://wiki.fragaholics.de/index.php/EN:Linux_Kernel_Optimization it was 100HZ time frequency and tickless system enabled. 1. Do I really need to mess with the kernel default configuration for stable 1000fps kernel? 2. Should I use 100HZ and no tickless system instead of 1000HZ and tickless system enabled? 3. What would you suggest to do more? (For example to enable x, disable y, or dont do z) On Tue, Aug 31, 2010 at 11:46 AM, Craig H robolea...@gmail.com wrote: In actual response to the original question, Ubuntu is fine, I find it a lot easier to use than a lot of other distributions. As for your question about x86 or x64, if your box can run the 64-bit version there really isn't much of a reason not to. On Tue, Aug 31, 2010 at 12:34 AM, Ulrich Block ulbl...@gmx.de wrote: +1 On my Systems I go for the largest throughput and not highest/most stable fps. Without preemtion, RT and such nobody complained about the servers so far. Am 31.08.2010 07:56, schrieb Nephyrin Zey: +1 to Everything Gary said - RT kernels are generally a waste. They might ensure more accurate wakeups, but the sleep(1) call really limits how accurate those can be anyway even with hires timers, a ld_preload to mess with sleep() could get you much more accurate/efficient wakeups, but that's more involved and only really helps CPU usage when the server is not under load. Non-hi-res kernels tend to use a bit less CPU (though again, usually only under low loads) because they wake up less often and waste less time waking up and going back to sleep for the next tick. The expense of this would be slightly less accurate gameframe times, but on the order of1-2ms so its not really significant. The main thing I would worry about, then, is kernel version - newer kernels have a better CPU scheduler, and a lot of work has been done on this recently. Also keep in mind that FPS is largely bogus - a server pulling 10k FPS can be crapper than one pulling 100. The reasons behind this are complicated, but do yourself a favor and dont even look at FPS - join the server and throw up net_graph 4. If you're getting 66 updates per second (or whatever your tickrate is) and var: is pretty stable below 10-12ms or so, your server is essentially lag-free. The number of variables that go into effective lag is so complicated that anyone claiming to notice a difference of 2ms from kernel wakeup timings is full of it. You'll also find plenty of
Re: [hlds_linux] Linux Distribution and Kernel
On 31/08/2010 16:00, Ben Mendis wrote: On Tue, Aug 31, 2010 at 4:46 AM, Craig Hrobolea...@gmail.com wrote: In actual response to the original question, Ubuntu is fine, I find it a lot easier to use than a lot of other distributions. As for your question about x86 or x64, if your box can run the 64-bit version there really isn't much of a reason not to. There really isn't much of a reason to run x64 either. An x86 kernel with PAE can address all the RAM your motherboard can support anyways. Also, HLDS is only x86, so it's not going to take advantage of x64 anyways. PAE forces the kernel to jump through hoops to access memory, whereas x64 does not - this can waste valuable CPU cycles if you actually want to use the extra memory. While srcds is indeed 32-bit only, if you launch more than one instance of srcds then the kernel can easily fit the whole process memory spaces in the TLB without having to fiddle around with cache/TLB misses and flushes. I'd go do far as to recommend running an x64 kernel even if you desperately want a 32-bit userspace, there's no reason not to. Debian makes this particularly simple, and thus so does Ubuntu. I run 12+ instances of various source dedicated servers (L4D, L4D2 and TF2) on my server with a stock 64-bit Debian kernel, and it runs great. HTH, Chris ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Linux Distribution and Kernel
There are other supporting operations the server has to handle. Those applications may be 64bit and the performance boost of those applications may positively impact your scrds installs. I've yet to see a server running just a kernel and srcds. Most people will need networking, and drivers also ;) Allan -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Ben Mendis Sent: August-31-10 11:00 AM To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] Linux Distribution and Kernel On Tue, Aug 31, 2010 at 4:46 AM, Craig H robolea...@gmail.com wrote: In actual response to the original question, Ubuntu is fine, I find it a lot easier to use than a lot of other distributions. As for your question about x86 or x64, if your box can run the 64-bit version there really isn't much of a reason not to. There really isn't much of a reason to run x64 either. An x86 kernel with PAE can address all the RAM your motherboard can support anyways. Also, HLDS is only x86, so it's not going to take advantage of x64 anyways. On Tue, Aug 31, 2010 at 12:34 AM, Ulrich Block ulbl...@gmx.de wrote: +1 On my Systems I go for the largest throughput and not highest/most stable fps. Without preemtion, RT and such nobody complained about the servers so far. Am 31.08.2010 07:56, schrieb Nephyrin Zey: +1 to Everything Gary said - RT kernels are generally a waste. They might ensure more accurate wakeups, but the sleep(1) call really limits how accurate those can be anyway even with hires timers, a ld_preload to mess with sleep() could get you much more accurate/efficient wakeups, but that's more involved and only really helps CPU usage when the server is not under load. Non-hi-res kernels tend to use a bit less CPU (though again, usually only under low loads) because they wake up less often and waste less time waking up and going back to sleep for the next tick. The expense of this would be slightly less accurate gameframe times, but on the order of1-2ms so its not really significant. The main thing I would worry about, then, is kernel version - newer kernels have a better CPU scheduler, and a lot of work has been done on this recently. Also keep in mind that FPS is largely bogus - a server pulling 10k FPS can be crapper than one pulling 100. The reasons behind this are complicated, but do yourself a favor and dont even look at FPS - join the server and throw up net_graph 4. If you're getting 66 updates per second (or whatever your tickrate is) and var: is pretty stable below 10-12ms or so, your server is essentially lag-free. The number of variables that go into effective lag is so complicated that anyone claiming to notice a difference of 2ms from kernel wakeup timings is full of it. You'll also find plenty of people who claim to know better, or have complex (and wrong, unsourced) explanations about why 1000FPS is good - which is why its that much more important to just use net_graph and sane judgement, and don't believe any of the voodoo unless you see real results - Neph ___ 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 ___ 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
Re: [hlds_linux] Linux Distribution and Kernel
Exactly. This is why typically you will see better overall performance with a 64 bit operating system if your hardware supports it, even with 32 bit applications. Drek On 31/08/2010 2:52 PM, Allan Button wrote: There are other supporting operations the server has to handle. Those applications may be 64bit and the performance boost of those applications may positively impact your scrds installs. I've yet to see a server running just a kernel and srcds. Most people will need networking, and drivers also ;) Allan -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Ben Mendis Sent: August-31-10 11:00 AM To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] Linux Distribution and Kernel On Tue, Aug 31, 2010 at 4:46 AM, Craig Hrobolea...@gmail.com wrote: In actual response to the original question, Ubuntu is fine, I find it a lot easier to use than a lot of other distributions. As for your question about x86 or x64, if your box can run the 64-bit version there really isn't much of a reason not to. There really isn't much of a reason to run x64 either. An x86 kernel with PAE can address all the RAM your motherboard can support anyways. Also, HLDS is only x86, so it's not going to take advantage of x64 anyways. On Tue, Aug 31, 2010 at 12:34 AM, Ulrich Blockulbl...@gmx.de wrote: +1 On my Systems I go for the largest throughput and not highest/most stable fps. Without preemtion, RT and such nobody complained about the servers so far. Am 31.08.2010 07:56, schrieb Nephyrin Zey: +1 to Everything Gary said - RT kernels are generally a waste. They might ensure more accurate wakeups, but the sleep(1) call really limits how accurate those can be anyway even with hires timers, a ld_preload to mess with sleep() could get you much more accurate/efficient wakeups, but that's more involved and only really helps CPU usage when the server is not under load. Non-hi-res kernels tend to use a bit less CPU (though again, usually only under low loads) because they wake up less often and waste less time waking up and going back to sleep for the next tick. The expense of this would be slightly less accurate gameframe times, but on the order of1-2ms so its not really significant. The main thing I would worry about, then, is kernel version - newer kernels have a better CPU scheduler, and a lot of work has been done on this recently. Also keep in mind that FPS is largely bogus - a server pulling 10k FPS can be crapper than one pulling 100. The reasons behind this are complicated, but do yourself a favor and dont even look at FPS - join the server and throw up net_graph 4. If you're getting 66 updates per second (or whatever your tickrate is) and var: is pretty stable below 10-12ms or so, your server is essentially lag-free. The number of variables that go into effective lag is so complicated that anyone claiming to notice a difference of 2ms from kernel wakeup timings is full of it. You'll also find plenty of people who claim to know better, or have complex (and wrong, unsourced) explanations about why 1000FPS is good - which is why its that much more important to just use net_graph and sane judgement, and don't believe any of the voodoo unless you see real results - Neph ___ 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 ___ 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
Re: [hlds_linux] Linux Distribution and Kernel
At 07:36 AM 8/31/2010, Alon Gubkin wrote: Okay guys, you convinced me - I will use the 2.6.35.4 kernel without any patches. Note that I changed *time frequency* to 1000 HZ and disabled *Tickless System (Dynamic Ticks)*. In the orginal articlehttp://wiki.fragaholics.de/index.php/EN:Linux_Kernel_Optimization it was 100HZ time frequency and tickless system enabled. 1. Do I really need to mess with the kernel default configuration for stable 1000fps kernel? 2. Should I use 100HZ and no tickless system instead of 1000HZ and tickless system enabled? 3. What would you suggest to do more? (For example to enable x, disable y, or dont do z) Why do you need stable FPS? There is no evidence at all that stable FPS does anything at all. 100HZ may be better for large servers because HZ on newer kernels is tied to msleep() and using 100HZ may increase throughput slightly as msleep() doesn't use hrtimers, msleep() is used by a large amount of drivers and other things inside the kernel. The wiki you posted was written by a guy who has no idea how the engine works. He posts speculation without any technical proof (external monitoring) and assumes his results are better because FPS is tied into everything like ping calculation. It's no different than altering sv_fps on Quake/CoD games and watching your ping drop because of rounding errors or fixed math that isn't a multiple or divisible by the default number. I would be very careful on believing everything you read about gameserver stuff, only a handful of people have a clue about it's internals and most others that say otherwise just repeat nonsense that others have said over the years. G. Monk Stanley gary at summit-servers dot com | gary at DragonflyBSD dot org http://leaf.dragonflybsd.org/~gary ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Linux Distribution and Kernel
At 07:36 AM 8/31/2010, Alon Gubkin wrote: Okay guys, you convinced me - I will use the 2.6.35.4 kernel without any patches. Note that I changed *time frequency* to 1000 HZ and disabled *Tickless System (Dynamic Ticks)*. In the orginal articlehttp://wiki.fragaholics.de/index.php/EN:Linux_Kernel_Optimization it was 100HZ time frequency and tickless system enabled. 1. Do I really need to mess with the kernel default configuration for stable 1000fps kernel? 2. Should I use 100HZ and no tickless system instead of 1000HZ and tickless system enabled? 3. What would you suggest to do more? (For example to enable x, disable y, or dont do z) Why do you need stable FPS? There is no evidence at all that stable FPS does anything at all. 100HZ may be better for large servers because HZ on newer kernels is tied to msleep() and using 100HZ may increase throughput slightly as msleep() doesn't use hrtimers, msleep() is used by a large amount of drivers and other things inside the kernel. The wiki you posted was written by a guy who has no idea how the engine works. He posts speculation without any technical proof (external monitoring) and assumes his results are better because FPS is tied into everything like ping calculation. It's no different than altering sv_fps on Quake/CoD games and watching your ping drop because of rounding errors or fixed math that isn't a multiple or divisible by the default number. I would be very careful on believing everything you read about gameserver stuff, only a handful of people have a clue about it's internals and most others that say otherwise just repeat nonsense that others have said over the years. G. Monk Stanley gary at summit-servers dot com | gary at DragonflyBSD dot org http://leaf.dragonflybsd.org/~gary ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Linux Distribution and Kernel
1. Do I really need to mess with the kernel default configuration for stable 1000fps kernel? 2. Should I use 100HZ and no tickless system instead of 1000HZ and tickless system enabled? 3. What would you suggest to do more? (For example to enable x, disable y, or dont do z) Why do you need stable FPS? There is no evidence at all that stable FPS does anything at all. 100HZ may be better for large servers because HZ on newer kernels is tied to msleep() and using 100HZ may increase throughput slightly as msleep() doesn't use hrtimers, msleep() is used by a large amount of drivers and other things inside the kernel. The wiki you posted was written by a guy who has no idea how the engine works. He posts speculation without any technical proof (external monitoring) and assumes his results are better because FPS is tied into everything like ping calculation. It's no different than altering sv_fps on Quake/CoD games and watching your ping drop because of rounding errors or fixed math that isn't a multiple or divisible by the default number. I would be very careful on believing everything you read about gameserver stuff, only a handful of people have a clue about it's internals and most others that say otherwise just repeat nonsense that others have said over the years. G. Monk Stanley gary at summit-servers dot com | gary at DragonflyBSD dot org http://leaf.dragonflybsd.org/~gary Smack | | | V ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] Linux Distribution and Kernel
What linux distribution and kernel would you suggest for running source dedicated servers? Currently I use Ubuntu Server 10.04 x86 and 2.6.33.7-rt29. By the way, is there any reason to use Ubuntu Server 10.04 x64 instead of x86? As far as I know, srcds doesn't support 64-bit. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Linux Distribution and Kernel
At 03:17 PM 8/30/2010, Alon Gubkin wrote: What linux distribution and kernel would you suggest for running source dedicated servers? Currently I use Ubuntu Server 10.04 x86 and 2.6.33.7-rt29. By the way, is there any reason to use Ubuntu Server 10.04 x64 instead of x86? As far as I know, srcds doesn't support 64-bit. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux Running realtime kernels is a waste of time, in my opinion. RT kernels more or less throughput for latency, and there isn't any solid evidence that realtime kernels 'help' the game, except consume large amounts of CPU time. I am assuming you're running a realtime kernel for 'stable fps', but in reality there is no evidence that 'stable fps' helps. gary at summit-servers dot com | gary at DragonflyBSD dot org http://leaf.dragonflybsd.org/~gary ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Linux Distribution and Kernel
At 03:17 PM 8/30/2010, Alon Gubkin wrote: What linux distribution and kernel would you suggest for running source dedicated servers? Currently I use Ubuntu Server 10.04 x86 and 2.6.33.7-rt29. By the way, is there any reason to use Ubuntu Server 10.04 x64 instead of x86? As far as I know, srcds doesn't support 64-bit. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux Running realtime kernels is a waste of time, in my opinion. RT kernels more or less throughput for latency, and there isn't any solid evidence that realtime kernels 'help' the game, except consume large amounts of CPU time. I am assuming you're running a realtime kernel for 'stable fps', but in reality there is no evidence that 'stable fps' helps. gary at summit-servers dot com | gary at DragonflyBSD dot org http://leaf.dragonflybsd.org/~gary ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Linux Distribution and Kernel
+1 to Everything Gary said - RT kernels are generally a waste. They might ensure more accurate wakeups, but the sleep(1) call really limits how accurate those can be anyway even with hires timers, a ld_preload to mess with sleep() could get you much more accurate/efficient wakeups, but that's more involved and only really helps CPU usage when the server is not under load. Non-hi-res kernels tend to use a bit less CPU (though again, usually only under low loads) because they wake up less often and waste less time waking up and going back to sleep for the next tick. The expense of this would be slightly less accurate gameframe times, but on the order of 1-2ms so its not really significant. The main thing I would worry about, then, is kernel version - newer kernels have a better CPU scheduler, and a lot of work has been done on this recently. Also keep in mind that FPS is largely bogus - a server pulling 10k FPS can be crapper than one pulling 100. The reasons behind this are complicated, but do yourself a favor and dont even look at FPS - join the server and throw up net_graph 4. If you're getting 66 updates per second (or whatever your tickrate is) and var: is pretty stable below 10-12ms or so, your server is essentially lag-free. The number of variables that go into effective lag is so complicated that anyone claiming to notice a difference of 2ms from kernel wakeup timings is full of it. You'll also find plenty of people who claim to know better, or have complex (and wrong, unsourced) explanations about why 1000FPS is good - which is why its that much more important to just use net_graph and sane judgement, and don't believe any of the voodoo unless you see real results - Neph ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
