DMagic

I don't have a picture of it, but it's the difference between the big green ball and the regular size green ball when adding parts in the VAB. I think you can see the difference in the 2.5 to 1.25m adapter piece, one side has the regular (size 1) node and the other has the large (size 2) node.

How are you measuring the CPU speed? Try CPU-Z, that should give the most accurate results. If it really is stuck at 0.75GHz for some reason, that's a problem, and it would explain the slow performance. It might somehow be stuck at the idle speed. There's probably a way to get it to behave normally, I'm just not sure exactly how.

I think Apollo has a good suggestion. Have a short, simple demonstration of rocket building (somewhat interactive) that preferably results in failure. Then show how to fix it and show a successful launch. You probably don't want to show the entire launch though, that can be a little boring and it has quite a bit of dead time. A quick Mun landing from a craft already in orbit that you know works would be a good way to finish. I think a complete mission is probably not a good idea. There is just too much dead time. One or two minute burns for orbital insertion or ejection to the Mun aren't very exciting. Showing the basics of construction and a few highlights of flight and failure is probably a good way to do it.

The freezing and crashing are definitely not normal. You can check in the support forums to see if anyone else has similar issues, or try submitting a bug report. Reinstalling the game can help, and if you use any mods you can try removing those. OSX could be an issue, but I've never had a problem running KSP on a Mac. Even my 2011 Macbook Air can run the game without freezing or crashing, it is really slow though. I don't know why RAM would be an issue. That is generally only a problem when you run out, and that usually happens when you run too many mods. 4GB should be fine for playing stock or with a few parts mods. Performance is very CPU limited. Having crafts with lots of parts will significantly decrease your frame rate. That green/yellow/red flickering on the timer in the top left is telling you that your CPU is having a hard time keeping up with the physics calculations. Set the physics slider all the way to the right in the first page of the settings menu. This can help with frame rate, but it will also slow down the passage of time in the game (one second of in-game time can take five seconds of real-life time). If you want to compare your performance to others you can try my CPU performance rocket in my CPU database thread: http://forum.kerbalspaceprogram.com/showthread.php/42877-CPU-Performance-Database

Thanks what-the, I added your results to the Mobile Intel graph. The different speeds for the GPU are for the different modes it operates in. During idle/2D/desktop usage it stays at 350MHz and during 3D or other GPU intensive tasks it switches to 1000MHz. Pretty much all GPU's do this; some have three modes and some have a turbo mode where the clockspeed is increased beyond the regular high speed limit based on power and temperature limits. It's nice to see how the i3 matches up with the i5. The major difference here, I think, is that the mobile i3's don't have any turboboost mode, whereas the i5's can increase their speed to 2-2.3GHz. You can see how that relatively small increase in performance has a big impact on total simulation time. The i5-2467M gets to stage 5 around 3 or 4 minutes before your i3, even though the difference in frame rate during the early stages is just 1 or 2 FPS. The other i5 on that chart continues on past stage 5 though, that's why it takes so long to finish.

That shakiness of the periapsis and apoapsis markers when you get close to circular always happens. When the two values get really close together the errors in the game will eventually get larger than the difference, so the markers bounce around a lot. And having too much torque can definitely make you start shaking with SAS on. It's easy to see with just the 1-man command pod by itself. With SAS on it starts shaking a lot; if you decrease the torque in the .cfg file it goes away. But that thing about the prograde and retrograde markers moving is weird. The maneuver node marker can move around a lot when you have a very small maneuver (<1m/s), but I don't think I've ever seen the velocity vectors do that. You can right-click on individual reaction wheel parts and command pods and toggle the torque on and off for that part. Try turning off torque in a few of the wheels (but leave SAS on) and see what happens.

Nicely done, it looks kind of like an ant farm the way the camera clips through the surface.

Yeah, that seems way too slow for that CPU. Even the low end mobile i3's stayed around 4-5 FPS for those first stages. My i7-4650U, which should be fairly comparable to yours, managed around 8-10 FPS for those stages. A reinstall is always a good idea when they release a new update. It can be a lot of trouble, I think it's around 1.5GB to download, but it could make a big difference. And that rocket should be stable with SAS on. It's best to just fly straight up, but you should be able to make controlled turns even in the early stages, within reasonable limits, of course. Extremely low performance might affect that, I'm not sure.

Performance is heavily influenced by the total part count of your craft. High part counts will choke even the fastest of desktop CPU's. It's also possible that the upgrade to 0.21 is causing some slow down. You should reinstall KSP to make sure that there are no issues caused by the upgrade (I had to do this for both the 0.21 and the 0.21.1 upgrades). If you want to compare your performance to others you can go to my CPU performance thread, download my test rocket and send me the results (make sure the physics slider is moved all the way to the right in the settings menu). With that low resolution and low graphics settings the game performance will be limited by CPU speed, so you can compare with the results others have reported. http://forum.kerbalspaceprogram.com/showthread.php/42877-CPU-Performance-Database

I think it's a good idea, too, but I'm also pretty sure this is on the do not suggest list (it's a variation on the combine-parts suggestion) because it's been suggested a thousand times. There are a few obvious problems with this. If you don't load the parts inside the fairings at launch then you will have to load them at some later point. So you will have some 10 to 20 second hitch when you separate the fairings and all of the parts have to be loaded in. Which would be a little odd, but not that big of a deal. The other issue is that no, you can't launch anything and expect good performance. A space station with a 1000 parts will still have slow performance whether you load those parts at launch or in space. If you are building a station out 10 or so components then the launch would be a little smoother since you are only simulating the launcher parts, but once you combine everything in space you would have the same problems as always.

Unity and KSP have been multithreaded for a long time. Just check your CPU usage when playing, it's pretty much always over 25 - 35% on a quad-core CPU. It's the physics engine, an older and not very efficient version of nVidia's PhysX, that is single-threaded. That is what causes the slow down, and there is little that Squad can do about it. So while there may be performance improvements here and there, I wouldn't expect major changes any time soon. PhysX is too deeply ingrained in KSP for them to just change to another physics engine (if that's even possible while still using Unity). Maybe Unity will be updated at some point to use PhysX version 3, but I'm not sure if KSP will be able to immediately take advantage of that.

Thanks for running these. I just put the FPS results on the first page, they scale nicely with clockspeed, but I guess Crossfire just doesn't work well with KSP. I didn't put up the frametime results there, but they are interesting, too. Here are the frametime data together with the framerate data: The framerate mostly matches the frametime data until it gets up to 60FPS. After that you get those ridiculous 5ms frames, which I'm pretty sure are meaningless as far as what you actually see onscreen. When I throw out the frames under 10ms and take a 5-frame moving average you get this: Again, the frametime and framerate data match up for most of the run. But when you get to the end the framerate data includes all those high speed frames, so it looks very high. Without those high speed frames you get something more like 60FPS. Maybe this always happens when you get above your monitors refresh rate. It's probably best just to turn V-sync on and not worry about it. Those slow frames are another story though. Those are around 200ms per frame, which causes that noticeable stutter. For my purposes none of this really matters though. It's the low frame rates during the initial stages that I'm most interested in. When you look closely at those stages you can clearly see about a 10% increase in performance going from 3.2 to 3.6GHz, and another 10% for the FX 6350 at 3.9GHz. And as has been mentioned earlier, those little differences really affect the total simulation time, too. Also, CaptainKorhonen and what-the, can you send me the results from your runs? If I can collect everything then I can put it all together and add it to the front page.

I hadn't really considered comparing total flight time when I recommended ending it at stage 5. I just figured the last four or five minutes wouldn't be that valuable and I didn't want to take up more time than necessary. Yeah, the physics distance cutoff is 2.5km. There are a few different things that can happen to debris beyond that range though. When you're still in the atmosphere, I can't remember the altitude cutoff, debris will just disappear after it gets out of range. But above that they will stay, at least until they fall back below that cutoff, if you have the persistent debris set above zero. If you turn that slider all the way down, then I think all debris immediately disappears after passing beyond 2.5km.

Also keep in mind that the in-game flight time is about 330 seconds to what I consider to be the endpoint. That is, when the parts from the stage 6 separation fall out of physics range, which is about 25 seconds after starting stage 5; at this point you're down to 83 parts and should be far away from Kerbin and any slow-downs caused by it. But if someone goes beyond that, say burning until the end of stage 5, that could add another 100 seconds (I believe the total burn time for stage 5 is about 120 seconds), and much more if you continue burning with the orbiter stage (another 120 seconds, I think). It might be better for comparing total flight time if everyone collected the data until you completely run out of fuel. I didn't really want to make people spend an extra 5 minutes collecting very high frame rates though. If you look carefully at the results you can generally see when the early stage parts fall out of physics range, and that can be used to compare simulation time. Although, my understanding is that simulation time is determined by the physics timestep and frame rate, so I'm not sure if we need to worry about comparing both frame rates and simulation time.

My assumption is that anyone running a high end CPU will also have a decent GPU (and don't dismiss the power of electrified gourds and tubers, we all know what happens when you put a ). I can imagine that someone with an OC'd i5 3570k running on integrated graphics might be GPU limited, but except for those edge cases I'm not very worried about it. Just look at Digger's results. Doubling the resolution has almost no impact on performance (Crossfire/SLI might have issues of its own, so I'm not so sure about those results). I'll run some tests later today with min and max graphics settings. I've seen an impact based on changes to graphics settings, but only on the later stages where I'm running above 60 FPS and am likely GPU bound. Slugy sent me his data, so I'll add that to the first page later. But his graph really nicely illustrates the effects of CPU clockspeed. The increase and frame rate and the decrease in time for each stage is obvious just from the plots (well, assuming you've seen these graphs a thousand times and can discern which stage it's at just by looking at the frame rate). Oh definitely. I really spent a lot of time making sure the rocket was stable because of this. The first two stages can take over ten minutes to finish. I didn't want the rocket falling apart somewhere in the middle just because it would take so long to try it again. And let me know if anyone has launch failures. I had a few rare cases where the 2.5m radial boosters on the lowest section were breaking off. I made a few minor changes and haven't seen the issue again (I've launched probably 15 to 20 times in its current configuration without issues), but I'd like to know if it happens so that I can see about fixing it.

Are you talking about the .txt log or the .csv log? I just checked my FRAPS benchmark folder and the FRAPSLOG.txt file shows what you have. But you should also get a separate .csv file for each benchmark, something like "KSP 2013-07-25 19-37-22-14 fps.csv". Maybe it's saved to a different folder?

For FRAPS? It looks like you only have "MinMaxAvg" checked under benchmark settings. You just need to check the "FPS" box, and if you want results like jfx or _Aramchek_ you can select "frametime". You can check PsuedoMonkey's results below to see what the output should look like when you only have "FPS" checked. For KSP you just need the physics slider all the way to the right, and v-sync turned off. Everything else shouldn't have a big effect, at least not during the early stages. I made a more forgiving, 450 part rocket, but I found that performance wasn't slow enough with that. I didn't want people with faster CPU's starting out at over 30 FPS. Thanks for testing it though, I know it's a pain to spend 30 minutes on a launch. The 2013 is definitely better. And more than that, I don't have to be so worried about it melting during testing. The 2011 was painfully hot to the touch while I was launching this, and the fan sounded like it was about to come loose.

Fixed that. Thanks for running these; it's interesting that crossfire seems to have so little effect. Does KSP, or Unity, just have lousy Crossfire implementation? I would expect the increased resolution to have an effect too, at least on the later stages.

The ocean can cause slow downs, but in general performance is limited by your CPU and the part count of the crafts you are flying. I would love to have better performance and more efficient use of multi-core CPU's, but I wouldn't expect much in the near future. For now you just have to learn to be very efficient with part counts. And if KSP really is somehow using only 10% of one core then you have something seriously wrong with your system.

Are you sure you are getting everything in the right folder? The full path should look something like this: D:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\Kethane\ With the Parts, Plugins, Resources, and Sounds folder inside of that. And are you sure that you cleared out everything from the other plugins folder, the one you initially put kethane in? Is the other problem something that's happened after you tried installing Kethane? That sounds like a more serious problem. You can ask on the main kethane forum if you think it's related to that, but it could be something wrong with the core KSP program. If nothing else works you can try deleting the entire KSP folder (make backups of your saves folder) and let Steam reinstall the game. To do that, after deleting the folder, just right-click KSP in your Steam library, select Properties, click on the Local Files tab and select Verify Integrity of Game Cache.

Now that I'm looking at your data I see how it works. I meant what would FRAPS give you if you recorded FPS instead of frametime. I'm guessing something close to the average from the frametime data. Thanks _Aramchek_, but do you have your CPU info? That is a bit weird. When did you start the benchmark, right after the scene loaded? I usually throttle up then hit F11 just before launch. That seems unlikely to cause the results you're seeing though. Can you send me the data file? Any filesharing service works fine, Google docs, dropbox, mediafire, etc... I want to collect everything so I can show it in a consistent form. I updated the second post with the data I have so far. I'll keep adding everything there; I want to keep the first post intact so that people can see what I want first. For the CPU speed, unless otherwise noted I'll put the dual core Turboboost clockspeed. Despite what many forum posts would have you think, KSP and Unity are not single-threaded. KSP CPU usage is regularly over 30% (on a quad-core CPU) so it is obviously using more than one thread. The PhysX implementation used by Unity, however, is limited to a single thread, and this is what causes much of the bottleneck. So most of the time the CPU should be running at the dual core clockspeed (if it has Turboboost or Turbocore). And let me know if that skydrive file works. The spreadsheet is too big to open online, so it will kick you out to Excel, which might give your browser conniptions. For the frametime data, because I want to keep everything consistent, I converted everything to frame rate. I divided 1000 by the time between frames to get frame rate, converted the time to seconds, and took a five-frame rolling average of the data to make the plot more manageable.

A lot of this is buried in the first few posts, but I don't think resolution, graphics settings and the GPU will have a large effect on the early stages of the launch. The whole idea of this rocket is that it will be CPU bound during the first several stages. In the stage breakdown I showed in the fourth post you can see the shift between CPU bound and GPU bound performance. When the game is CPU bound there is little change in the frame rate until the parts pass out of physics range. But later on you can see an increase in FPS as soon as the parts are off screen. You can also use something like MSI Afterburner's screen overlay to monitor GPU usage and see that. If you have a very weak GPU then it's best to look up, this should ensure that you get good, CPU bound, results. The most important setting matters is the physics slider, which should be all the way to the right. V-sync should also be turned off, but you can leave the frame rate cap on, I don't really care about performance above 60 FPS. As I said in the first post, it's best just to leave the camera alone and do nothing but throttle up, hit "T", and press space when necessary. My results show that performance doesn't change much at all when I move the camera around, but it's still probably best just to leave it be. This is also buried in the thread a little, but don't use Mechjeb. Some MJ windows can really affect performance. I know that you aren't testing it, but I just want to make sure people know that.

It would be interesting to see KSP analyzed with FCAT, the much more in depth monitoring system. It requires a complicated setup, but there must be someone out there who can get this into the right person's hands. My guess is that those superfast frames are some kind of runt frames, where just a tiny portion of the frame is actually rendered on screen. There is a good demonstration of FCAT and runt frames here: http://techreport.com/review/24553/inside-the-second-with-nvidia-frame-capture-tools/9 I'm also curious to know what your performance looks like with a smaller polling interval. Do you just see the average frame rate, or do you get something more like the most common frame rate?

If the FPS are capped it probably doesn't matter, I capped mine at 120 FPS during testing. But if V-sync is on that can affect performance. I don't think it matters much (performance at the low doesn't seem to change with it on or off), but it's probably best to turn it off. The really important setting is the physics slider, which should be all the way to the right. That has to be consistent to get comparable results. That might be helpful, but I think it might add too many variables. RAM usage is highly dependent on how many mods people have installed, and I don't want to exclude people because they have lots of parts added. And GPU usage can be all over the place. I've monitored this with the MSI Afterburner overlay and it fluctuates a lot. Changing the view during launch can cause huge swings in usage, but because the frame rate is so low and CPU bound it never really has an effect.

I'm a bit surprised too, I've never seen any kind of real frame rata data. And thanks for trying it in so many different configurations, that helps a lot. Does Dxtory have any kind of frame rate monitoring function, I can't be sure from looking at it online? Anything that outputs a file with the frame rate captured at regular intervals should work fine. Fraps just puts out a file with frame rate numbers, but other programs put out frame rate and the time stamp for each recording. If Dxtory does either of those it should work fine. I think MSI Afterburner also has a frame rate recording function, and there may be other programs, too. You could also just watch the frame rate and write it down during the launch. It's pretty easy, at least in the earlier stages, to eyeball the average frame rate. And the shift as parts move out of physics distance is pretty obvious, even if you aren't looking down to see them.