Padishar

Firstly, while the garbage collection process (at least all the ones that are in common use) is occurring, nothing else must be allowed to allocate any memory or change the contents of any reference variable because the collector has to determine which blocks of memory are still being used and it does this by first assuming that all blocks are no longer needed and then scanning through all the memory looking for block references which it then marks as still used. Theoretically, there are ways to implement a garbage collector that doesn't "stop the world" for any appreciable time but they would result in the allocation of memory taking significantly longer which is one of the main reasons for using a garbage collector mechanism in the first place. The garbage collection process in KSP can take anywhere from <10ms to >500ms depending on the speed of the CPU, the speed of the memory access and the size and number of memory blocks that are allocated. At 60fps there are <17ms per rendered frame so, if the game is paused for even 10ms, it is quite likely that the next rendered frame will not get done in that 17ms resulting in a stutter. A more usual (for KSP) time would be 80-120 ms so you will miss between 5 and 7 frames of the 60 that should occur in a second. If the GC takes 500ms (for whatever reason) then you will lose half the frames... Garbage collection is only used by some programming languages (well, strictly speaking, language runtimes) such as Java and C# (or other .NET/Mono based languages). A lot of games (and underlying game engines) do not use it precisely because of the stalling issue. If you have to explicitly code the releasing of unwanted memory (e.g. in C or C++ using the standard allocators) then the programmer has control over when the CPU is used to do it rather than letting the language runtime decide to do it when it feels like it. Those games that are GC based and don't stutter have simply been written in such a way that they do not create significant amounts of garbage during normal gameplay. As you can see from Tig's graph, his game produces somewhere between 10 and 20 MB of garbage every second, so code is allocating and discarding more than 300 KB of memory for every 60fps frame that is rendered. After using the heap padding feature his stutters are approx. one minute apart rather than 15 seconds apart but, if KSP were only creating 30KB of garbage each frame then they would be 10 minutes apart and could be deliberately triggered when the user wont notice the pause. Yes, all of these things can reduce the perceived stutter and, in combination, can reduce it to a level where it is effectively unnoticeable. However, the most important part is creating less garbage. The same is true in any language, if you're trying to write a program that requires consistent, fast performance, then you don't waste CPU cycles constantly allocating and releasing temporary memory. If you do it in any GC based system you will get a stutter, do it in a non-GC system and you will simply get poorer general performance. If any game written in C or C++ did 10000+ calls to malloc/free/new/delete every frame, it would be very unlikely to manage 60 fps...

My apologies, I totally missed this earlier. UnanimousCoward is totally correct...

I also get the server migration page when going directly to this link: https://kerbalspaceprogram.com/lib/highwindsDwn.php?version=win-1-1-2 I don't have an account but that looks like a maintenance gate has been enabled while maintenance was being done that happens before any authentication. Could this have something to do with the issue the night before last when both the forum and bug tracker (and presumably the store too though I don't use it so didn't check at the time) disappeared for at least half an hour at about midnight GMT? Most likely I would have thought was that something was "fixed" and somebody forgot to disable the maintenance redirect... Edit: actually that link is the maintenance page itself, so I can't tell what link is actually being requested that is causing the redirect (assuming the links on the download page aren't direct to the maintenance page for some odd reason).

First, I understand your frustrations but use of that sort language to describe issues is not constructive and doesn't really encourage anyone to help you (e.g. if you posted anything like it in any mod thread that I develop then you wouldn't get help from me). Secondly, the garbage collection stutter is not the same thing as "microstutter" and I really wish people would stop confusing the two (both here and on the Unity forums). Microstutter refers to the very slight stuttering that you can see in the animation in some Unity games due to aliasing effects between the physics update rate and the frame rendering rate not being correctly accounted for. The garbage collection stutter, as it can often pause the game for up to half a second for some people, really can't be described as "micro" without the application of an entire lorry-load of salt... Third, well done for actually posting a log and dxdiag rather than just an unhelpful rant as so many are fond of doing...

Good work. Hopefully those folks can help further with diagnosing/fixing the actual problem...

As Kandjk asked earlier, is there any set time scheduled (and any estimate of the length of the downtime)?

Thanks for more great feedback, very helpful. I'll try to get a more detailed reply up in the next few hours, including the detailed description of how the memory allocation works but, for now, I will say that most of the "not-really-problems" are understandable consequences of how the Mono heap works. As an example, yes, there is a reason for the positive slope between collections. The actual rate of memory allocation is a lot more constant but the memory allocator works on 4 KB pages and it groups allocations of similar sizes together into the same 4KB pages. E.g. if some code allocates an object that is 120 bytes in size then this will be rounded up to 144 bytes and allocated from a page that already contains other allocations of 113-144 bytes but isn't totally used (due to the extra padding the allocator adds to each block, 25 such blocks can be allocated in each 4KB page). Larger allocations (anything over 2032 bytes, where no more than one block can fit in a 4KB page) are handled a little differently, simply using as many 4KB pages from the free page list as are required. If there isn't an existing page with empty space for the correct size range of block then the allocator will take a page that is currently not used at all and add it to the list of pages used for that block size range. It's only when a page is added like this that the memory usage can be detected. If there are no free pages then the collector runs to free up space, either by freeing up a block in a page that holds the correct size range or by freeing up all the blocks in any page so the whole page gets returned to the free list and can then be assigned to a different block size range. So, immediately after a collection, there will be lots of 4KB pages that have some free space in them which results in some of the memory demand being taken from already allocated pages and they don't show up in the usage rate. E.g. it could be possible for hundreds of 144 byte blocks to be allocated without needing any new 4KB pages to be assigned to that size range. Once all the free space in the already assigned pages are used up, a new page will be assigned for every 25 such blocks that are allocated and the reported allocation rate will be much closer to the "real" rate. A couple of other observations: So much for the people that complain that the game is "unplayable" (without qualifying it with "for me")... The "not responding" dialog isn't really a "crash" warning. It simply tells the user that the program has not responded to a Windows message that it was sent, usually because it is busy doing something and isn't bothering to run the main message processing loop in the program. Most programs that do any kind of long calculation will do the same thing but often only when the user tries to interact with the program while it is busy (e.g. if you click on a busy window you will often trigger this dialog instantly because Windows sends the program a "click" message but it doesn't respond to it immediately). I suspect these may be caused by the game auto-saving (though every minute seems a little frequent so it may be some other regular housekeeping task that KSP does). Not a problem, you've been more than helpful. I used to use fraps every time I played the game and I've only ever seen this happen once though I've hardly used fraps with KSP 1.1. I spent a considerable time trying to repeat it but I couldn't. I switched from using fraps to using a mod to get better accuracy at low frame rates (fraps only displays integer values in its overlay and there's a lot of difference between 2 and 3 fps).

I guess you were typing that when I edited my first post. It's basically a case of technical debt built up during the early access development period that didn't get cleaned up before release. The devs are aware of it (and a number of others) and have plans to address them as soon as practical. I don't believe the stock game ever changes the mass of any parts while a vessel is on rails but some mods do. Any mass change could be communicated to the vessel directly rather than the vessel adding up the mass of all the parts every time. Unfortunately, while this should work quite nicely for resources being produced and consumed, it doesn't fit very well with the IPartMassModifier interface that mods can use to dynamically adjust the non-resource bit of part masses. However, I'm sure the Squad devs will be able to sort it out...

Unfortunately, this just isn't the case. There is a known inefficiency in the handling of on-rails vessels due to the game recalculating the mass of every vessel on every physics update. Not only does this use a considerable amount of CPU, but the code that does the calculations using the unloaded vessel data also creates a large amount of garbage. There are also other things that are calculated, such as heat effects and whether any on-rails vessels have entered the current physics bubble and need to be loaded. As a further test to flying the same ship in an empty save, you could also make a copy of your save and then terminate vessels in the tracking station a few at a time and see what effect it has on the frame rate. Another thing that might show interesting results is running my MemGraph mod (linked in my sig below) to display the memory allocation rate and garbage collection frequency. The heap padding feature probably wont help you but it's worth doing it on the off chance that your performance issue is actually due to the garbage collector running almost constantly. Edit: I also meant to say that the devs are aware of this issue and do plan to fix it though they might appreciate seeing any performance figures you come up with...

I nearly replied to this saying "Hey, you're following the same threads as me..." before I came to my senses... It's been a long day...

Do you have a trim applied? That could be causing your station to slowly spin up again after timewarp. Try hitting Alt-X to reset the trim and see if it stops...

Perhaps, rather than rotating the vessel to alter the inclination, you could leave the vessel pointed prograde/retrograde and use translation RCS to perform the adjustment burns? This should allow you to set the inclination accurately and then adjust the altitude (again, using translation RCS) without needing to rotate in between. Also, assuming you are running 1.1.2, then bear in mind there is currently an issue with decaying orbits, so I would get the inclination as close to correct as possible first, then set the Ap to ~704,800m and then set Pe to as close to the Ap as possible. Then, you can nudge the orbit sideways using RCS as you pass over the equator if necessary...

Well, assuming it is one or more particular parts then I would suggest finding the smallest vessel you have that reliably hangs and then create test vessels using the various parts that vessel uses (search the craft file for "part = " without the quotes) until you find one that causes it. Try to more unusual parts first, or compare a few different craft files to find the ones they use in common (if more than one then this could be tricky). Also, take a look at the end of the output_log.txt or player.log file to see if there is any indication of what the problem might be. It might also be an idea to upload a complete log so people can take a look for anything else that could be a concern...

I have implemented a mechanism that allows the mono heap to be forcibly extended resulting in it taking longer for the heap to fill up and the garbage collection to be triggered. This can considerably reduce the frequency of the stutters with the tradeoff of increased memory usage and each stutter being somewhat longer. This tradeoff may not be seen as a playability improvement by all people but I have plans to improve the padding mechanism both generally and by adding automatic tuning to fit the current heap usage pattern. There will be heap usage patterns that do not work well with the current code, most notably, it isn't yet possible to provide enough padding for large block allocations without Unity deciding to give it back to the OS so, if the majority of the heap usage is large block allocations then it may not affect the stutter much. I have added this code to my MemGraph mod (thread linked in my sig below). I would appreciate it if people that try it could follow the recommended process in the OP and provide feedback as described to help me develop this further...

In the Solution Explorer panel, drill down into the KerbalEngineer/References section. You should see various warning symbols indicating which KSP DLLs you need to add. Then right-click on the References section and select "Add Reference...". In the dialog that opens, click the "Browse..." button at the bottom and navigate to the <KSP>/KSP_Data/Managed folder and select all the DLLs that have a warning symbol in the solution explorer and click ok. This should set up all the required references for that sub-project to build. If you want (or need) to you can do the same thing for the KerbalEngineer.Unity sub-project (it needs a lot fewer references) but this only contains new UI API related code so you probably wont need to rebuild that bit.

Could someone kindly move this thread to the Add-on Releases sub-forum, please? Many thanks.

Thank you. That clearly shows that the reason the call to the stock GetExperimentBiome function is failing is because both the latitude and longitude of the impact point are being passed as NaN (not a number, an invalid numerical value used to represent undefined results). That should help to narrow down the cause... Edit: I have updated the zip in my dropbox with a speculative fix for the NaNs by clamping a calculated value that is passed to Acos to (-1,1).

And another: Any chance this issue could be forwarded to the authors of the forum software (Invision Power Services?) or, in fact, acknowledged in any, vaguely official, way...?

I assume from "LEO" that you are using RSS. If you are also using RealFuels then you should bear in mind (if you're not already aware) that there are currently issues with KER in flight that cause it to fail to calculate deltaV/TWR correctly for RF engines. If you're just using for VAB, design time, numbers then you should be fine. You may find that you also need to adjust the size of bits of the UI as some of it is quite tightly fitted and extending the length of the mass readouts may cause stuff to wrap strangely and look bad...

Yes, assuming you have the latest release version installed then, after building the source from GitHub, you should just need to replace the one DLL. However, are you sure you really need a resolution of 10 grams? Seems a bit excessive to me...

Actually, on linux and, possibly, OSX (any version that uses a shared library version of libgc), it should be possible to write a mod that talks directly to libgc to get more detailed information. This may require making some modifications to libgc (e.g. to add some sort of hook that would allow code to be run every time any memory is allocated on the heap) but this would probably be rather easier than delving into the whole of Mono. Of course, adding this sort of detailed memory allocation tracking would make the game run an awful lot slower and is basically what the Unity profiler does already so you may as well just use that. Another complication is in deciding whose "fault" a particular allocation is. If a mod calls a KSP function that allocates a lot of memory on every frame then is it the fault of the mod or of the KSP function. Some functions in KSP are not intended to be called on every frame so that would be the mod's fault and some functions are intended to be called often but still create far too much garbage which would be KSP's fault. So, to be a really useful tool, it would probably need to record (a substantial part of) the call stack for every memory allocation rather than just the actual function doing the allocation or the function from the "top-most" DLL involved. This would cause the game to run even slower still...

No, even recompiling everything with debug symbols wouldn't enable a mod to do that. You would need to be running a modified version (or at least a debug version) of mono and would probably need to make some significant changes to it before that would be practical (i.e. less hassle to implement than the trial and error method would be to use).

These two fairly recent threads (one in the "popular questions" section at the top of this forum) talk about what is probably the same issue (or closely related) and many variations on it have been reported over the years. Most likely is that some mod is causing the issue but I don't believe it is always the same mod. See the "How to get support" sticky thread (3rd one below) for details of troubleshooting techniques and, if you can't deduce the source of the problem yourself, details of what other information you will need to provide for others to attempt to diagnose it (logs, mod list, etc.).

As far as I'm aware, there are basically two ways to do it. Either you use this mod (or an alternative similar mod such as MemGraph, linked in my sig) and simply test with different combinations of mods to see which cause the highest rates of memory allocation, or you can run the game under the Unity profiler which should be able to give, at least, some indication as to which DLLs are responsible (though to get more accurate information would probably require rebuilding the mod DLLs including debug symbols).

Though you'll probably need to follow the advice in this thread: ...about what information you should provide to give people a chance of helping you...