WoW Performance - Degrades over Time

[Nom]

Hi All,

I've posted for some suggestions in the WoW forums, but it's been suggested that I post here as well, as I'm more likely to get someone who has a clue

PROBLEM
======

After an extended play time in one area (~ 1 hour), or rapid travel between areas, the performance degrades substantially. It goes from 60+ FPS to about 5FPS and doesn't recover until I restart the game.

A restart brings an instant performance boost, even in the same area I just logged out. For instance, I was just in Icecrown (up in the air, looking at a large landscape), getting 5fps. I quit and relaunched, and am now getting 45fps. This seems to indicate it's not a graphics performance issue (ie. I don't have quality settings set too high).

It's not just the low framerate either, it's constantly stop-starting which basically adds up to making it near impossible to play.


HARDWARE/CONFIG
=============
CPU - AMD Phenom(tm) 9950 Quad-Core Processor (@2.6GHz)
Memory: 4GB
Video Card: GeForce 9800 GT

OS: Fedora 10
Wine Version: 1.1.14 (Fedora package)


OTHER NOTES
=========
I've noted that memory usage is sensible. Prior to writing this post, I just restarted a game which only had a resident size of 980mb. The OS had plenty of free memory.

I've adjusted just about every setting or tweak in the game to try and isolate the issue, including different timing mode settings which can be tweaked. Nothing has succeeded in resolving the issue.

The problem has persisted through multiple Wine versions, and seems to get no better or worse.


Thanks in advance for any help

[quad]

Can't say I really have any issues like this.

I did however notice some kind of memory leak introduced in a recent version of wine or WoW. Over say 4 hours, the WoW process eats up to about 1GB of RAM. That just continues with longer gameplay.

Even still, I don't experience any performance degredation.

I'd be suggesting checking the obvious... does glxgears performance suffer too when WoW performance suffers? If it does, it's your graphics card or associated drivers. Perhaps the fan's duty cycle is too low leading to gradually higher temps?

How about CPU usage? Mine is constantly at about 100% usage of one core (got 3). Does it decrease or increase for you?

[Addys]

Sounds like you're using an nVidia 17x driver. Upgrade to the 180.x branch if that's the case (most recent is 180.37) - if not, ignore this bit.

If you crash due to those memory problems, patch wine up with the preloader.c patch on here: http://bugs.winehq.org/show_bug.cgi?id=10778

[Nom]

If only it where that simple
OpenGL version string: 3.0.0 NVIDIA 180.29

I'm currently investigating the GPU temperature thing, but so far the temps seem no different than under Windows.

According to Nvidia's website, 180.29 is the latest (at least for x64 systems)

[John Drescher]

I'm currently investigating the GPU temperature thing, but so far the temps seem no different than under Windows.

Is it under 115C?


If so no need to worry. These GPUs can handle temps like this..
John

[Nom]

Well under.. like tops out at 75-80 degrees.

[loltsy]

After an extended play time in one area (~ 1 hour), or rapid travel between areas, the performance degrades substantially. It goes from 60+ FPS to about 5FPS and doesn't recover until I restart the game.

Sounds like the virtual memory exhaustion bug. Have a look at http://bugs.winehq.org/show_bug.cgi?id=13335

[Nom]

I've done a bit of testing today.

GPU temp seems unrelated, as the performance started to drop off with the GPU at only 65 degrees.

Memory usage, again, didn't even reach 1GB resident, so there doesn't *appear* to be a memory issue, but I'm happy to stand corrected.

This issue has persisted through at least 3 versions of Wine (1.1.7 - 1.1.9 - 1.1.14).

[Nom]

loltsy,

Thankyou for that link. I've just been having a read through, and it precisely describes the issue.

I know someone at work who is having no issues with WoW + Wine + Fedora, so I'll check whether he's running the 32-bit version tomorrow.

Additionally, i'll add the mem=4G kernel option and see if that helps tomorrow night as well.

[tparker]

On Wed, 2009-03-11 at 07:44 -0500, Nom wrote:

If only it where that simple
OpenGL version string: 3.0.0 NVIDIA 180.29

There are posts at NVidia's Linux forums about this as well, including
ones letting them know that the 180.x drivers did not fix the problem.
The posts don't make it clear if it is all caused by a driver problem or
if part of it could be in Wine as well, might be worth keeping on eye on
that forum as well as this one in case something useful gets posted.

I have the same problem in Fedora 10 (x86_64), turning my video settings
way down buys enough time for a raid before it gets too bad.

[Kalle Last]

I seem to be having somewhat similar issues lately. Unfortunately I haven't
been able to pin down the problem yet as lots of things changed. I went from
64 bit Kubuntu 8.-something, older NV drivers, wow 3.0.3 to 64bit Gentoo
with 180.-something NV drivers, latest Wine and wow patch 3.0.9.

Before the change I only had somewhat lowish performance on some of the
bossfights but was rockstable. After the change the game crashes almost
randomly, gets graphical glitches every now and then (usually soon followed
by crash), is awfully slow on nearly every bossfight and over time eats up
2GB of my 6G RAM. It shouldn't be the addons as I'm using the exact same
ones I used before, I haven't even updated them.


--
Kalle Last
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-us ... chment.htm>

[Nom]

Seems the very simple (one line) change has fixed the performance issues I was having, however it's also created a new one... crash after about 2 hours (out of memory)

I'm going to try recompiling with one of the other patches (there's one which has a huge chunk of files) and see how I go.

[tparker]

On Thu, 2009-03-12 at 11:34 +0200, Kalle Last wrote:

I seem to be having somewhat similar issues lately. Unfortunately I
haven't been able to pin down the problem yet as lots of things
changed. I went from 64 bit Kubuntu 8.-something, older NV drivers,
wow 3.0.3 to 64bit Gentoo with 180.-something NV drivers, latest Wine
and wow patch 3.0.9.

Mine seems to be finally becoming stable again, a couple things that
might be worth trying to see if they help on your system (no promises):

-go into WINE config, graphics tab and look for a box that says 'allow
pixel shader', be sure it is not checked. You may have to go back in and
reselect it if you have another game that uses it, but for some odd
reason my WoW runs better without that, even though I use opengl

-if you start the game from a desktop shortcut be sure that "-opengl"
without the quotes is at the end of the Command line, sometimes updates
take it out.

-for stability you might want to try limiting your system to 3G ram as
mentioned on the WINEappdb page, not a favorite work around but it does
help some people until a better solution is found.

-check your /ect/X11/xorg.conf, in the Files section for a line that
says either ModulePath "/usr/lib64/xorg/modules/extensions/fglrx"
or ModulePath "/usr/lib64/xorg/modules/extensions/nvidia". If yours
says nvidia at the end try commenting it out and putting in the line
ending with fglrx. When I upgraded to the 180.x drivers it changed that
line and I got graphics glitches until I changed it back to ending in
'fglrx'.

[Kalle Last]

2009/3/12 tparker <[email protected]>

On Thu, 2009-03-12 at 11:34 +0200, Kalle Last wrote:

I seem to be having somewhat similar issues lately. Unfortunately I
haven't been able to pin down the problem yet as lots of things
changed. I went from 64 bit Kubuntu 8.-something, older NV drivers,
wow 3.0.3 to 64bit Gentoo with 180.-something NV drivers, latest Wine
and wow patch 3.0.9.

Mine seems to be finally becoming stable again, a couple things that
might be worth trying to see if they help on your system (no promises):

-go into WINE config, graphics tab and look for a box that says 'allow
pixel shader', be sure it is not checked. You may have to go back in and
reselect it if you have another game that uses it, but for some odd
reason my WoW runs better without that, even though I use opengl

That's worth a try for sure

-if you start the game from a desktop shortcut be sure that "-opengl"
without the quotes is at the end of the Command line, sometimes updates
take it out.

I'm quite sure I had the option in my cfg.wtf file, it's again a good idea
to recheck it.

-for stability you might want to try limiting your system to 3G ram as
mentioned on the WINEappdb page, not a favorite work around but it does
help some people until a better solution is found.

That's kind of complicated as I need the RAM for other background tasks.

-check your /ect/X11/xorg.conf, in the Files section for a line that
says either ModulePath "/usr/lib64/xorg/modules/extensions/fglrx"
or ModulePath "/usr/lib64/xorg/modules/extensions/nvidia". If yours
says nvidia at the end try commenting it out and putting in the line
ending with fglrx. When I upgraded to the 180.x drivers it changed that
line and I got graphics glitches until I changed it back to ending in
'fglrx'.

That doesn't sound logical at all. fglrx is or ATI aka AMD video cards but I
have NV one. Could anyone explain why would such a change be needed?


I'll try those changes out in a few hours when I get home, I'll try to let
you know of my progress.



--
Kalle Last
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-us ... chment.htm>

[ds]

This problem isn't limited to WoW, I get the exact same symptoms described here (abrupt performance degradation, restart resets everything) in Civilization IV and Red Alert 2. With Civilization it happens after only about 10 minutes of play, while Red Alert 2 can run for over an hour.

If it's an issue with Nvidia drivers, a large range of them are affected as I'm using the 169 series

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 6800 GT/PCI/SSE2/3DNOW!
OpenGL version string: 2.1.2 NVIDIA 169.12

[Susan Cragin]

This problem isn't limited to WoW, I get the exact same symptoms described here (abrupt performance degradation, restart resets everything) in Civilization IV and Red Alert 2. With Civilization it happens after only about 10 minutes of play, while Red Alert 2 can run for over an hour.

If it's an issue with Nvidia drivers, a large range of them are affected as I'm using the 169 series

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 6800 GT/PCI/SSE2/3DNOW!
OpenGL version string: 2.1.2 NVIDIA 169.12

I'm wondering if the same problem makes Dragon NaturallySpeaking 10 Standard crash after exactly 12 minutes.

[Kalle Last]

So I tried at a few of those things that was suggested in last post:
Disabling pixel shaders didn't help with crashing
GL was set in wow conf file and forcing it from commandline didn't
help with crashing

I haven't tried limiting RAM and I didn't swap over to ATI extensions
as first one I can't do and second doesn't make any sense and
shouldn't even work properly. I did upgrade to latest NV drivers
aswell (180.37 I believe) but it made no difference, game still
crashed a few times. I haven't been able to test 25-man raids yet but
I'll probably do it tonight to see if slowdowns have gotten any
better.

--
Kalle Last

[Nom]

Looks like this patch fixes the problem:
http://bugs.winehq.org/attachment.cgi?id=19905

The trick is, you need to use the mem=4G option as well, otherwise your games (or at least WoW) will launch but be invisible.

[ds]

Just applying the patch did not fix the problem for me.

I'm a bit confused about the mem=4g part. Is this related to a problem particular to having 4 gb RAM or a more general problem? I have 1 gb RAM, would changing this option possibly help me, and if so, to what value?

[Rico]

Just applying the patch did not fix the problem for me.

I'm a bit confused about the mem=4g part. Is this related to a problem particular to having 4 gb RAM or a more general problem? I have 1 gb RAM, would changing this option possibly help me, and if so, to what value?

Probably 1GB ram is a little bit small and the kernel is swapping to disk which could get you a big performance hit.

According to posts on http://www.nvnews.net/vbulletin/showthread.php?t=127984 the mem=3G / 4G switch is only for 64Bit distributions and more than 3GB ram installed and with a geforce 8 or better and proprietary nvidia driver. Otherwise the switch seems to be useless for this problem.

It looks like the problem isn't present if (testers are welcome to verify this by trying the attached test case in the nvnews forum):
- there is a geforce 6 in the machine (haven't seen a log/comment with a geforce 7)
- there is a smaller amount of ram (less than 3GB)

Completely untested:
- 32Bit kernel with pae and more than 3GB ram, geforce 8+

[ds]

Nah, I've been playing the same game for years with the same specs, hard to believe it would suddenly be insufficient

Thanks for the info


Oh, and I'm using both a Geforce 6 and have less than 3gb RAM, so it's not that, unless my symptoms, while being identical to the ones described here, derive from some other issue altogether

[loltsy]

Completely untested:
- 32Bit kernel with pae and more than 3GB ram, geforce 8+

I've been playing around with this for the past week on a 4GB box with a 9600GT 512M, driver 180.29.

Looking at the virtual size of the process it starts around 2600M where with a 64bit system it started around 3600M. After flying around all over the world and running some instances it seems to float around the 3G mark. Well short of the 4G crash that takes about 30 seconds to get to on 64bit.

[Rico]

Looking at the virtual size of the process it starts around 2600M where with a 64bit system it started around 3600M. After flying around all over the world and running some instances it seems to float around the 3G mark. Well short of the 4G crash that takes about 30 seconds to get to on 64bit.

I tried that, too, with this result:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
l32 w32: 5793 ich 20 0 2598m 8556 6524 S 0.0 0.3 0:00.16 notepad
l32pae w32: 5760 ich 20 0 2598m 8564 6536 S 0.0 0.1 0:00.21 notepad
l64 w32: 4445 Ricola 20 0 3622m 9040 6544 S 0.0 0.1 0:00.13 notepad

This table shows the output of top after "rm -rf ~/.wine && wine notepad" on linux 32Bit, 32Bit+pae, 64Bit. The main difference is the VIRT memory. Why is it ~1GB higher on 64Bit systems than on 32Bit systems?

Completely untested:
- 32Bit kernel with pae and more than 3GB ram, geforce 8+

I checked that and it seems there isn't any memory leaked in this case.

[James Mckenzie]

Rico <[email protected]> wrote on March 27th:

loltsy wrote:

Looking at the virtual size of the process it starts around 2600M where with a 64bit system it started around 3600M. After flying around all over the world and running some instances it seems to float around the 3G mark. Well short of the 4G crash that takes about 30 seconds to get to on 64bit.

I tried that, too, with this result:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
l32 w32: 5793 ich 20 0 2598m 8556 6524 S 0.0 0.3 0:00.16 notepad
l32pae w32: 5760 ich 20 0 2598m 8564 6536 S 0.0 0.1 0:00.21 notepad
l64 w32: 4445 Ricola 20 0 3622m 9040 6544 S 0.0 0.1 0:00.13 notepad

This table shows the output of top after "rm -rf ~/.wine && wine notepad" on linux 32Bit, 32Bit+pae, 64Bit. The main difference is the VIRT memory. Why is it ~1GB higher on 64Bit systems than on 32Bit systems?

The results are quite interesting. It is possible there is unoptimized code in Wine 64 bit.

The question I have is this immediately after running the program or after a set time period, say ten minutes? If it is immediately, then my statement is basically correct and work needs to be done to optimize code for 64 bit. If it is after ten minutes, then there is a leak somewhere that is causing this and it should be investigated.

James McKenzie

[Rico]

The question I have is this immediately after running the program or after a set time period, say ten minutes? If it is immediately, then my statement is basically correct and work needs to be done to optimize code for 64 bit. If it is after ten minutes, then there is a leak somewhere that is causing this and it should be investigated.

This is immediately after the start (<1 min). Also I tried the wine 32bit version ("w32") on all 3 systems (it was exactly the same build).

It doesn't look like memory leak, because the numbers were constant over this time. But I could run it a little bit longer.