Several times noticed complaints new users linux on the responsiveness of games. They say that after a long game in windows, in Linux, strange system delays are immediately noticeable. An example is the delay between clicking on the shot button and the shot itself, for example, this is expressively manifested with the railgun in quakelive. Of course, the average reaction time of a player to an event (200-220 ms) is significantly greater than the gain from any tuning system, but if you can turn a few tens of milliseconds to your advantage, then why not do it? In general, windows users themselves, being carried away, are looking for ways to tune the system for a more enjoyable game. Plays a significant role and purely game tuning variables, but this is enough information in specialized forums, and once again it is not worth discussing.
The linux kernel, like the core of any other system, is the basis of the foundations, the root of all roots. The performance of any application directly depends on the performance of the kernel. In order to make the kernel more responsive, I did two simple operations. First, I changed the CONFIG_HZ
parameter. It reflects the frequency of the interrupt timer. The higher this value, the more frequent interruptions occur and the more responsive user applications become. Usually, its value in distributions is 250 or 300Hz. This is the average between the frequency recommended for the server (100Hz) and the highest frequency. In the vanilla core, which means in most distributive kernels, the maximum value that this parameter can take is 1000Hz. Of course, you can patch the core and get a more brutal line of its values. For example, a zen patchset
contains a patch that allows you to set this parameter to 10,000Hz! Honestly, I have not tried this value, since I have several server tasks running, and I also need some kind of stability. Feel free to build the
kernel with CONFIG_HZ_1000 = y
, it is responsive, it is stable, tested over the years. Well, or more, I just cannot comment on the stability and behavior of the system.
The second, as for a kernel - the scheduler. By default, CFS is used in vanilla and distribution kernels, this is the standard linux scheduler, it is stable, good, and does a good job. But it is not unique, there are patches that allow you to assign another scheduler - BFS
(Brain Fuck Scheduler), written by Kon Kolivas. I will not speak about the intricacies of his work, we are only interested in the fact that this scheduler also makes the system more responsive and “desktop”. Stability, I have to say, not so hot. It is better not to use it with the core of git or rc-cores, and wait for a stable release. On cuts, sometimes a short frieze of some keys or a short frieze of a picture can be observed during the game. Download the BFS patch
for your kernel and set CONFIG_SCHED_BFS = y
, this well improves responsiveness.
By the way, the BFS scheduler is also contained in the zen patchset, and there are zen kernels in many distributions.
Another useful kernel option is Preemption Model
. It can take three values: "No Forced Preemption (Server)", "Voluntary Kernel Preemption (Desktop)" and "Preemptible Kernel (Low-Latency Desktop)". The latter value includes a number of optimizations for using the kernel as a responsive desktop. We need it. Set CONFIG_PREEMPT = y
, this will help increase the responsiveness of desktop applications, including games.
Besides all this, there is a wonderful rt-patchset
aimed primarily at performing tasks in realtime. The rt kernel is also found in most distros, which is a big plus - you don’t need to patch anything. If you are used to binary kernels, just go to rt, this is a simple and good way to increase system responsiveness.
For many years, players with the experience of "disperse the mouse." In fact, the mouse itself does not give way to overclocking, but there are ways to make the system interrogate the state of the mouse more often. In windows there are special utilities for this, in Linux this is done at the driver level. To find out which driver is used for your mouse, look for information in the output of the ' dmesg | grep input
'. Most players have wired usb mice for which the usbhid
driver is used
, and this module has a special mousepoll option that determines the time when the mouse is polled. By default, it is 8 (ms), i.e. polling frequency is 125Hz. I use mousepoll = 2
and drive a mouse at 500Hz. Would make the period and less, but with mousepoll = 1, the frequency of the mouse still remains 500 Hz instead of the expected 1000 Hz. Why - I do not know, I am not a programmer and I can’t figure out the driver code. In order for the usbhid module to automatically load with the mousepoll = 2 option, you must explicitly specify this in the autoload parameters of the modules. Here you should read the documentation for your distribution, because In different distributions, different initialization systems can be used, and the rule for loading modules for one distra may simply not work in another.
But there is nothing difficult. I, for example, in the file /etc/modules.autoload.d/kernel-2.6 simply contain the line ' usbhid mousepoll = 2
'. You can have this file /etc/modprobe.d/hid.conf (created by hands if the directory exists) or /etc/modprobe.conf (outdated). Check the frequency of polling the mouse can be a small utility
. To run, you need to collect it (gcc evhz.c) and run a.out from root. Specially give the source code, run without fear.
Network quality is undoubtedly important. But the player can hardly affect its quality outside of its network card unless he uses the services of the provider where his friend works. And, I think, we should not say that it is better to prefer the wires, which also applies to the mouse. But to manage the queue of outgoing packets is even possible. Most games use UDP ports in a certain range to communicate with the server. The following few lines allow you to increase the priority of game packages over other pathetic packages:
tc qdisc del dev ppp0 root 2> /dev/null > /dev/null
tc qdisc del dev ppp0 ingress 2> /dev/null > /dev/null
# HTB , 15 -
tc qdisc add dev ppp0 root handle 1: htb default 15 r2q 10
# (rate) (ceil)
tc class add dev ppp0 parent 1: classid 1:1 htb rate 15mbit ceil 15mbit
# rate ceil 1:10, (0)
tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 10mbit ceil 15mbit prio 0
# rate ceil 1:15, (5)
tc class add dev ppp0 parent 1:1 classid 1:15 htb rate 5mbit ceil 15mbit prio 5
#, , , 1:10
tc filter add dev ppp0 parent 1:0 protocol ip prio 0 u32 match ip protocol 17 0xff flowid 1:10
I have all the udp in the highest priority, I didn’t specify ports for specific games, as it is useful for other protocols, such as dns. I hope you do not use uTP and do not drive on udp torrents. And if you are using, immediately disconnect and never turn it on. Gamers are asking.
values for your rate. Rate - the guaranteed bandwidth width for the queue, ceil - the maximum width, that is, when there are no packets in other queues, this queue is given a channel with a width greater than the rate, but never more than ceil. It is recommended to carefully select the rate for the queues 1:10 and 1:15, their sum should be equal to the rate of the parent class 1: 1. The ppp0 interface can be left unchanged if you use pppd to connect to the Internet, that is, if your provider distributes the Internet via PPPoE or PPTP. If you are a happy owner of a non-encapsulated Internet on ethernet, substitute the interface of the network card into the rules, most likely eth0.
These and other aspects of network configuration in Linux are described in more detail in the posh Linux
document Advanced Routing & Traffic Control HOWTO
I hope this guide will help even the most enthusiastic players to really love linux. Good luck in the games!