Padishar

Yeah, I was being a bit picky with that part, the 1000x was the main point of my post. A bit more pickiness, "frames" (FixedUpdate) are actually a fixed length of 20ms (except in physics warp). Impulse is the integration of the force with respect to time, which, assuming a constant force over the period of a frame, is simply the force multiplied by the time. The units of this are Ns or kgm/s (as impulse is equivalent to momentum). I'd need to read the Unity docs to be certain (well, as certain as I could be) of how the value passed to AddForce is treated for the different force types but I think I would correct what you wrote above to say: It does sound very strange. Do your vessels have landing legs or wheels? Given their somewhat unstable behaviour in 1.1.2 I would avoid using them in your tests to rule out any possibility of an odd interaction...

I think you've made a mistake with your units here: ...so your results are 1000 times too small and the units should be m/s².

You have a very strange definition of the word aggressive. KER usually calculates stages as they appear in the staging list. When the currently active engines are not consistent with the staging (i.e. you have enabled or disabled any engine) then it calculates an extra "stage" using the currently active engines burning until they run out of fuel and then continues with the normal staging process. There does appear to be a bug with the burn time, possibly because it isn't using this extra stage in its calculations or possibly because of something more involved. I play very little KSP compared to most of the users of KER, I generally don't need to time burn starts with the extra accuracy that KERs calculations are supposed to give and I generally don't use vessels whose staging is set up in any way that is likely to cause problems for KER. Now that I am aware of the issue it will be investigated (in the fullness of time) and probably fixed.

Well, I was expecting to find a significant amount of log spam while you were EVA but that appears to not be the case. There are some messages from ScanSat about building heightmaps, which, if it is being done in the background or in chunks via a coroutine, might cause a problem like this. The first time you went EVA, Kopernicus gave the following exception: NullReferenceException: Object reference not set to an instance of an object at Kopernicus.Configuration.Asteroids.Location+RandomRangeLoader.op_Implicit (Kopernicus.Configuration.Asteroids.RandomRangeLoader loader) [0x00000] in <filename unknown>:0 at Kopernicus.DiscoverableObjects.SpawnAsteroid (Kopernicus.Configuration.Asteroids.Asteroid asteroid, UInt32 seed) [0x00000] in <filename unknown>:0 at Kopernicus.DiscoverableObjects.UpdateAsteroid (Kopernicus.Configuration.Asteroids.Asteroid asteroid, Double time) [0x00000] in <filename unknown>:0 at Kopernicus.DiscoverableObjects+<AsteroidDaemon>d__10.MoveNext () [0x00000] in <filename unknown>:0 ...which may have left something in a dodgy state. The same exception happens the second time you EVAd though it appears you jetted about a bit (or jumped) because your state switched between landed and flying several times before the exception happened. This exception only appears to happen when you are in EVA so could well be related (or you may just not have spent enough time in the vessel for the asteroid spawn code to be run). There are also a number of exceptions from other mods that should probably be looked at by the authors: MKS.LightGlobe is causing an exception during part loading. KIS is reporting that it is ignoring a couple of exceptions during part loading when it should be simple to avoid the exceptions completely. KAC is giving a couple of exceptions when switching into the flight scene. MJ has caused an exception when switching from the editor to the spacecenter. My first suggestion would be to try repeating it in an install that doesn't have ScanSat and, if that doesn't help, try in an install without Kopernicus (and whatever planet mods). This may require you to create a new save and launch a new rocket, but it shouldn't take long.

Unless you happen to have one mod that's generating an insane amount of garbage (this is possible though I would have thought it unlikely) then this would probably be better off being posted as a new thread in the Technical Support (modded installs) sub-forum. Please read the "How to get support" sticky thread in that sub-forum for lots of general advice on how to troubleshoot problems and also details of what other information you will need to include if you're unable to solve the issue yourself.

Calling Gravity semi-realistic is an insult to halves everywhere...

Thanks for confirming that, it probably explains some of the inconsistencies in GC timing I've seen. Nice to see a Unity dev (I assume you're a dev if you risked delving into that code ) in this forum... Indeed. While there are certain things that are quite difficult to do without creating some garbage, there are very few things that couldn't be optimised to generate considerably less than at present. Most of the really rampant garbage creation (in both stock KSP code and in mods) is simply badly written code that ignores the garbage issue completely (e.g. using complex LINQ queries that result in temporary iterators and allocation of intermediate result arrays, writing functions that create and return a new List even if it's empty, etc). Yes, Squad are aware of the issue, exactly what bits of code are at fault and have plans to look at it soon™. I usually report them to an internal tracker I have access to (due to being on the experimentals team) or just discuss them directly with a Squad dev in IRC to see if they are already known about. No comment... Actually, I will comment, I think it's obvious that very little profiling gets done given that some of the code is so obviously bad just looking at the source. There are lots of bits of code that flat-out ignore all the guidelines for reduction of garbage creation and general CPU efficiency. Hopefully it will continue to improve...

Not to mention that the code to dynamically unload and load them would probably generate more garbage itself unless it were very carefully written...

So, you mean by patching or overriding various bits of stock code? Yes, it should be possible to fix a lot of stuff but the extra hassle to actually override some stock code from a mod rather than just sending the code changes to Squad for possible inclusion in the next update, don't really seem worth it to me. However, I would support and probably contribute to such a mod, especially if it were a single mod containing multiple such fixes. Edit: oh, I meant to add that even though the garbage creation you describe adds up to 1170 KB/s for a machine doing 60fps, if you had another few (large) vessels in that save (e.g. a couple of thousand parts in total) then that would be a minimal part of the total usage (see the platonic stations examples in the MemGraph thread). Yes, the editors generate a lot of garbage displaying (or even not displaying because it still happens when switched to crew or action groups) the part categories. The more parts in the category, the more garbage is created. There is a post somewhere in this thread or the MemGraph one that mentions this. This is (I presume) the "main editor GC problem" that xEvilReeperx mentioned...

There's nothing of the sort in my post and I resent the implication.

I suspect, though I haven't got any real evidence to back it up, that they have tried to use some of the more advanced features of the Boehm collector to make it less conservative, e.g. by using the Mono type information to determine that a block can't contain any references to other blocks and therefore doesn't need to be scanned, or even, to make the scanning itself use the type information to only check those memory locations within a block that actually are reference types. It wouldn't surprise me if these changes were not thread-safe as, with the option turned off, they don't need to be. I have devised a method of padding the Mono heap with quite a lot of extra empty headroom that doesn't get eliminated after one or two runs of the GC. This should increase the time between stutters considerably (anywhere from 2 to 12 times depending on the current pattern of heap usage) though it does make each pause somewhat longer. The code will probably be improved further in the coming days/weeks but you can try it out by installing the latest version of the MemGraph mod linked in my sig. Get into a situation where the stutter is bad and then hit Mod-End. After a short while (at least 2 or 3 runs of the collector), you can try hitting it again, which will reset the padding and may improve it further. Please reply in either this thread or the MemGraph thread with any observations, either qualitative or quantitative (but as with any kind of report, details of your system, mod setup and what you were doing would be helpful). Yes, that was the entire purpose of my MemGraph mod. I've already passed on information about a number of stock areas of code that create excessive garbage and am continuing to look for them as reducing the amount created is still, by far, the best way to reduce the annoyance of the stutters... While targeting code that creates 1.5 KB/frame will have an effect (and it will be considerable if lots of such code is fixed), I'm, initially, more concerned about situations where stock code allocates much more. I have a number of saves where the garbage creation adds up to 20+ MB/s resulting in the GC running every 3 to 4 seconds. This padding of the heap extends that to approx. 20 seconds between collections which, even with the pauses being noticeable longer, is considerably nicer to play (in my opinion).

Actually, the way I read it is that it starts with several rhetorical questions (a long way from a "rant") about some other members of the forum who happen to be behaving in ways that don't make any logical sense and I can't see any personal insults, to you or any other member. There is controversy because most users of KER/MJ manage to use it fine with considerably complex vessels and, when they do have an issue with it, they get advice on how to get it to give more useful results. First, you are describing how the stock burn time works, not the KER one. The KER one uses the per-stage deltaV and burn time calculations to work out the burn time for a node. As for your "very basic and obvious example", you have two opposed active engines and are obviously running with the "vectored thrust calculation" setting turned off so it is assuming the engines are all pointing in the same direction. Try learning how to use your tools before claiming they don't work... As said above, this isn't how KER works. The logical flaw you are referring to is your own due to not using the tools correctly. You are making conclusions based on faulty premises. You appear to be the sort of person who is convinced they know enough about a subject to make definite conclusions about it but, in reality, your level of knowledge is far below the required level.

Great data again, thanks. I'm a bit disappointed by only just over three times, I guess it's probably tuned a bit too specifically to the situations I was testing. Hopefully, I should be able to improve that a fair bit with some analysis of the heap. The figures should also be better with fewer mods installed, though it is difficult to predict because there isn't any easy way to see how many blocks of what sizes are being regularly allocated. Not sure about 3, I'll have to think about it tomorrow (1:30 am here now and I need to be up at 7:30). Another thing that could reduce your stutter would be to set a lower fps limit. Currently, the 16-20 MB/s is being generated by 120 rendered frames and 50 physics updates. It is hard to say how much is being done per rendered frame and how much is per physics update but changing to a 60 fps limit could significantly reduce the rate of garbage creation...

Well, the process uses the CPU so the faster the CPU, the shorter each pause will be. The amount of work to be done depends on the total number and total size of all the allocated memory blocks but the relationship is slightly complex due to the multiple passes the GC performs. I've now released version 1.0.0.6 of MemGraph that includes Mod-End to allocate a large chunk of heap headroom. In my testing this has increased the time between runs of the garbage collector by between 5 and 12 times (though the collections themselves pause for somewhat longer) though it probably needs further tweaking and could probably do with dynamically adjusting to the current pattern of heap usage.

Updated to 1.0.0.6. Now includes a mechanism to increase the Mono heap headroom to reduce the frequency of garbage collections. Just hit Mod-End to assign approx 1.5 GB of extra ram to the Mono heap...

Yes, the docs for the Boehm collector and various Unity specific docs claim that it never releases memory back once it is part of the Mono heap but this appears to not be the case. I suspect that Unity do some extra weird stuff to get some control over it. This is all very useful data (though it's nothing I've not seen before, it's nice to have it confirmed). The new padding mechanism I'm designing should increase the heap headroom by a factor of 10+ rather than the near-doubling you are seeing. This should be a seriously useful reduction in the GC rate though the actual stutters, when they do happen, may be a lot more noticeable...

I would seriously recommend you get more memory. Another 4GB (assuming your laptop will take it), or replacing the 4GB with an 8GB (again, if your machine allows it) will make a world of difference. With only 4GB you will probably have better results running the 32bit version of 1.1.2 as the 64bit version is less efficient at using the memory and you don't have much to play with. Also, the 32bit version understands about the 4GB address space limit and makes more effort to avoid exceeding it than the 64bit version does about exceeding the limit of total physical RAM. Simply right click on the log file and do "Send To->Compressed folder" to compress it into a .zip file. This will be very much smaller and you should be able to put it on dropbox just fine (though 5MB shouldn't be a problem from dropbox anyway).

I really can't see this being an unmodded issue or it would've been reported before. It is most likely a clash between different mods or simply a bug in one mod and your unmodded game is less unmodded than you think. Can you read this thread: ...and upload an output_log.txt/player.log file as this is the only thing likely to contain any clues to what is going on...

Hehe, yeah, I've investigated that too in the past, though I was trying to avoid keeping the padding allocated. I'm intending to revisit it now after learning more detail about how the allocator works. It should be possible to force the total mono heap size to virtually any value while leaving most of the padding unallocated by carefully choosing the sizes of memory blocks and keeping one block allocated from each 4k page... That looks like 1000 million, not 100. I would've expected a better improvement for that much so there is probably something else going on like Unity increasing the GC_free_space_divisor when the heap gets very large so you don't end up with an extra 250MB of heap headroom. It would be interesting to know the minimum and maximum values of HWM you see before and after adding the huge block. I'll definitely take a look at PadHeap later today and also try to post the info I've learned about how the allocator works...

Yes, you're basically correct, when Mono needs to increase the size of the heap it (currently) allocates so approx 1/4 of the total heap size is free (I believe Unity changes this value to 3). No, it isn't exposed to modding (or even to the KSP code written in C#). This is what the blog article you linked to does for iOS or other OSes that use libgc. Mono doesn't expose it to the CIL code running inside Mono. It would be fairly easy for Squad (or anyone else) to change this in the same way as the blog article but the Windows player doesn't use a shared libgc (I presume it's statically linked into the player executable or mono.dll). If the linux and OSX versions use libgc then it should be easy for those but the Windows version may need a considerably more complex change. However, the best this can do is increase the heap headroom by a factor of 2 or 3 which will only result in the frequency being reduced by this same factor. E.g. if the heap has 3 times the headroom then there will be 3 times as long between runs of the GC. This isn't going to be enough of an improvement to really be worthwhile by itself though it would make the improvement due to a general cleanup of the garbage producing code more significant.

You're welcome. Give a man a fish etc...

First, I look up the P-M22 in the ModuleManager.ConfigCache to find out the internal part name (Pollux_Solar_A). Then I search the output_log.txt for the internal part name to find out what MM patches are being applied to it. The following mods are all applying a patch to the part in question: Thermal Monitor/Thermal/@PART[*] UmbraSpaceIndustries/Kolonization/ScrapParts/@PART[*] KerbalKrashSystem/Configs/KerbalKrashSystem_Other/@PART[*]:HAS[!MODULE[ModuleKerbalKrashSystem_Exclude],!MODULE[ModuleKerbalKrash*],!MODULE[ModuleWheel],~PhysicsSignificance[1]]:AFTER[KerbalKrashSystem]:FOR[KerbalKrashSystem_Other] KerbalKrashSystem/Plugins/KKS-mods/KerbalKrashSystem_KIS_Repair/Configs/KerbalKrashSystem_KIS_Repair/@PART[*]:AFTER[ModuleKerbalKrash_Repair]:FOR[KerbalKrashSystem_KIS_Repair] kOS/kOS-module-manager/@PART[*]:FOR[kOS] TweakableEverything/TweakableSolarPanels/@PART[*]:HAS[@MODULE[ModuleDeployableSolarPanel]]:FOR[TweakableEverything] GalacticNeighborhood/Configs/Core/solarpanelsFix/@PART:HAS[@MODULE[ModuleDeployableSolarPanel]]:FINAL InterstellarFuelSwitch/Patches/IntegrateInterstellarFuelSwitch/@PART[*]:FINAL Of these, I would suspect the GalacticNeighborhood mod as it is presumably trying to give solar panels some use at long distance from the sun. There is presumably a file "GameData/GalacticNeighborhood/Configs/Core/solarpanelsFix.cfg" that contains this patch.

It would probably be better for you to zip up an output_log.txt file and the ModuleManager.ConfigCache file, upload the zip to a file hosting site (e.g. dropbox) and post a link here.

Yes, the code just needs to use "this.otherPart" instead of "parent" except it needs to remember it from before the "undocking" happens which will probably set otherPart to null.

It looks like the line of code in ModuleGrappleNode.Release that adds a force to the node being grappled is using the parent part rather than the part the grapple is attached to. It should be a simple fix for Squad to make... Edit: I have added this bug to an internal Squad bug tracker...