Extended play stuttering/'memory leak' issue
Scout1Treia
United States Join Date: 2015-01-06 Member: 200664Members
United States Join Date: 2015-01-06 Member: 200664Members
Now I say "memory leak" but I've not done any sort of analysis on my actual memory usage, so please note that that is an amateur's interpretation.
What I can say is that after a period of extended play (starting anywhere from ~1 to ~3h) Natural selection 2 starts to have serious issues. During normal, smooth, ~60FPS gameplay I will experience sudden drops or freeze-ups where the game simply stops responding, only to kick back into life a few seconds (or a minute or more, towards the end) later. This, obviously, makes it difficult to play. The drops are pronounced when entering a room for the first time after a map load, or opening the armory/prototype lab to select a purchase (oddly the evolve menu seems to be fine). Drops also occur "at random", for example while running through the base to chase a gorge or something, or while there are no other players around. Typically right after the drops I'll get the yellow socket/connection error and my ping's DISPLAY will momentarily rise dramatically (normally it's ~30, and increases go anywhere from ~80 to ~300).
A related, but more confusing error is the red socket/connection error, which only happens when I am spectating (dead or otherwise). A gorge, for example, will be running happily along a corridor... and then start flying and spinning outside the map while the red connection/socket error appears, all while still running at full ~60 FPS (so without the pronounced stuttering/"drop"). A few seconds later gameplay will resume without a hint of any other problem. Other applications do not report connection drops, and continuous file transfers that I sometimes run while playing show no marked decreases or dead periods, making me assume that it is not an issue with the otherwise reliable connection.
On the face of it it sounds like a texture loading issue, and I was quite happy to discover the texture handling setting... only to discover that it in fact makes the issue worse. With texture handling set to the correct setting, the game experiences more frequent and severe drops starting immediately after map load (i.e. with one minute of playtime). Textures also "refuse to load", showing the default/low quality models when I have them set to medium, the map's background will refuse to load for large portions of the map, and generally it's a complete shitshow. So that is unfortunate.
Here's my techsupport.zip: https://dl.dropboxusercontent.com/u/86097728/tech_support.zip
And something I forgot to mention: This issue started roughly 2 1/2 months ago. I am unsure of the build number. Before that the game ran admirably, all the time, for as long as I wanted it to.
What I can say is that after a period of extended play (starting anywhere from ~1 to ~3h) Natural selection 2 starts to have serious issues. During normal, smooth, ~60FPS gameplay I will experience sudden drops or freeze-ups where the game simply stops responding, only to kick back into life a few seconds (or a minute or more, towards the end) later. This, obviously, makes it difficult to play. The drops are pronounced when entering a room for the first time after a map load, or opening the armory/prototype lab to select a purchase (oddly the evolve menu seems to be fine). Drops also occur "at random", for example while running through the base to chase a gorge or something, or while there are no other players around. Typically right after the drops I'll get the yellow socket/connection error and my ping's DISPLAY will momentarily rise dramatically (normally it's ~30, and increases go anywhere from ~80 to ~300).
A related, but more confusing error is the red socket/connection error, which only happens when I am spectating (dead or otherwise). A gorge, for example, will be running happily along a corridor... and then start flying and spinning outside the map while the red connection/socket error appears, all while still running at full ~60 FPS (so without the pronounced stuttering/"drop"). A few seconds later gameplay will resume without a hint of any other problem. Other applications do not report connection drops, and continuous file transfers that I sometimes run while playing show no marked decreases or dead periods, making me assume that it is not an issue with the otherwise reliable connection.
On the face of it it sounds like a texture loading issue, and I was quite happy to discover the texture handling setting... only to discover that it in fact makes the issue worse. With texture handling set to the correct setting, the game experiences more frequent and severe drops starting immediately after map load (i.e. with one minute of playtime). Textures also "refuse to load", showing the default/low quality models when I have them set to medium, the map's background will refuse to load for large portions of the map, and generally it's a complete shitshow. So that is unfortunate.
Here's my techsupport.zip: https://dl.dropboxusercontent.com/u/86097728/tech_support.zip
And something I forgot to mention: This issue started roughly 2 1/2 months ago. I am unsure of the build number. Before that the game ran admirably, all the time, for as long as I wanted it to.
Comments
If no - then it is more like overheating than leak.
It's approximately 1/10th the performance of cards coming out this year, and 1/5 the performance of cards from 5 years ago! (yours came out 6 years ago, for reference)
The dropped connection sounds like choking but its hard to be sure without net_log 3. Do some line tests such as pingtest.net whenever you are experiencing issues.
The texture loading setting should definitely make things *better* if you set it to the correct setting. (1 GB in your case)
The textures refusing to load on time is preferable to the alternative - it is doing that IN LIEU of hitching occurring - Still, this indicates an issue somewhere in your PC's ability to load the textures onto the GPU.
I would begin diagnosing your hardware considering it's age and the symptoms involved.
Use the free programs Speedfan and GPU-z or MSI Afterburner to ensure the proper temps and clockrates are occurring while you run into these issues.
If you feel like doing some bonus investigation, you can type p_logall in the console (~ key) after you get into a game that you can easily reproduce these issues for at least 5 or 10 minutes.
Then quit, navigate to your hidden folder C:/users/YOU/Appdata/Roaming/Natural Selection 2/
And find the *.plog file you just made and zip it up and upload it here for analysis. This provides us with a frame by frame breakdown of what is running.
Thanks so much for your detailed reply. In rough order:
The video card is pretty old, yep. A long life story short it worked for what I wanted and now it performs admirably... and NS2 has always been among the admirable performance, with the exception of this recent problem. I haven't seen problems in any other games or applications, so I would hope for my sake (sorry programmers everywhere) that it's a NS2 problem/spec problem coinciding with updated textures, rather than hardware failure.
Net_log I did... I'm not sure what I was supposed to be looking for or if it has an output file proper, I found the console spam it produced in the log.txt file, uploaded as follows. The stuttering was a bit light during this capture but I hope it captures the issue. https://dl.dropboxusercontent.com/u/86097728/log.txt
Texture handling I'm going to try nuking the options file and setting new ones, hopefully that will help.
Pingtest.net reported okay latency, a bit high considering the location but certainly nothing I'd call abnormal. Unfortunately if you were looking for the packet drop results I couldn't get those as the IGB doesn't run javascript and trying to tab to a browser might be... problematic. http://www.pingtest.net/result/114251662.png
Speedfan reports all temperatures staying well within the green during the entire play session; I was unfamiliar with MSI afterburner/clockrates so I've put that off pending other, easier things for me to check.
p_logall as follows: https://dl.dropboxusercontent.com/u/86097728/client-0107-012108.plog
Since no texture or rendering changes related to textures have occurred recently, I am operating under the assumption that its your hardware or something in between.
Once we rule that out, then we can move on.
Are you using the 1 Gb texture setting, and is that still producing worse results for you? (as far as stuttering goes)
After reviewing your plog, i can say that your intermittent connection issues are definitely caused by the performance in game (your GPU in particular) - not your network.
What about GPU-z? It's just a single window that shows your video card's clockrates and other info. Important to run that at the same time you are having issues so you can alt tab (temporarily use Fullscreen Windowed for reliable alt tabbing) to it quickly and ensure that all the data matches what your card SHOULD be getting by default, according to the manufacturer (especially the clockrate).
WHEW you were'nt joking about getting stuttering, look at this!
Those green spikes shouldn't be that extreme
The frames preceding to that hitch are D3D9Shader:ApplyTextures ... they increase until it looks like it essentially jams up and freezes and produces that WaitingForBufferedFrames
Looks like the game is waiting on your video card for some reason (like i mentioned in the previous post) - creating pauses that are more than 1 second long!
At this point, once you rule out the health of your GPU with GPU-z and the texture settings used for it, I am suspicious something is running in the background stealing your resources...
Are you familiar with how to control what loads during windows boot? Start > run > msconfig.exe > Startup tab > Check ONLY the windows/microsoft essential stuff. (as well as drivers)
Reboot. Check background processes with task manager, and ensure you don't see anything suspicious running.
People have had their GPUs turned into Bitcoin mining machines by viruses before, so it's worth checking.
GTX-480 & AMD Phenom 2 955BE Quadcore @ 3.6ghz, 4GB ram.
If you are able to reproduce similar hitching as the OP, please follow the instructions I provided earlier in here for making a PLOG, so that I can compare and confirm what you are saying.
Symptoms can often be similar but with different culprits.
Thanks for your input in any case!
Aero: Disabled for a long, long time.
Texture handling: For some reason this performed a lot better after nuking the settings file and starting from scratch, I have none of the texture handling issues I had before and I would say that it delays the onset of my issue on average. I am still encountering the stuttering, however. I might have used the wrong setting before, as poking it to 512 produces issues similar to what I remember. So overall this setting is helpful, but not a fix.
Unwanted processes: Checked, cleaned, scanned with MSE+malwarebytes, no issues besides a rogue tracking cookie.
GPU-z: All settings normal (while running windowed) EXCEPT...
and here's where it gets just plain odd: The issue does not appear, whatsoever, while playing in "windowed" mode. I have not tried "fullscreen windowed", but I did another round in plain old fullscreen to check that I am still experiencing the issue, and I am.
So obviously GPU-z is reporting everything is green when everything is, indeed, working just fine. I'm not sure how to proceed at this point, maybe start a log with GPU-z, load up fullscreen, and play until it appears? That would be a hell of a log file to review, though....
No worries! Just perform the actions you did previous to encounter this issue (including playing for a really long time). Start a PLOG right after you start experiencing any ill effects, and viola, we'll be able to analyze just what's making this nasty bug.
After extended playing, it stuffs itself so full of RAM that it crashes.
Only solution so far has been switching back to DirectX9 where - for whatever reason - it doesn't occur.
The only reason I can think of why windowed mode would produce smooth frames in comparison is because it is enabling Vsync / buffering frames.
This allows your GPU to rest, essentially... but it has a downside : ~20 FPS less as well as increased input delay. (1 extra frame, so 16ms @ 60 fps, and 32ms @ 30fps)
It's essentially the same as being fullscreen but using Vsync in the graphics options.
I am still not convinced that your card is not failing, however. It can't just be poor performance / age... other cards similar to yours run (albiet poorly) without those hitches.
Have you ran any artifacting tests?
EVGA OC Tester or ATI tool or even Furmark and OCCT tester and Kombuster - are all GPU stress tests, with the first two able to error / artifact check your GPU.
If they display no artifacting and no loss of performance (you should be watching GPU-z when these are running to ensure its not downclocking itself) then I guess it just has to be the old performance of your card.. and you can try that ultra low res mod : http://steamcommunity.com/sharedfiles/filedetails/?id=189793180
edit: confirm you have reinstalled directx?
edit2: confirm that you cannot reproduce the issue when using fullscreen + Vsync
I apologize for the delay in responding to this, life got busy... but that's also what allowed me to figure it out. With a changing schedule I started playing NS2 at other times and other things during times that would be NS2... which then started experiencing odd issues with performance. The specific nature of the problems lead me to delve into my system and chart WHEN these issues appeared...
I won't bore you with the incredibly odd exacting details, but SOME combination of the BITS and windows update services, with my own unique series of windows updates, leads to some incredible system errors. Like it not realizing that I'm at the computer. And prioritizing peak time as "downtime" to suck up up to 1.8GB of memory while strangling the private memory addresses of everything else. I was playing in such long sessions that i was literally running into the times when windows thought I'd be asleep.
Disabling BITS ***and*** all automatic functions of windows updates has fixed the problem for me, at least until I can bother re-imaging my machine. But the error itself is simply windows strangling the memory out of every other process - just in case anyone runs into this similar set of circumstances.
Last thing: One of the reasons I couldn't immediately determine that my system was actually using this memory is because it was, essentially, hidden inside normal system processes. Obviously windows update isn't supposed to eat ~2GB of memory, but who expects to check? Chalk it up to user error, I suppose. Thanks for the support xoxoxoxo
In any case, thanks for the in depth report... very very odd, still..
I believe it is.
You absolutely do not want to run with either windows updates or bits off, and I strongly suggest to reinstall (or possibly fix) as soon as possible.
Fun detail, windows support in terms of updates on a supported OS, (vista or higher) are free to all. (mail)
Bits basicly downloads stuff on the background in terms of bandwidth. This used to be a utter royal pain, but has been fixed long long long ago.
There is also absolutely no reason any windows update should grab that memory.
I would expect worse cause scenario and not wait on that reinstall.
Do not assume that its theirs by default, its actually rare that such bugs make it into live.
Anyway, to continue on the track of reporting we'd first need to know what actually is truly wrong.
Bits is MS software yes, but non MS software can call upon such things so the culprit may very well not be MS based.