OR  Zero-K Name:    Password:   

[Linux kernel 3.16.7] Performances [Spring 104.0.1-287] ]

4 posts, 105 views
Post comment
Filter:    Player:  

3 days ago
Greetings !!

I read a lot of posts concerning the poor performances concerning some of the campaign maps... this even if we had
an 8core computer with a quite good GPU.

For me I use a AMD FX-8370E running at 3300MHz and a R7-370MX.

I was surprised about the fact the computer was blowing once any maps where started... I took the time to monitor the system
and realized that Spring was a simple "process" that uses 137% of the processor, each core was set to 100% one by one.

I take a tour on the different forums and I learned that Spring was 15 years old and seemly that wasn't enough features to hold
a multithreaded environnement. As far as I know to reduce the weight of a process, principaly concerning loops, in single or multi threading programming, you "just" need a little nanosleep of 10 ms, and your core start from 100% to less than 10 once the scheduler
took the relay... depending on the way you are programming and the quality of the langage you use to devellop.

As I have not yet learned the way spring works, I downloaded the source code yesterday, I decided to find a way to obtain a better
behaviour of the computer when playing Zero-K under Linux environment.

Changing the priority of the process seems to give more FPS but I didn't tested with very complicated "maps" in the campaign.
I set the scheduler to be CFQ/NOOP (not yet tested with deadline) with a priority close to RT, the fan is still blowing like crazy
because one core at least is set to 100% but I got FPS near 40 at minimum in all the "maps" I tested from little to middle.

I'll keep you in touch concerning the "big maps" in coop style where the performances where diving quick (less than 24 FPS).

This is the script I used to obtain better performances with graphical settings set to LOW.

mono --desktop --optimize=all Zero-K.exe & renice -n -20 -p $(pgrep mono)
sleep 35
renice -n -20 -p $(pgrep spring)
kill -9 $(pgrep mono)
echo "$(date) KILLED"
exit 0

It must be a shell script and this one must be set executable with chmod +x run-zerok.sh
I'm pretty sure if we could change the processor to process timeslice we could fix this issue.

This script kills the launcher that never exits when the Zero-k is closed.

+2 / -0

2 days ago
Hi BErankhurukan, I am not sure the scheduler matters here. Priority -20 means Zero-K gets priority over everything, and has same priority as core system processes (kernel), so it naturally gets more resources. I think this has the biggest impact in your test. CFQ might even make matters worse, since it is fair, and requires Zero-K to be fair to other priority -20 processes.
About --optimize=all for mono: The Zero-K exe only runs the lobby using mono, and launches a Linux binary of spring for the actual game. I would be curious in how much --optimize=all really improves performance apart from the priority setting. Have you compared with Spring 104.0.1-527 which was used in the Linux test branch of Zero-K Steam a while ago? I think it had better performance for me, but could not test properly in multiplayer because of different versions. Here's the Spring binary: https://springrts.com/dl/buildbot/default/maintenance/104.0.1-527-gf2536df/
+0 / -0

2 days ago
I have a better question. Why are you using such an old Kernel? I am running Debian 9 (stretch) the stable release and my kernel is 4.9.0-6-amd64 and I am thinking about upgrading so I can have a newer 32 bit graphics stack so I can both run Zero-K and Wine. The non-backport version of the kernel is 3.16.63.
+0 / -0

2 days ago
(edited 2 days ago)

Ubuntu 18.04, 4.15.0-23-generic (x86_64) here. I believe standard for this Ubuntu release.
+0 / -0