These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Linux

 
  • Topic is locked indefinitely.
 

Performance Tweaking Tips
Author
Previous Topic Next Topic
Whitehound
#1 - 2012-03-22 12:03:56 UTC  |  Edited by: Whitehound
Hello,

I saw people mentioning the use of the command taskset 1 to avoid load balancing issues. Using the CPU governor "performance" will probably work for some, too. The default for me is "ondemand" and I like using it to save power and so I tweaked its settings.

In the file "/etc/default/cpufrequtils" I wrote:

# increase CPU speed at 50% load
echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
# decrease CPU speed delayed
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

The default behaviour of the "ondemand" governor is to speed up a core only after it reaches 95% load. The command cpufreq-info shows a statistic of how often each core gets a boost.

If you are not concerned by the CO2 footprint of your spaceships and you want to disable the "ondemand" governor altogether then you can do this with (i.e. a 4 core CPU):

for i in 0 1 2 3; do cpufreq-set -c $i -g performance; done


To improve the network speed and to reduce the latency did I set some kernel parameter in "/etc/sysctl.conf":

# TCP/IP network performance tuning:
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 3932160 62914560
net.ipv4.tcp_wmem = 4096 196608 3145728
net.ipv4.tcp_mtu_probing = 1
net.ipv4.tcp_timestamps = 0

The default buffer sizes for TCP/IP are very small. Increasing them optimizes the maximum throughput. Enabling MTU probing can help with problems on ADSL and WiFi connections and lets the kernel discover the best MTU size (MTU = Maximum Transfer Unit). Disabling the time stamps on network packages saves 4 bytes on every outgoing package. Turning them off will not hurt as these are usually only useful for network trouble shooting.


What are the things you have done to tweak the performance of EVE when run under WINE?

Loss is meaningful. Therefore is the loss of meaning likewise meaningful. It is the source of all trolling.
Whitehound
#2 - 2012-03-29 06:33:53 UTC
Setting the environment variable $WINEDEBUG to -all turns off all debugging messages.

export WINEDEBUG=-all

My WINE kept reporting an unhandled Direct3D flag several times per second and had filled up ~/.xsession-errors to the size of several tens of megabytes. A small thing to do, but quite effective when not trouble shooting WINE.

Loss is meaningful. Therefore is the loss of meaning likewise meaningful. It is the source of all trolling.
Whitehound
#3 - 2012-03-29 09:05:53 UTC  |  Edited by: Whitehound
For those who compile WINE themselves, know that it can be compiled with gcc's Link Time Optimization pass (LTO). This allows for deep optimizations of the code. The configure script of WINE does not allow this, but one can work around it by compiling WINE in two steps. In the first step does one need to compile the source in the usual way. In the second step does one need to delete all the .dll.so-files and recreate them with a second make run. This is an example:

export CC="gcc -m32" CFLAGS="-pipe -O2 -march=native -flto"
configure
make
find dlls -name \*.dll.so -print0 | xargs -0 rm
make TARGETFLAGS="-m32 $CFLAGS -fipa-pta -flto-partition=none -fuse-linker-plugin"
make install

(The second make run will raise an error message, but it can be ignored.)

What does LTO do? With LTO enabled will gcc add the source code to each object file it creates. When it calls the linker to create executables and libraries will it read the source code again, this time from the object files, and optimizes the code as one large file. The advantage for WINE here is that each of its DLLs, which consist of multiple source files, receive a better optimization.

For LTO to work does one need gcc-4.6.2 or .3 and binutils 2.22.51 or .52. Some of the packages required for WINE like freetype, tiff, png, mpg123 and zlib can be compiled with the LTO pass, too.

Loss is meaningful. Therefore is the loss of meaning likewise meaningful. It is the source of all trolling.
Whitehound
#4 - 2012-03-29 09:22:19 UTC  |  Edited by: Whitehound
Using a window environment like Xfce or LXDE over GNOME and KDE can improve the speed of EVE on WINE, too. It is because of the window managers using some resources of the graphics card (3D composition, transparency, overlays, etc.) that causes a loss in performance. More light-weight environments like Xfce and LXDE keep the resource requirements to a minimum, which leaves more to the 3D applications and as a result does EVE run faster.

As an alternative to changing the desktop environment can one start a second X server, too. This allows to run the client exclusively on a single display without any interference from a window manager. It can be combined with a real-time scheduler to maximize CPU utilisation. An example, run as root and in one command line where me stands for the user ID to run WINE under:

xinit /usr/bin/chrt -f 1 su -l me -c 'env WINEPREFIX="/home/me/.eve" WINEDEBUG="-all" WINEDLLOVERRIDES="msvcr80,msvcr90,msvcr100=b,n" wine explorer "/desktop=EVE,1680x1050" "/home/me/.eve/drive_c/Program Files/CCP/EVE/bin/ExeFile.exe"' -- /usr/bin/Xorg :1 -nolisten tcp

The EVE client will then be running on a different virtual terminal and one can switch between the two X servers with i.e. CTRL-ALT F7 or F8.

Loss is meaningful. Therefore is the loss of meaning likewise meaningful. It is the source of all trolling.
Bent Barrel
#5 - 2012-03-30 07:33:26 UTC
hmm ... interesting ... have to give the first 2 a look .... but wine is already taxing a CPU and EVE is special in that it is not multithreaded ... so de ondemand governor should do fine at default ....
Whitehound
#6 - 2012-03-30 08:49:05 UTC  |  Edited by: Whitehound
Bent Barrel wrote:
hmm ... interesting ... have to give the first 2 a look .... but wine is already taxing a CPU and EVE is special in that it is not multithreaded ... so de ondemand governor should do fine at default ....

My EVE client uses 22 threads and I get a CPU load on all cores. If you do not see it then check with:

ps -eLf | fgrep ExeFile.exe

if your client is using multi-threading. If not then your WINE may be missing support for it.

Your graphics driver may be using multi-threading, too. My frame rate in EVE goes up by about 5 fp/s.

Other software, like ffmpeg, which is a video encoding tool and very CPU demanding, improves by 68%!! (a 5 min test video encodes in 28.2s with default settings and 16.7s with tweaked settings). It is not only useful for EVE.

Loss is meaningful. Therefore is the loss of meaning likewise meaningful. It is the source of all trolling.
After Shok
Ruthenia Co
#7 - 2012-03-31 11:19:06 UTC
REGEDIT4

[HKEY_CURRENT_USER\Software\Wine\Direct3D]
"DirectDrawRenderer"="opengl"
"MaxFragmentUniforms"="1024"
"MaxVaryings"="52"
"MaxVertexUniforms"="1024"
"Multisampling"="enabled"
"OffscreenRenderingMode"="fbo"
"PixelShaderMode"="enabled"
"UseGLSL"="enabled"
"VertexShaderMode"="hardware"
"VideoMemorySize"="512"


I have r6900 with 2gb ram .I have low fps without this settings.
I use "VideoMemorySize" = "2048" for single client and
"VideoMemorySize" = "512" for 2 and more clients.

Правдой нельзя оскорбить, уважаемый адвокат!

Тот самый Мюнхгаузен

Золотая орка
Bent Barrel
#8 - 2012-03-31 19:48:18 UTC  |  Edited by: Bent Barrel
Whitehound wrote:
Bent Barrel wrote:
hmm ... interesting ... have to give the first 2 a look .... but wine is already taxing a CPU and EVE is special in that it is not multithreaded ... so de ondemand governor should do fine at default ....

My EVE client uses 22 threads and I get a CPU load on all cores. If you do not see it then check with:

ps -eLf | fgrep ExeFile.exe

if your client is using multi-threading. If not then your WINE may be missing support for it.

Your graphics driver may be using multi-threading, too. My frame rate in EVE goes up by about 5 fp/s.

Other software, like ffmpeg, which is a video encoding tool and very CPU demanding, improves by 68%!! (a 5 min test video encodes in 28.2s with default settings and 16.7s with tweaked settings). It is not only useful for EVE.


I do get 15 threads ... anyway the best for me was to turn off all wine debug messages ....

EDIT: turns out you were spot on with the performance governor, thank you
Bent Barrel
#9 - 2012-04-02 18:50:56 UTC  |  Edited by: Bent Barrel
turns out we are both correct ... there are more threads in the eve client under wine, but only one is doing any significant load ...

ps -eLo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm| grep ExeFile.exe
23629 23629 TS - 0 19 2 70.4 Rl+ - ExeFile.exe
23629 23838 TS - 0 19 0 0.0 Sl+ pipe_wait ExeFile.exe
23629 23839 TS - 0 19 2 0.2 Sl+ poll_schedule_ ExeFile.exe
23629 23840 TS - 0 19 3 0.4 Sl+ pipe_wait ExeFile.exe
23629 23841 TS - 0 19 3 0.2 Sl+ pipe_wait ExeFile.exe
23629 23842 TS - 0 19 3 0.4 Sl+ pipe_wait ExeFile.exe
23629 24832 TS - 0 19 0 0.0 Sl+ pipe_wait ExeFile.exe
23629 25221 TS - 0 19 0 0.0 Sl+ pipe_wait ExeFile.exe
23629 27223 TS - 0 19 2 0.0 Sl+ poll_schedule_ ExeFile.exe
23629 27739 TS - 0 19 0 0.0 Sl+ pipe_wait ExeFile.exe
23629 27846 TS - 0 19 3 0.0 Sl+ pipe_wait ExeFile.exe
23629 1673 TS - 0 19 1 0.0 Sl+ pipe_wait ExeFile.exe
23629 9351 TS - 0 19 2 0.0 Sl+ pipe_wait ExeFile.exe
23629 9352 TS - 0 19 3 0.0 Sl+ pipe_wait ExeFile.exe
23629 9758 TS - 0 19 2 0.8 Sl+ pipe_wait ExeFile.exe
23629 9759 TS - 0 19 3 0.7 Sl+ pipe_wait ExeFile.exe
23629 9760 TS - 0 19 2 0.7 Sl+ pipe_wait ExeFile.exe
23629 10322 TS - 0 19 1 0.0 Sl+ pipe_wait ExeFile.exe
23629 10323 TS - 0 19 1 0.0 Sl+ pipe_wait ExeFile.exe

so for all practical purposes, EVE is single threaded ....
Mythas Rothron
The God's of EVE Inc.
#10 - 2012-04-02 23:10:05 UTC
Whitehound wrote:
Using a window environment like Xfce or LXDE over GNOME and KDE can improve the speed of EVE on WINE, too. It is because of the window managers using some resources of the graphics card (3D composition, transparency, overlays, etc.) that causes a loss in performance. More light-weight environments like Xfce and LXDE keep the resource requirements to a minimum, which leaves more to the 3D applications and as a result does EVE run faster.

As an alternative to changing the desktop environment can one start a second X server, too. This allows to run the client exclusively on a single display without any interference from a window manager. It can be combined with a real-time scheduler to maximize CPU utilisation. An example, run as root and in one command line where me stands for the user ID to run WINE under:

xinit /usr/bin/chrt -f 1 su -l me -c 'env WINEPREFIX="/home/me/.eve" WINEDEBUG="-all" WINEDLLOVERRIDES="msvcr80,msvcr90,msvcr100=b,n" wine explorer "/desktop=EVE,1680x1050" "/home/me/.eve/drive_c/Program Files/CCP/EVE/bin/ExeFile.exe"' -- /usr/bin/Xorg :1 -nolisten tcp

The EVE client will then be running on a different virtual terminal and one can switch between the two X servers with i.e. CTRL-ALT F7 or F8.


So, do you think the BFScheduler, 1000mhz ticker in the kernel and Preemptive kernel compilation would help? Just wondering, it would seem on multithreaded applications (especially with multiple real/virtual cores) that this would help, especially at partial cpu load.
Whitehound
#11 - 2012-04-03 07:58:14 UTC  |  Edited by: Whitehound
Mythas Rothron wrote:
So, do you think the BFScheduler, 1000mhz ticker in the kernel and Preemptive kernel compilation would help? Just wondering, it would seem on multithreaded applications (especially with multiple real/virtual cores) that this would help, especially at partial cpu load.

You tell me! I personally do not like the BF scheduler due to its name X. Should it ever find its way into the standard kernel will I give it a try. However, I have not compiled my kernel only to suite EVE, because I run other stuff, too. I do use a 1000Hz tickless and semi-preemptive kernel setup. It might actually be that Nvidia's graphics driver expects a certain setup here. I remember something like this being the case in the past... The reason why I included the chrt command in my example was to avoid the normal scheduler, because of the many background processes a distribution can have, but nothing more. I sometimes do not know what exactly is happening in the background on my box. It may also be interesting for those who run multiple clients or who want to stream the video of their EVE session by using a second X server.

Loss is meaningful. Therefore is the loss of meaning likewise meaningful. It is the source of all trolling.
Mythas Rothron
The God's of EVE Inc.
#12 - 2012-04-03 11:33:42 UTC
Whitehound wrote:
Mythas Rothron wrote:
So, do you think the BFScheduler, 1000mhz ticker in the kernel and Preemptive kernel compilation would help? Just wondering, it would seem on multithreaded applications (especially with multiple real/virtual cores) that this would help, especially at partial cpu load.

You tell me! I personally do not like the BF scheduler due to its name X. Should it ever find its way into the standard kernel will I give it a try. However, I have not compiled my kernel only to suite EVE, because I run other stuff, too. I do use a 1000Hz tickless and semi-preemptive kernel setup. It might actually be that Nvidia's graphics driver expects a certain setup here. I remember something like this being the case in the past... The reason why I included the chrt command in my example was to avoid the normal scheduler, because of the many background processes a distribution can have, but nothing more. I sometimes do not know what exactly is happening in the background on my box. It may also be interesting for those who run multiple clients or who want to stream the video of their EVE session by using a second X server.


Aye, I hear that, but the code under the poorly-chosen name is very interesting. I maintain a ported BFS kernel under Arch, I'll give it a try and see what happens!
COMM4NDER
Legendary Umbrellas
#13 - 2012-04-05 03:01:45 UTC
About the cpu scaling Arch really got a awesome wiki for this explaining everything with different governators etc.
https://wiki.archlinux.org/index.php/CPU_Frequency_Scaling

[url=https://github.com/CommanderAlchemy/.bin/blob/master/eve] EVE - Online Launcher [Linux] [/url] Installs, launches character prefixes (both SISI & Tranquility). Simplescreenrecorder shm inject
Bent Barrel
#14 - 2012-04-05 10:20:24 UTC
COMM4NDER wrote:
About the cpu scaling Arch really got a awesome wiki for this explaining everything with different governators etc.
https://wiki.archlinux.org/index.php/CPU_Frequency_Scaling


great stuff, thanks