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 > article<http://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 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 > > >> > > >> > > > > > > _______________________________________________ > > > 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
