Linux kernel and game performance?
Hey folks, I've run into two web sites that claim that the Linux kernel causes performance problems in particular games (see below). Anybody know of others? And has anybody found concrete improvements in performance of a particular app (other than an audio workstation app) from using a realtime kernel? Thanks! - Dan First: http://wiki.archlinux.org/index.php/World_of_Warcraft#Kernel_Timing_Bug says in a section dated September 2008: "If you are having problems with choppy video every 15 seconds or so, it is related to the kernel scheduler... to fix, add CONFIG_SCHED_DEBUG=y to your kernel config, then set kernel.sched_features=21 kernel.sched_batch_wakeup_granularity_ns=25000000 kernel.sched_min_granularity_ns=4000000 in /etc/sysctl.cfg." Yikes. Any truth to that rumor? Second: http://hisouten.koumakan.jp/wiki/Linux_support#Resolved_bugs says "The game runs too slowly Symptoms: Instead of running at about 60-62fps, like the game is supposed to, it'll run closer to 53fps. This is not ideal. The bug: This is a Linux timing issue. The game runs a secondary timing thread with THREAD_PRIORITY_TIME_CRITICAL, where it simply sleeps for 16ms and sends events to the main thread to tell it that a new frame is needed. On Linux the necessary timing accuracy is not available, so it wavers between 16ms and 20ms. The fix: I hacked around this by setting the timer period to 14ms. This leads to a steady 62-63fps. Which is close enough for use, really. For a constant 60fps turn on vsync in your video drivers."
On 26/10/10 01:26, Dan Kegel wrote:
The game runs a secondary timing thread with THREAD_PRIORITY_TIME_CRITICAL, where it simply sleeps for 16ms and sends events to the main thread to tell it that a new frame is needed. On Linux the necessary timing accuracy is not available, so it wavers between 16ms and 20ms.
I thought TICKLESS did away with the timer resolution issues. Also, I'm not aware of any easy high frequency timers in Windows. Which API does it use? Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
On Tue, Oct 26, 2010 at 7:23 AM, Shachar Shemesh <shachar(a)shemesh.biz> wrote:
The game runs a secondary timing thread with THREAD_PRIORITY_TIME_CRITICAL, where it simply sleeps for 16ms and sends events to the main thread to tell it that a new frame is needed. On Linux the necessary timing accuracy is not available, so it wavers between 16ms and 20ms.
I thought TICKLESS did away with the timer resolution issues.
There might still be some, and there are lots of knobs to tweak on the kernel, perhaps default settings are not optimal.
Also, I'm not aware of any easy high frequency timers in Windows. Which API does it use?
I think he said Sleep().
On 26/10/10 14:09, Dan Kegel wrote:
On Tue, Oct 26, 2010 at 7:23 AM, Shachar Shemesh<shachar(a)shemesh.biz> wrote:
I thought TICKLESS did away with the timer resolution issues.
There might still be some, and there are lots of knobs to tweak on the kernel, perhaps default settings are not optimal.
More details would certainly be welcome.
Also, I'm not aware of any easy high frequency timers in Windows. Which API does it use?
I think he said Sleep().
My mistake. I was referring to sub-millisecond precision, which is irrelevant to this discussion. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Am 26.10.2010 um 01:26 schrieb Dan Kegel:
Hey folks, I've run into two web sites that claim that the Linux kernel causes performance problems in particular games (see below). Anybody know of others? UT 3 I think. It spends a lot of time in task switching, but I have no proof that it is indeed a kernel bug and not a wine bug or a red herring. Interestingly it only hits the unmodified game hard, games based on the engine(e.g. Mass Effect 2) seem to be less affected.
Don't get fooled by oprofile though. A high amount of time spent in vmlinux may be because of time spent in the driver module or oprofile itself.
And has anybody found concrete improvements in performance of a particular app (other than an audio workstation app) from using a realtime kernel? I wouldn't expect a realtime kernel to improve performance in general, since realtime constraints make achieving overall performance harder(e.g. limit the ability to cache writes). I haven't experimented with a realtime kernel though.
For the first reference, I have a WoW install. I haven't seen fps below 60 except in areas of the game where there are a lot of other players, but that was under OpenGL back before the latest patch. I haven't tried since Blizzard has disabled all high end settings in OpenGL mode for both Windows and Linux, and I've heard nothing but bad performance on D3D recently. I could give it a shot though. What is needed to make a kernel realtime other than adding CONFIG_SCHED_DEBUG and adding the sysctl settings? Thanks Tom On Mon, Oct 25, 2010 at 6:26 PM, Dan Kegel <dank(a)kegel.com> wrote:
Hey folks, I've run into two web sites that claim that the Linux kernel causes performance problems in particular games (see below). Anybody know of others?
And has anybody found concrete improvements in performance of a particular app (other than an audio workstation app) from using a realtime kernel?
Thanks! - Dan
First:
http://wiki.archlinux.org/index.php/World_of_Warcraft#Kernel_Timing_Bug says in a section dated September 2008: "If you are having problems with choppy video every 15 seconds or so, it is related to the kernel scheduler... to fix, add CONFIG_SCHED_DEBUG=y to your kernel config, then set kernel.sched_features=21 kernel.sched_batch_wakeup_granularity_ns=25000000 kernel.sched_min_granularity_ns=4000000 in /etc/sysctl.cfg."
Yikes. Any truth to that rumor?
Second:
http://hisouten.koumakan.jp/wiki/Linux_support#Resolved_bugs says
"The game runs too slowly Symptoms: Instead of running at about 60-62fps, like the game is supposed to, it'll run closer to 53fps. This is not ideal. The bug: This is a Linux timing issue. The game runs a secondary timing thread with THREAD_PRIORITY_TIME_CRITICAL, where it simply sleeps for 16ms and sends events to the main thread to tell it that a new frame is needed. On Linux the necessary timing accuracy is not available, so it wavers between 16ms and 20ms. The fix: I hacked around this by setting the timer period to 14ms. This leads to a steady 62-63fps. Which is close enough for use, really. For a constant 60fps turn on vsync in your video drivers."
participants (4)
-
Dan Kegel -
Shachar Shemesh -
Stefan Dösinger -
Tom Spear