It's been 6 months since I asked about the stutter

[SessoSaidSo]

Hi.

So back in July I was pretty upset about the stutter or micro freezing as it may be known. Now it's been pretty much concluded it is due to the GC of Unity 4.x, and I have been playing 1.0.5 and see it is worse than ever.

For reference I play off a custom rig running:

Windows 10 Home

i7-5820k

GTX 980 Ti

16 GB DDR4

I generally use a resolution of 2160p or 1440p

I have run the game from the following 3 drives:

SM951 256 m.2 SSD

850 Pro 256 SATA SSD

840 EVO 512 SATA SSD

I go back and forth playing the game with DirectX and OpenGL. Problem persists either way, so I generally stick to OpenGL for performance reasons(RAM savings are significant).

No. I do not spend all my money on computer parts. I work for a large IT vendor. 

I believe back in July I came off as a Kerb-Hole, for which I apologize. I am interested in understanding if the GC issue is a currently acknowledged issue from Squad and if the team is aware of its presence (or lack thereof) in Unity 5.x. 

 

TL;DR...too bad. Go Back up and read it.

[Rocket In My Pocket]

I've played KSP on 4 different computers from low end to high end over the years and I've never had this problem even on my 10 year old laptop with an integrated card I used to use. Even when playing on lowest settings at barely 30 frames it never micro stuttered or hung up. (And yes I know what that looks like, I've had the same problem your describing with other games.)

Must be specific to certain comps/gfx cards/drivers/etc..., hopefully someone else who has experienced this can help you out. The next major update will see KSP move to the newest version of Unity so possibly that will solve your problem?

Welcome back and best of luck!

[Speadge]

8 hours ago, SessoSaidSo said:

Hi.

So back in July I was pretty upset about the stutter or micro freezing as it may be known. Now it's been pretty much concluded it is due to the GC of Unity 4.x, and I have been playing 1.0.5 and see it is worse than ever.

Little addition for those who are not common with "GC":
"Garbage-Collection" is a feature in the engine running every x ticks to cleanup data that is not needed anymore.

About your problem at all: I whink most of us need to understand first if you are having a problem with KSP compared to other users (i.e. extra-freezing) or are you just expecting way to much frames than many others are.There is a mod called "GC-Monitor" which may help to visualize what you are experiencing. Also a Screen of the "Performance"-Window in flightmode (moderate craft, 0.04 physics delta) would be nice to understand whats going on.

Can you also compare it to a complete vanilla installation? (You are posting in unmodded, but since you want to save memory in OGL-mode, i dont believe you are running vanilla @ all )

 

I think with those information we might bring up some better suggestions than "wait for u5" like some ppl do now...
 

[swjr-swis]

One thing I've noticed caused some noticeable stutter, at least in the VAB/SPH, is the ground crew Kerbals. It removes a little bit of graphics bling, but there's a setting to disable those, and it would at least help while building.

Scatter is also something that seems to cause fps drops and stutter for some. This is also something you can either turn down or disable entirely in the settings.

In the flight scene.. there's been a recent thread (here) where some people complained about the animated portraits of Kerbals on a craft (lower right of the screen) causing fps drops for them, which could seem like stutter. A workaround is to remove the INTERNALs of crewed parts, so the portraits don't show, and it's been reported to give a slight increase in fps. Again, at the cost of some bling, but if you find fluid graphics more important, it might be an option to consider.

 

Other than the above: I haven't seen any specific mention in release notes of a fix for graphics stutter, no. There's a bug tracker though where people report problems and SQUAD keeps track of issues - if you consider this to be a real issue and can provide a reproducible use case, you would likely get more attention to this if you post it there. This thread explains how to best put an issue to the attention of SQUAD, including a link to the bug tracker to check if your isue is already known or even already worked on.

[anarkhon]

9 hours ago, SessoSaidSo said:

Hi.

So back in July I was pretty upset about the stutter or micro freezing as it may be known. Now it's been pretty much concluded it is due to the GC of Unity 4.x, and I have been playing 1.0.5 and see it is worse than ever.

For reference I play off a custom rig running:

Windows 10 Home

i7-5820k

GTX 980 Ti

16 GB DDR4

I generally use a resolution of 2160p or 1440p

I have run the game from the following 3 drives:

SM951 256 m.2 SSD

850 Pro 256 SATA SSD

840 EVO 512 SATA SSD

I go back and forth playing the game with DirectX and OpenGL. Problem persists either way, so I generally stick to OpenGL for performance reasons(RAM savings are significant).

No. I do not spend all my money on computer parts. I work for a large IT vendor. 

I believe back in July I came off as a Kerb-Hole, for which I apologize. I am interested in understanding if the GC issue is a currently acknowledged issue from Squad and if the team is aware of its presence (or lack thereof) in Unity 5.x. 

 

TL;DR...too bad. Go Back up and read it.

Hi SessiSaidSo!

This bug just old like KSP,here is the cure: At the <Nvidia Controll Panel> , set the <Maximum pre-rendered frames> to 1.

[Speadge]

15 minutes ago, anarkhon said:

This bug just old like KSP,here is the cure: At the <Nvidia Controll Panel> , set the <Maximum pre-rendered frames> to 1.

please dont quote _whole_ posts that are so long..

To your comment: is there any source where u learned that? Im running fine with <4> on this setting.

Edited January 9, 2016 by Speadge

[SessoSaidSo]

5 hours ago, swjr-swis said:

One thing I've noticed caused some noticeable stutter, at least in the VAB/SPH, is the ground crew Kerbals. It removes a little bit of graphics bling, but there's a setting to disable those, and it would at least help while building.

Scatter is also something that seems to cause fps drops and stutter for some. This is also something you can either turn down or disable entirely in the settings.

In the flight scene.. there's been a recent thread (here) where some people complained about the animated portraits of Kerbals on a craft (lower right of the screen) causing fps drops for them, which could seem like stutter. A workaround is to remove the INTERNALs of crewed parts, so the portraits don't show, and it's been reported to give a slight increase in fps. Again, at the cost of some bling, but if you find fluid graphics more important, it might be an option to consider.

 

Other than the above: I haven't seen any specific mention in release notes of a fix for graphics stutter, no. There's a bug tracker though where people report problems and SQUAD keeps track of issues - if you consider this to be a real issue and can provide a reproducible use case, you would likely get more attention to this if you post it there. This thread explains how to best put an issue to the attention of SQUAD, including a link to the bug tracker to check if your isue is already known or even already worked on.

I have actually created two prior threads regarding this issue and many have come forward acknowledging they have this same problem. It may very well be that only certain people actually notice this issue as it appears to be fairly good mix of hardware that can reproduce this. 

Please see this video I posted on Youtube in July: https://www.youtube.com/watch?v=fI0Rx6dwJEc&feature=gp-n-y&google_comment_id=z12wt1ehdmvftt33522bijkb0kbgzz3p504

Again, this is not an FPS issue, this is a literal freezing of the game that occurs in intervals of 2 to 10 seconds. It's actually incredibly easy to recognize using mechjeb; if you pay attention to your dV stat and watch the numbers change during a burn, you will see the numbers stop for a moment and then resume. DO NOT take this to mean it is a mechjeb issue, I say this to only give an idea of how to spot this issue. 

In the past 2 threads created, Squad has never given a response and in fact many posts have tried to flat out deny this problem exists usually blaming my hardware. I upgrade my hardware every 3 or 4 months and I have had this issue for years. Played this game on Win 7, 8 and 10. 

[SessoSaidSo]

6 hours ago, Speadge said:

 

Can you also compare it to a complete vanilla installation? (You are posting in unmodded, but since you want to save memory in OGL-mode, i dont believe you are running vanilla @ all )
 

Also note that I said I experience the issue in both DirectX and OpenGL so I primarily just use OpenGL for Ram performance. 

As I said before, I believe everyone experiences this, I can see it in so many KSP videos, however, I believe only certain people actually notice it. 

[Waxing_Kibbous]

Are there specific repeatable times when these lags occur? The only lag I get is when coming back to Kerbin from a different body, around 160,000m up which I believe is when the higher res textures are loading. Other than that, off the top of my head when rotating the view I will get choppiness on occasion. One of my concerns is the number of graphics options to choose from, and the arcane descriptions of what they do.

[SessoSaidSo]

1 hour ago, Waxing_Kibbous said:

Are there specific repeatable times when these lags occur? The only lag I get is when coming back to Kerbin from a different body, around 160,000m up which I believe is when the higher res textures are loading. Other than that, off the top of my head when rotating the view I will get choppiness on occasion. One of my concerns is the number of graphics options to choose from, and the arcane descriptions of what they do.

Did you go look at the video I posted? No? Again, and this is the frustrating part; this is not an FPS issue, this is not a loading issue. I do not understand why these types of questions are asked. This is a well described phenomenon of which I have included a video. 

I am not looking for community support. I am not looking for someone to say, "oh, ya, the solution is...".

My question was simple and direct. Is the issue persisting within the KSP versions compiled in Unity 5.x 

This is a massive bug which I have never seen Squad make mention of and I would like them to work on. I am not a community tester. I do not get paid to fix issues.

[Speadge]

hi,

checked the video and seen, that it is on the 18/19th  second most noticeable, not before, not after... Are you sure its the GCs fault? did u try the monitor i suggested?

P.S.: As u dont want help - im not here to help you, just to understand for myself why i dont have this issue :P)
Edit: ok, tried the VAB-scene. seems to be default that the truck is "hanging" somehow... never bothered me before

Edited January 10, 2016 by Speadge

[Guest]

I'd expect some of this to be fixed in unity 5.

[Waxing_Kibbous]

4 hours ago, SessoSaidSo said:

Did you go look at the video I posted? No? Again, and this is the frustrating part; this is not an FPS issue, this is not a loading issue. I do not understand why these types of questions are asked. This is a well described phenomenon of which I have included a video. 

I am not looking for community support. I am not looking for someone to say, "oh, ya, the solution is...".

 

So, your issue is that the truck stops, then goes again? Seriously? You are right, the issue is neither an FPS issue nor a loading issue.

I think the well described phenomenon you are referring to is called "animation."

[SessoSaidSo]

1 hour ago, Waxing_Kibbous said:

So, your issue is that the truck stops, then goes again? Seriously? You are right, the issue is neither an FPS issue nor a loading issue.

I think the well described phenomenon you are referring to is called "animation."

Do me a favor. Do not post on my thread if you are not going to be contributing productive dialogue. 

Watch the video i posted, then you have my permission to return.

[steve_v]

@SessoSaidSo I take it you are referring to this thread? If so, I am also waiting for some news. It's been a long time now with no improvement.

4 hours ago, Waxing_Kibbous said:

 think the well described phenomenon you are referring to is called "animation."

I think you are wrong. Go read the thread I just linked, and try one of the easy tests mentioned there.

-----

6 hours ago, CliftonM said:

I'd expect some of this to be fixed in unity 5.

If this is, as I suspect, caused by the brain-dead GC code in the ancient version of mono that Unity uses... that has not changed in U5.

If it's the GC at fault (and I'm pretty sure it is), the only solution short of unity upgrading their mono runtime is to create less garbage. This is something Squad could, and should be doing.

Edited January 10, 2016 by steve_v

[sal_vager]

Demo Unity4 projects also show this stutter albeit less severe as they have fewer game objects, so it's not garbage as actually freeing unused resources is very fast, you just call free() on it and move on.

What makes the Unity version of Monos GC slow is that it walks the entire memory heap looking for something to free, so the more objects you have the longer it takes.

Look it up if you like here, here, here and here.

It does this automatically and periodically when free space is low, there is no off switch.

So it's not a case of too much garbage, or in fact any garbage, if you actually watch KSP's memory use while it's running it's not fluctuating that much, there's not much that isn't in use for the GC to remove.

When you have a lot of objects the Boehm–Demers–Weiser garbage collector used by Mono is slow, whether there is anything to free or not it's still going to walk the stack looking for objects to free.

So any attempts to reduce garbage by Squad would have no little effect on the stutter, Squad has already optimized several parts of KSP.

 

As for Unity5, there are benchmarks from other software available to make comparisons, and the inclusion of a newer PhysX should might mean that  physics can continue on another core while the GC is collecting, preventing it from blocking the simulation (ie the stutter)

But we won't know until KSP 1.1 is released, or until performance is discussed in the devnotes, so keep an eye on the devnotes for news

 

Edited based on Padishars comments, added stuff is in italics.

[steve_v]

18 minutes ago, sal_vager said:

What makes the Unity version of Monos GC slow is that it walks the entire memory heap looking for something to free.

This gells with my own experimental tinkering with Unitys mono build - the 'mark' (heap crawl) phase is the main culprit. Giving it something to collect does however exacerbate the problem.
The properly frustrating thing is that this has been much improved in upstream mono, and quite some time ago. Unfortunately Unitys build has diverged too far to backport those features, or drop in a more recent runtime.

As usual, commercial entity forks open-source code for their own purposes, and promptly makes it incompatible with and inferior to the original project.

Edited January 10, 2016 by steve_v

[sal_vager]

Absolutely, and I hear Unity won't upgrade Mono any further, but the replacement also uses the Boehm–Demers–Weiser garbage collector (libgc).

Interestingly, it contains the goto command. which looks a bit Basic to me.

[Padishar]

@sal_vager While there is an element of truth about the slowness of the GC in your post, the conclusions you come to are way off the mark

Firstly, yes, the garbage collection does run automatically but describing it as periodic makes it sound like it happens at a fixed interval and this is not the case.  Mono has a heap of a certain size and when the amount of free space in the heap drops below a threshold it runs the garbage collector to free up any objects in the heap that are no longer being used.  Only if it can't free up some space does it increase the size of the heap.  So, the fact that the memory used by KSP doesn't fluctuate much doesn't say anything about how many objects are being allocated and released.

Secondly,

56 minutes ago, sal_vager said:

So any attempts to reduce garbage by Squad would have no effect on the stutter.

This is so patently untrue that you really should withdraw this statement or you risk looking like a complete idiot.  The GCMonitor tool (or just thinking about it for a minute) clearly shows that if some code allocates 1000 objects and discards them immediately and does the same on every frame then the heap will fill up with released but not collected objects much faster and the GC will run much more frequently.

Thirdly,

56 minutes ago, sal_vager said:

As for Unity5, there are benchmarks from other software available to make comparisons, and the inclusion of a newer PhysX should mean that  physics can continue on another core while the GC is collecting, preventing it from blocking the simulation (ie the stutter)

This is a rather optimistic conclusion given that, while the GC is running, other threads are not able to allocate any memory on the heap.  The PhysX threads may be able to run while the GC does but this won't affect the stutter as that is a pause in the calls to Update that Unity makes each frame because it is unable to allocate memory.  That it why you get a stutter, nothing to do with the PhysX calculations.

Edited January 10, 2016 by Padishar

[steve_v]

4 minutes ago, sal_vager said:

Absolutely, and I hear Unity won't upgrade Mono any further, but the replacement also uses the Boehm–Demers–Weiser garbage collector (libgc).

This is not what I wanted to hear, but they do mention improvements to the GC problem, so... maybe some optimism?

6 minutes ago, sal_vager said:

it contains the goto command.

Ouch, we all know what happens if you use that.

[sal_vager]

The 3rd point is optimistic because I'm being optimistic over Unity5's performance, I'd rather do that than be pessimistic, I'm hoping for the best.

As to the second point, please show me where KSP is allocating and removing 1000 objects on every frame as I find that unlikely, you make it sound like KSP is making and removing 1000 Kerbals or 1000 GUI's, which would have a much larger impact than we actually see.

Unless you mean it's updating 1000 objects, which it may be doing with the PQS terrain but also seems a rather high number, and creating temporary variables which are automatically removed when those functions go out of scope is normal, but other objects in use aren't garbage and won't be freed.

Thinking about it for a minute doesn't lead me to your conclusion, sorry.

As for the first, the stutter is pretty regular, thats periodic enough for me.

[steve_v]

16 minutes ago, sal_vager said:

Thinking about it for a minute doesn't lead me to your conclusion, sorry.

Perhaps not, but the obvious change in GC frequency when there is much garbage being generated might. Example.
This is also an example of Squads code rapidly generating garbage, and reducing such would certainly improve matters, if only in this specific case.

16 minutes ago, sal_vager said:

As for the first, the stutter is pretty regular, thats periodic enough for me.

Casual observation does not data make.

Also, as Padishar points out, this has nothing to do with PhysX. GC not interrupting the physics thread is irrelevant if no managed code can allocate memory - everything else will still have to stop.

Edited January 10, 2016 by steve_v

[sal_vager]

I'd have chosen a better example that that, he is after all using 80 fuel cells, that's a lot, it doesn't matter what game it is you're going to reach its limits at some point unless it caps you, such as the unit limits in RTS games.

Fact is I don't know what is going on inside KSP, I don't know if it's Squad code or Unity that is causing this, and I don't know if Squad has already added free() to their objects to remove them and it's being deferred by Unity.

Only the developers could tell us that.

I also don't know if the GC can run at the same time as PhysX, which is why I said "should" not "will", we'll all have to wait and see just how things improve if at all.

I expect that performance be better for some, same for others and there's the chance it'll be worse for a few, there's just too much variation in players PC's to know how it'll be on any given computer.

But I hope it'll be improved.

[steve_v]

2 minutes ago, sal_vager said:

I'd have chosen a better example that that, he is after all using 80 fuel cells, that's a lot, it doesn't matter what game it is you're going to reach its limits at some point unless it caps you, such as the unit limits in RTS games.

Well, the point of that was simply to show that the frequency of GC runs is not static. 80 fuel cells may be a lot, but extreme conditions make for an extreme change in GC behaviour, and therefore a clear example.

[Padishar]

57 minutes ago, sal_vager said:

The 3rd point is optimistic because I'm being optimistic over Unity5's performance, I'd rather do that than be pessimistic, I'm hoping for the best.

Well, you will almost certainly be disappointed (or would be if this issue affected you).  I'd rather be pessimistic so at least there's a small chance of being pleasantly surprised.

57 minutes ago, sal_vager said:

As to the second point, please show me where KSP is allocating and removing 1000 objects on every frame as I find that unlikely, you make it sound like KSP is making and removing 1000 Kerbals or 1000 GUI's, which would have a much larger impact than we actually see.

Now that you're Squad staff, ask one of the devs to show you the source of the ResourceConverter and ResourceBroker classes.  For a vessel with a reasonable number of parts that hold EC, it only takes a couple of fuel cells to end up with well over 1000 objects (any instance of a C# class allocated with new and also things like adding an item to a full List<T>) being created and deleted each physics frame.  This isn't the only example, there are many other bits of code that create pointless garbage.

Do you accept that the more garbage the game creates, the more often the GC will run?  Logically, it follows that reducing the amount of garbage created will lessen the frequency and, if tackled seriously so that almost no garbage is created during scenes, the GC would almost never need to run and forcing it to run when the user wouldn't notice a small glitch (e.g. when saving or loading, when bringing up the pause menu, switching to/from map view etc.) could probably eliminate the noticeable stutters completely.

57 minutes ago, sal_vager said:

As for the first, the stutter is pretty regular, thats periodic enough for me.

Yes, periodic it is, but that says nothing about the frequency.  If less garbage is created it will run less often.  One call per hour would also be periodic but no-one would complain about it.

Edited January 10, 2016 by Padishar