| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0004434 | Spring engine | General | public | 2014-06-12 08:04 | 2016-02-05 23:11 | ||||
| Reporter | Google_Frog | ||||||||
| Assigned To | Kloot | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | fixed | ||||||
| Product Version | 97.0.1+git | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0004434: 97.0.1-18 is bad at maintaing ping during high CPU. | ||||||||
| Description | Many people have reported that 97.0.1-18 is has performance issues in large games compared to 91.0. Testing this has been problematic because I don't even have 2 dedicated testers and this would take 16. This report is a comparison of the CPU and Ping values in the engine playerlist and mostly hinges on those values being useful and correct. The attached screenshots are two large games of similar unit count. In terms of CPU both 97.0.1-18 and 91.0 are similar and 97.0.1-18 may even be better. The 97.0.1-18 has 8 players with pings which indicate that they are in catchup mode while the pings in 91.0 are fine. Players have reported playing "seconds behind" so I think that the ping values are reported correctly. If there was a bug with maintaining ping it could account for most of the performance complaints. The host is a dedicated server. This is probably related to the jitter bug http://springrts.com/mantis/view.php?id=4427 (it may even be the same thing but I think it is better to report than to not report). | ||||||||
| Additional Information | Frozen Fortress v2 with 97.0.1-18. Licho highlighted it as an example of a game where he complains about performance. http://zero-k.info/Battles/Detail/267237 Melt v2 with 91.0 and the same player count that occurred a week ago. Importantly this game was played after the server move. It appears in the 91 screenshot. http://zero-k.info/Battles/Detail/268066 Frozen Fortress v2 with 91.0 and the same player count but it is 9 months old. http://zero-k.info/Battles/Detail/193131 Frozen Fortress v2 with 91.0 and similar player count but it is 2 months old. http://zero-k.info/Battles/Detail/247112 | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
Google_Frog (reporter) 2014-06-12 10:04 |
As I said this rests on CPU and Ping displays. If those aren't useful could they be improved? |
|
jK (developer) 2014-06-12 10:36 |
... I already explained that it's not the netowrk ping that is displayed ... see http://springrts.com/phpbb/viewtopic.php?f=12&t=30652&hilit=+ping |
|
Google_Frog (reporter) 2014-06-12 10:48 Last edited: 2014-06-12 10:49 |
Is it untrue that high ping (>10s) indicates that someone is catching up? Also why not make large reverts for testing purposes? |
|
silentwings (reporter) 2014-06-12 12:32 Last edited: 2014-06-12 12:41 |
Those values all look normal to me - I would expect that all red values are players either (1) dropping due to cpu unable to keep up with game or (2) dropped, reconnected to game and still catching up - and since there are many players in red I'd bet its mostly (1). I don't expect it to be true that 97+ and 91.0 are comparable in terms of load placed on cpu, I'd expect 97 to ask more from cpu. Based on 96.0 I would expect the "ping" of a ingame non-lagging player to read 200-400ms. |
|
malric (reporter) 2014-06-14 20:11 Last edited: 2014-06-15 23:30 |
Not sure if it helps (please come with suggestions) but I have made a widget to dump the number of units, average cpu and average spring ping. Data is a bit raw now (not sure I compute very well the number of units), but I applied the widget for the 2 frozen battles with 97 and 91 and uploaded the data here: For 97: https://docs.google.com/spreadsheets/d/15G6wvEozZfIl0G7iO1jzF-XU4pX1m0M2H32zH4jGwXY/edit?usp=sharing For 91: https://docs.google.com/spreadsheets/d/1MddeG-fKKHEvubTP-PkUxuj7WQamfuulupq_5Ts9snA/edit?usp=sharing (previously I posted some comparison, but I think there were incorrect as they were taking some dropped specs into account. Will repost only when sure on the,). Please come with suggestion to improve, etc. I can share somewhere the widget that dumps the data if anybody is interested. It would be nice to have to replays with the same set of players/computers/connections. Edit: I made individual sheet-s for players (sfireman as he was in both games, and malric (me) as I was in the 97 game). The spring ping is quite high (I think). After the 97 game, the host was switched to 91 and I do not remember experience those high pings. I would like to determine exactly what causes the problem with this new release and zero-k, and I am not sure how to interpret the results/what to investigate next. Question: in the developers opinion what is the relation between cpu usage and spring ping? For example for the 91.0 game I see that for sfireman, with a cpu usage less than 40%, spring ping does not go above 0.4. On the other hand with 97.0 game I can see that for sfireman, with a cpu usage between 40% and 60%, spring ping starts going a lot above 0.4. For malric with 97.0 game I see something similar (cpu usage below 80%, spring ping goes very high). |
|
Kloot (developer) 2014-06-15 23:49 Last edited: 2014-06-15 23:57 |
'Ping' is the number of simframes a client is behind the server (100ms == 3 frames, 200ms == 6 frames, etc). CPU usage is normally unrelated to ping so long as a client can maintain 30*s simframes/second (where s is the game-speed multiplier). If client pings grow larger over time while their CPU usage is only 40%, that would mean they are not maintaining a steady 30Hz simframe rate (which should be verifiable from logging data) and the only explanation I can see for that is a consistent lack of time spent eating through network messages under higher load (which probably goes to drawframe FPS instead). |
|
malric (reporter) 2014-06-16 00:37 |
Thanks for the answer Kloot. Just to make sure I understand, when you say "not maintaining a steady 30Hz simframe rate (which should be verifiable from logging data)", you mean something like logging in a "widget:GameFrame" the time at which is called? (to check what sim frame rate is obtained by a specific machine)? |
|
Kloot (developer) 2014-06-16 01:03 Last edited: 2014-06-16 01:05 |
Yes. Start with numGameFrames = 0 and gameTime = 0. Every GameFrame call, increment numGameFrames by 1 and gameTime by the amount of time elapsed since the last GameFrame call. Whenever gameTime >= 1000ms, dump numGameFrames to log, then reset gameTime and numGameFrames to 0 again. |
|
Kloot (developer) 2016-02-05 23:11 |
I assume this was resolved by removal of Lua mutexes (extra painful due to boost::recursive_mutex being used) |
| Notes |
| Issue History |
|||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-06-12 08:04 | Google_Frog | New Issue | |
| 2014-06-12 08:04 | Google_Frog | File Added: largeGame91.jpg | |
| 2014-06-12 08:06 | Google_Frog | File Added: largeGame97.0.1-18.jpg | |
| 2014-06-12 10:04 | Google_Frog | Note Added: 0013273 | |
| 2014-06-12 10:36 | jK | Note Added: 0013274 | |
| 2014-06-12 10:48 | Google_Frog | Note Added: 0013275 | |
| 2014-06-12 10:49 | Google_Frog | Note Edited: 0013275 | View Revisions |
| 2014-06-12 12:32 | silentwings | Note Added: 0013276 | |
| 2014-06-12 12:34 | silentwings | Note Edited: 0013276 | View Revisions |
| 2014-06-12 12:35 | silentwings | Note Edited: 0013276 | View Revisions |
| 2014-06-12 12:36 | silentwings | Note Edited: 0013276 | View Revisions |
| 2014-06-12 12:41 | silentwings | Note Edited: 0013276 | View Revisions |
| 2014-06-14 20:11 | malric | Note Added: 0013282 | |
| 2014-06-14 20:12 | malric | Note Edited: 0013282 | View Revisions |
| 2014-06-14 20:44 | malric | Note Edited: 0013282 | View Revisions |
| 2014-06-14 20:46 | malric | Note Edited: 0013282 | View Revisions |
| 2014-06-14 21:15 | malric | Note Edited: 0013282 | View Revisions |
| 2014-06-14 21:19 | malric | Note Edited: 0013282 | View Revisions |
| 2014-06-15 23:30 | malric | Note Edited: 0013282 | View Revisions |
| 2014-06-15 23:49 | Kloot | Note Added: 0013285 | |
| 2014-06-15 23:51 | Kloot | Note Edited: 0013285 | View Revisions |
| 2014-06-15 23:52 | Kloot | Note Edited: 0013285 | View Revisions |
| 2014-06-15 23:54 | Kloot | Note Edited: 0013285 | View Revisions |
| 2014-06-15 23:57 | Kloot | Note Edited: 0013285 | View Revisions |
| 2014-06-16 00:37 | malric | Note Added: 0013286 | |
| 2014-06-16 01:03 | Kloot | Note Added: 0013287 | |
| 2014-06-16 01:03 | Kloot | Note Edited: 0013287 | View Revisions |
| 2014-06-16 01:05 | Kloot | Note Edited: 0013287 | View Revisions |
| 2016-02-05 23:11 | Kloot | Note Added: 0015636 | |
| 2016-02-05 23:11 | Kloot | Status | new => closed |
| 2016-02-05 23:11 | Kloot | Assigned To | => Kloot |
| 2016-02-05 23:11 | Kloot | Resolution | open => fixed |
| Issue History |