| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0002149 | Spring engine | General | public | 2010-09-26 07:44 | 2011-09-26 22:33 | ||||
| Reporter | dfreeman | ||||||||
| Assigned To | zerver | ||||||||
| Priority | normal | Severity | minor | Reproducibility | sometimes | ||||
| Status | closed | Resolution | suspended | ||||||
| Product Version | 0.82.5 | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0002149: Unresponsive GUI under high CPU load | ||||||||
| Description | Under high CPU load, orders start getting dropped. A factory keeps sending units to die after being told to send them to a new destination, or an air transport doesn't pick up your commander, or the commander won't d-gun even though it could. Very quickly things get out of hand because the fraction of orders that are dropped can get quite high. Maybe it goes all the way to 100% under high enough load.. I've had times where it's just impossible to d-gun and I know I'm trying! (was originally thought to be MT related, but the author then discovered the regular build exhibits the same problem, 0.81 and later.) | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
||||||
|
||||||
 Relationships |
| Notes |
|
|
zerver (reporter) 2010-09-26 12:21 |
All Spring version exhibit lag once your CPU hits 100%. In Spring MT, this problem gets severe unless you follow these instruction, printed at game start: ************** SPRING MULTITHREADING VERSION IMPORTANT NOTICE **************. LUA BASED GRAPHICS WILL CAUSE HIGH CPU LOAD AND SEVERE SLOWDOWNS. For best results disable LuaShaders in SpringSettings or the Edit Settings menu. Press f11 to open the widget list, which allows specific widgets to be disabled. The LUA-DRAW(MT) value in the upper right corner can be used for guidance. Safe to use: Autoquit, ImmobileBuilder, MetalMakers, MiniMap Start Boxes. So, make sure LUA-DRAW is a near zero value, and you will have even better performance with Spring-MT than with single thread. This limitation regarding LUA and MT may or may not be fixed in Spring 0.83. The fix is rather easy (and available already) but it also requires significant changes to many existing LUA widgets/gadgets. I will close this issue in a few days unless you have more questions. |
|
dfreeman (reporter) 2010-09-26 16:27 |
IMHO, there is a big difference between the behaviour in single-thread vs MT-SIM. While single-thread will slow down screen refreshes and start to lag, it won't to my knowledge drop orders. You give an order, and after the current lag has passed, your order is carried out. In reality, every other non-lagging player sees your order carried out right away. The problem is in the MT-SIM version, the orders get dropped completely. This happens even when the screen is refreshing fast enough to be playable, so you don't realise you have a problem until gameplay is affected by orders being lost. You know damn well that you clicked on a valid order, so you assume it's been accepted, and then you find out otherwise. I imagine that this is a thread synchronisation issue, but I haven't looked at the codebase. |
|
zerver (reporter) 2010-09-26 20:10 |
Okay, thanks for the info, I will investigate... |
|
zerver (reporter) 2010-09-27 02:42 |
Not able to reproduce so far. Can you remember how high your ping was when this problem occurred? |
|
dfreeman (reporter) 2010-09-27 04:22 |
I just viewed a replay in which this was happening, and it reports my CPU=12% and ping=150ms. I'm not sure if I believe that.. but the replay should be accurate, right? In any case, the user isn't aware that this is happening because gameplay appears normal. One possibility that comes to mind, is I had the "Transport AI" widget enabled, which might be editing the orders of the factories and accidentally clobbering the new orders. I'll try without. Still, I've had problems with other units too. |
|
zerver (reporter) 2010-09-27 14:42 |
Yes, the replay should be accurate for players. There is a bug though that might cause the person who is watching the replay to appear with the wrong name. I tested playing with a 5000ms ping and the orders seem to come into effect after about twice that time (10 seconds). |
|
dfreeman (reporter) 2010-09-28 02:40 |
I'll have to report back after I play a few more games. It's possible that "Transport AI" failing under MT-SIM could account for a lot of it actually. Transports not picking up a commander for example, if they would rather be going back to a factory. And there are other reasons for not being able to d-gun in the heat of the moment. |
|
zerver (reporter) 2010-10-17 02:53 |
Any more problems with this? otherwise I close the issue. |
|
dfreeman (reporter) 2010-10-17 05:05 |
I don't have time to play-test at the moment, so please close it. |
|
dfreeman (reporter) 2010-10-17 09:30 |
I just loaded down my system and then ran a single-player game of BA 7.19 using the non-multithreaded version. I found that the UI would ignore clicks, requiring me to re-issue orders. For example, I would click on a building type, and the cursor wouldn't change. This is probably the same bug, and so it would appear to be unrelated to multithreading. |
|
zerver (reporter) 2010-10-17 14:39 |
Do you mean that you click on a building in the build menu, but when you then move the mouse pointer to place the actual building, the building "sample" is not shown? This should not happen. The closest thing I can remember experiencing, is when you are a bit sloppy and click on a button, but then accidentally move the mouse outside the actual button before releasing it. This will cause the click not to be registered (is consistent with how windows GUI behaves in general). All commands sent to the server will delayed depending on your ping. So you should see the building sample, but it may take X seconds before the actual construction starts. |
|
abma (administrator) 2010-10-17 18:08 |
maybe this is related: (gadget test script + output) http://pastebin.com/NCuWkiqq |
|
dfreeman (reporter) 2010-10-19 02:39 |
Zerver, this is what I mean, but remember I was playing single player so the ping should have been close to zero even on a loaded system. The CPU wasn't causing lag, despite the background tasks using up all the disc bandwidth. (I had a virtual machine running another O/S using 100% of one core, so although spring had a free core, the system was fairly busy.) Also I find that it can take several goes to select a building and have the orders menu displayed. I think this bug can be renamed, it happens with non-multithreaded, and it's probably not the orders being dropped, but the GUI events. I noticed the buildings being hard to select since trying the 0.82 releases. I remember the GUI being responsive in 0.81, even under high CPU/ping. |
|
zerver (reporter) 2010-10-19 14:08 |
Okay, I renamed the issue accordingly. Will see if I can reproduce the problem, otherwise maybe someone else can. |
|
dfreeman (reporter) 2010-11-07 06:41 |
I've been testing 0.82.6.1, and although this problem is present on both single-threaded and multi-threaded, it's much worse on multi. I started a game on Throne with 8 players, with a freshly booted system and nothing else running, and even in the first few seconds I noticed that there was a one second lag between clicking on the UI buttons and the resulting action being taken. This appears to apply to the whole UI, so telling a unit to guard a building, or selecting that building, has the same problem. Even in the single-threaded version, it's quite unresponsive to the point where it spoils the game. I've noticed this problem since the 0.82 series, and I hope it can be fixed!! |
|
zerver (reporter) 2011-01-22 17:41 |
This delay in selecting stuff indicates that network is not the issue. Tbh I have never experienced anything remotely similar. Can you tell me something more about your machine? Is this linux? You wrote something about background tasks stressing the hard disk very much. This could in fact cause the type of behavior your are describing. Check your system and VM for viruses. |
|
dfreeman (reporter) 2011-01-22 18:01 |
Dell Studio 15 laptop. Core2 Duo P8600 @ 2.4 GHz. 4GB RAM. ATI Mobility Radeon HD 3400. openSUSE 11.2 (x86_64) with KDE 4.3.5 I'm confident that my system and VMs are virus-free. The CPU and disc activity were all on purpose, although I forget what I was doing. I might have been installing a Windows OS into the VM, which explains why I was playing Spring ;) |
|
zerver (reporter) 2011-01-22 22:40 |
To make sure I understand, were you playing a linux build of spring, or a windows one? Was it in a VM or a real system? |
|
dfreeman (reporter) 2011-01-23 03:01 |
It was running natively under linux, in parallel to the VM. So it had one core free to play with, while the VM sucked up the other core. |
|
zerver (reporter) 2011-01-24 00:45 |
You spoke about a freshly booted system, does that mean no VM running? Running MT with only a single core available is pretty pointless as you may understand, and depending on thread or application priorities may give strange results. |
|
dfreeman (reporter) 2011-01-24 04:19 |
Yes, the "freshly booted system" is a different test altogether. Perhaps the problem being much worse on multithreaded is related to the ability of both threads to get adequate time on separate cores. Maybe there is a synchronisation issue after all - if one thread is waiting for the other one, and not giving up the CPU, it will wait a long time if there is another process using the other core. Whereas if it gives up the CPU, the other thread can run, and it will be closer to the performance of the single-thread version. I presume the end goal is to have the multithreaded version polished up to the point where everybody can use it regardless of whether they have SMP or not. So it shouldn't be pointless to test it on a single core configuration, or dual core with one core loaded down. Does spring adjust its behaviour to the performance of the machine? Does it run any timing loops at the start that can be fooled by background tasks coming and going? |
|
zerver (reporter) 2011-01-25 12:58 |
No, spring does not measure the performance. Some issue with thread priorities could explain your problem. How high is your frame rate in game? Did you compile spring yourself, and if so how did you do it? I remember some guy who accidentally compiled a debug build and tried to play with that :) |
|
dfreeman (reporter) 2011-01-26 04:36 |
The frame rate is usually high enough.. more than 60 fps in the beginning, but at the end of a big game it can drop. (I have limited the number of particles to keep it high during insane battles.) I'm usually limited by lag rather than frame rate. Remember, I've seen this bug happen at the start of the game when the frame rate is maxed out by syncing to vertical refresh. I always compile myself from the release version of the source. I change one setting in cmake, I set STABS_DEBUG_SYMBOLS=TRUE. Then make, and make install-spring install-spring-multithreaded . I hope you mean that "some guy" compiled a debug sync build, not just debug symbols :) |
|
zerver (reporter) 2011-02-06 18:40 |
I meant debug mode (no compiler optimizations). But if you have 60fps that can be ruled out for sure. Unfortunately I have no real clue at this time to what the problem could be. MT behaving differently is a good clue though. Perhaps you should test some other OpenGL app, which uses mouse input, on your machine and see if the UI response is snappy. Try running the app together with an intense Spring game and see if this changes something. |
|
zerver (reporter) 2011-07-14 12:22 |
I experienced something that matches the "unresponsive" behavior while running a debug build of Spring recently. Debug builds are typically very slow, not playable really, but the mouse clicks and such usually register. But this time I had the Widget Selector open, and when I clicked items in the list, a large percentage of the clicks had no effect. Great, I thought, maybe finally a way to reproduce the issue. However, on the next run, the problem was gone again. So I'm back on square one again. dfreeman, I assume you still have this issue? It would help if you could try with the latest master version too: http://springrts.com/dl/buildbot/default/master/0.82.3-2624-ga307307/spring_0.82.3-2624-ga307307.exe |
|
zerver (reporter) 2011-08-24 22:20 |
I'm closing this one since there was no response from the reporter. I also found a bug in Red UI that causes menu clicks not to be registered if you click very rapidly. This could account for some of the symptoms. |
|
dfreeman (reporter) 2011-08-25 15:10 |
Sorry I haven't been around for a while. I have tested the latest stable version, 0.82.7.1, BA 7.50, by playing with a friend. I was hosting each game, his ping was about 200-300ms. Our CPUs were not very high, 30% maybe. Both running Linux. I was running single-thread. Not only do I find my orders getting dropped, and buildings/units hard to select, but so does he! Also two of our games were ended early by one of us comwalking into the battle by accident. (We each did this.) One difference in configuration, is somehow my "3D trees" setting got switched back on - this really loads my video card on maps with lots of trees. |
|
zerver (reporter) 2011-08-25 18:03 |
Like I wrote, maybe partly due to a bug in RedUI. So, turn off all widgets (f11) and test again. |
|
zerver (reporter) 2011-09-26 22:33 |
Please reopen the issue when you have time to provide some feedback |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-09-26 07:44 | dfreeman | New Issue | |
| 2010-09-26 12:21 | zerver | Note Added: 0005657 | |
| 2010-09-26 16:27 | dfreeman | Note Added: 0005660 | |
| 2010-09-26 20:10 | zerver | Status | new => assigned |
| 2010-09-26 20:10 | zerver | Assigned To | => zerver |
| 2010-09-26 20:10 | zerver | Note Added: 0005663 | |
| 2010-09-27 02:42 | zerver | Note Added: 0005666 | |
| 2010-09-27 04:22 | dfreeman | Note Added: 0005667 | |
| 2010-09-27 14:42 | zerver | Note Added: 0005671 | |
| 2010-09-28 02:40 | dfreeman | Note Added: 0005673 | |
| 2010-10-17 02:53 | zerver | Note Added: 0005749 | |
| 2010-10-17 02:53 | zerver | Status | assigned => feedback |
| 2010-10-17 05:05 | dfreeman | Note Added: 0005751 | |
| 2010-10-17 09:30 | dfreeman | Note Added: 0005752 | |
| 2010-10-17 14:39 | zerver | Note Added: 0005753 | |
| 2010-10-17 18:08 | abma | Note Added: 0005754 | |
| 2010-10-19 02:39 | dfreeman | Note Added: 0005758 | |
| 2010-10-19 14:08 | zerver | Note Added: 0005759 | |
| 2010-10-19 14:08 | zerver | Summary | MT-SIM drops orders under high CPU load => Unresponsive GUI under high CPU load |
| 2010-10-19 14:08 | zerver | Description Updated | |
| 2010-11-07 06:41 | dfreeman | Note Added: 0005838 | |
| 2011-01-22 17:41 | zerver | Note Added: 0006285 | |
| 2011-01-22 18:01 | dfreeman | Note Added: 0006288 | |
| 2011-01-22 22:40 | zerver | Note Added: 0006289 | |
| 2011-01-23 03:01 | dfreeman | Note Added: 0006291 | |
| 2011-01-24 00:45 | zerver | Note Added: 0006301 | |
| 2011-01-24 04:19 | dfreeman | Note Added: 0006302 | |
| 2011-01-25 12:58 | zerver | Note Added: 0006307 | |
| 2011-01-26 04:36 | dfreeman | Note Added: 0006310 | |
| 2011-02-06 18:40 | zerver | Note Added: 0006351 | |
| 2011-07-14 12:22 | zerver | Note Added: 0007017 | |
| 2011-08-24 22:20 | zerver | Note Added: 0007278 | |
| 2011-08-24 22:20 | zerver | Status | feedback => closed |
| 2011-08-24 22:20 | zerver | Resolution | open => no change required |
| 2011-08-25 02:56 | abma | Relationship added | related to 0002437 |
| 2011-08-25 15:10 | dfreeman | Note Added: 0007289 | |
| 2011-08-25 15:10 | dfreeman | Status | closed => feedback |
| 2011-08-25 15:10 | dfreeman | Resolution | no change required => reopened |
| 2011-08-25 18:03 | zerver | Note Added: 0007290 | |
| 2011-09-26 22:33 | zerver | Note Added: 0007421 | |
| 2011-09-26 22:33 | zerver | Status | feedback => closed |
| 2011-09-26 22:33 | zerver | Resolution | reopened => suspended |
| Issue History |