Quake Wars Performance Across Distros

[nonfatmatt]

I've been distro shopping lately so I've been able to benchmark ETQW across four different distributions, and they do have an impact on performance.

The System:
Core 2 Duo 2140 @ 2.66 Ghz
Nvidia Geforce 8800gs with the 173 series drivers.
3gb DDR 800

Not an ultra high end system, but enough to run the game for competition. Splash Damage recommends a 1000hz preemptible kernel, but I went with the stock kernels on all distributions and tested the difference in preemptible kernels on two.

Game was set exactly the same across distros as I moved my /home folder with me. Settings were 1280x1024 at low quality with all special effects turned off (my preference for competition). The timedemo used was during a heavy firefight indoors and outdoors.

The distributions: Ubuntu 8.04, Debian Sid, Arch Linux, and OpenSUSE 11.0. All distributions were run with 2.6.25 kernels.

Results with stock kernels:

Debian Sid: 74.2 FPS
Arch Linux: 71.4 FPS
Ubuntu 8.04: 65.8 FPS
OpenSUSE 11.0: 60.5 FPS

OpenSUSE takes a beating, but I think it's because of the services it automatically starts (Beagle, Pulseaudio). Also, none of the distributions were run with any desktop effects (compiz etc) and were run in entirely 2d mode. All distros used the full GNOME desktop.

Now, the interesting thing is that Splash Damage recommends high kernel hz and preemption, but Debian wins with a completely unpreemptible stock kernel at 100hz. I have, however, noticed a lot of jerkiness on Debian with the stock kernel, so having the preemption might help with that. I did have a chance to benchmark across kernels on Arch Linux and Debian.

Across Kernels:
Debian Stock: 74.2 FPS
Debian Custom Low Latency Desktop with 1000 Hz: 69.5 FPS
Debian Custom with Realtime Patches: 53.5 FPS

Notice the performance hit using the RT patches, you pay the price for that realtime responsiveness if you game on the same box, not that anyone would run RT on a gaming system, but since I do pro audio it's interesting.

Now for Arch Linux:
Arch Stock with Voluntary Preemption and 300hz: 71.4 FPS
Arch Custom with Full Preemption and 1000hz: 67.2 FPS

Again, increasing the hz decreases the FPS, but might make the game more responsive in terms of gameplay. Also, both the Debian and Arch stock kernels were compiled for i686 while the customs were compiled for Core 2 Duo, indicating that this difference might have an effect too.

So the conclusion I draw is that the distro you use can have as much as a 20% difference in performance. The greatest impact seems to come from background services, as Ubuntu and OpenSUSE took the biggest hit in performance, while the piecemeal distributions did a bit better (I tend to not install services I don't need). Also, choice in kernels may impact your gaming, while no preemption benchmarked the game the fastest, I noticed an increase in smoothness when played on a kernel with preemption and at least 300hz (in the case of Arch Linux, I couldn't tell the difference between 1000 and 300).

Also, it's important to say that the Windows client with the same hardware consistently benchmarked at 102 FPS in Windows XP, indicating a need for further optimization on the Linux side. I have heard that recompiling a special SDL for ETQW might help, but if you're really serious about performance or have a mid to lower spec system and want to play the game at a higher resolution installing XP might be the best bet.

[deanjo]

Pulse audio can severely hit your framerates. Also make sure it's not vsync holding back your fps. Another thing is to try the new nvidia 177.80 drivers as well. Beagle shouldn't hit your performance at all after the initial indexing as well but it's easily disable through the beagle applet. Background services should not be interfering that much (I run tonnes of services in the background with little performance hit at all, typically <2%) with your results but like I said things like pulse are known performance killers.

[nonfatmatt]

Pulse audio can severely hit your framerates. Also make sure it's not vsync holding back your fps. Another thing is to try the new nvidia 177.80 drivers as well. Beagle shouldn't hit your performance at all after the initial indexing as well but it's easily disable through the beagle applet. Background services should not be interfering that much (I run tonnes of services in the background with little performance hit at all, typically <2%) with your results but like I said things like pulse are known performance killers.

Vsync is off or I'd be hitting multiples of 60, plus it's disabled by default, and permanently disabled in timenetdemo. Also, I did run a benchmark with Ubuntu on the new drivers, and the difference is negligible, of course this may not cascade over all cases. This might have to do with the shift in support from G9x hardware to the newer stuff, and that most of Nvidia's bugs lately seem to be desktop based. Honestly I'm not interested in improving FPS on Linux, as I primarily play the game in Windows (40% is a big difference when you play competitively) and Splash Damage has indicated that they don't take the Linux client seriously, so there's not a lot of hope for further optimization that would make it competitively viable unless I dropped a whole lot of extra money on hardware.

[Kano]

Was EIST on or off?

[curaga]

Where's tickless?

[StringCheesian]

Where's tickless?

Seconded. Please consider testing an Arch or Debian custom with tickless enabled. It might be interesting.

[nonfatmatt]

Tickless should have no effect on actual game performance given what it does, but I tested it anyway:

Arch with 2.6.26 - Config 300hz and Nvidia Drivers 177.80

Stock Kernel: 70.3 FPS
With Tickless: 70.1 FPS

Also of note is that FPS is actually down by 1 with the new drivers.

[Kano]

Did you try disabling EIST? Because some distros might not enable powersaving or with differnent strategies.

[nonfatmatt]

EIST shouldn't have an effect. I run all of my distros with it enabled at the "on demand" setting. Also, the only two steps on my processor are 2 and 2.6 ghz, so you'd see a large performance hit if the game wasn't pegging the CPU.

[Kano]

Test it, then you will know it...

[xav1r]

Im wondering if other linux clients of commercial games like ut2k4 or even quake4 have this lack of optimization problem.

[nonfatmatt]

I would just like to update this because I got new hardware, and Quakewars is now multithreaded (at least the renderer).

The new Rig:

Asus 780G Board
Phenom II 710 @ 3GHZ
Radeon 4830 @ Stock - with my performance config the game is CPU bound

Results:

Linux:

84 FPS Single Thread
120 FPS Multithreaded

Windows XP SP3

105 FPS Single Threaded
153 FPS Multithreaded

Arch Linux Rolling Release w/ Custom Kernel - 2.6.28.9
Kernel Options:
Tickless
Voluntary Preemption
1000 HZ

I used the same demo as I used with the above benchmarks - if anyone wants it to compare message me.

The performace delta between Linux and Windows is still there, unfortunately, but QW is finally playable in Linux for me even though it drops to almost 50 FPS sometimes. The Windows client stays in a much smaller range. Also, I know Phoronix tested the threaded renderer a few months back and found it didn't make a difference, so clearly there's been an update or the threaded renderer just works better with more than 2 cores.

[Kano]

1000 hz is a bit extreme...

[tball]

Hmm. With the with the fglrx 9.4+ without compiz I get better performance than Vista. I guess Vista just sucks over linux and winXP :P

[L33F3R]

The performace delta between Linux and Windows is still there, unfortunately, but QW is finally playable in Linux for me, even though it drops to almost 50 FPS sometimes, wheras the Windows client stays in a much smaller range.

I get a good +40 FPS on ubuntu over windows XP, god forbid vista. This was at about patch 1.4 I think.

same settings
7950gt @default
q6600 @default
(at the time) 2GB ram

I recall it being faster for ubuntu on my old Athlon 64 3200+.

[nonfatmatt]

1000 hz is a bit extreme...

1000 HZ is recommended in the QW Readme. Also drivers are Catalyst 9.5. As to those of you who get more fps in Linux, I honestly don't know how that is possible at this point. I've tested this over four or five different hardware configurations with multiple kernels and it's always the same.

[tball]

1000 HZ is recommended in the QW Readme. Also drivers are Catalyst 9.5. As to those of you who get more fps in Linux, I honestly don't know how that is possible at this point. I've tested this over four or five different hardware configurations with multiple kernels and it's always the same.

I could run the test on Arch 64, if you like. I just moved to the distro, so I don't know the easiest way to downgrade my kernel to 2.6.28, so I can use fglrx. How did you do it?

[L33F3R]

1000 HZ is recommended in the QW Readme. Also drivers are Catalyst 9.5. As to those of you who get more fps in Linux, I honestly don't know how that is possible at this point. I've tested this over four or five different hardware configurations with multiple kernels and it's always the same.

I also get better fps in counterstrike through wine vs xp :D

[personman]

The Quake Wars demo runs pretty much like butt in linux on my PC. Frame rate seems decent overall, but it's very jerky. I've tried different driver versions, and different kernels compiled with different options. I would probably have purchased the game by now if it wasn't for this.

My PC is no world-beater by any means, but even when scaling the graphics down to ridiculously low settings, it's still jerky.

PC is an Athlon X2 5000+ with a GeForce 8800GTS 640 MB vid card, 4 GB ram.

Maybe it just needs more horsepower.

[energyman]

do yourself a favour and forget that 1000Hz ever existed. 300Hz is a much better choice.

[L33F3R]

do yourself a favour and forget that 1000Hz ever existed. 300Hz is a much better choice.

agreed. for most people 1k is overkill

[Dragonlord]

Why should we?

[energyman]

who are you asking and what?

[nonfatmatt]

do yourself a favour and forget that 1000Hz ever existed. 300Hz is a much better choice.

Yeah, I get that feeling too. I also do pro audio so having 1000hz compiled enables me to not have to boot into RT so it serves a dual purpose.

[nonfatmatt]

Also, if anyone wants the demo I used I put it up on Sendspace. http://www.sendspace.com/file/luf8wi

[energyman]

you could still try 300 ;) it has the advantage of being more fine grained than 100 and a lot less overhead than 1000.

[nonfatmatt]

you could still try 300 ;) it has the advantage of being more fine grained than 100 and a lot less overhead than 1000.

It makes a difference when you're working on an audio project that has 50 tracks going at the same time. On 1000hz I can get my latency down further than I could on 300. I can mix on 300 but not record. I also haven't seen that much of a negative impact considering I mostly just use my system for browsing and writing papers when I'm not doing audio work.

[Dragonlord]

who are you asking and what?
Why 1000 should be bad.

[energyman]

context switch overhead. Reduced IO performance. A lot of other stuff.

[nonfatmatt]

context switch overhead. Reduced IO performance. A lot of other stuff.

Look at my other benchmarks above, especially on the RT kernel which is essentially an extreme version of cranking up the HZ - albeit a really useful one. Basically the tradeoff is that you get a much more responsive system at the cost of throughput. For my specific case it's worthwhile but I'd imagine for 99% of desktop users voluntary preemption and 300 works great. I can't really tell the difference on a server kernel with no preemption at 100hz on a good multicore processor anyway.

[Dragonlord]

I could not really see any difference between the two on my systems here.