DMagic

I updated the first page with better high-resolution graphs for the framerate plots, a partially labeled CPU comparison chart and a fully labeled high-resolution version, and a short discussion about the results at the top of the third post. And thanks for the suggestion about labeling that chart xcq. Once I did that a few trends became clear. First, AMD and mobile CPUs all tend to underperform based on their benchmark scores, which isn't surprising. And the Core 2 Quad CPUs produce very consistent results, with performance scaling very well with clockspeed, that was nice to see. It's also clear that the recent Core series CPUs from Intel tend to perform very well and cluster together. And the overclocked CPUs fill out the top right corner of the chart, though there does seem to be a limit to how much can be gained from this. From watching last week's Squad Cast it seems that the 0.22 update will come with some significant performance improvements. This is, of course, awesome, and I really want to see some comparisons between 0.21 and 0.22. This also means that I won't be able to compare performance between versions for the database. I don't think it will invalidate any of the testing I've already done because I was never interested in the performance of any specific CPU, only in the comparisons between many different CPUs.

There does seem to be a bit of a difference with MSSE off. And a small difference in performance can make a big difference in total simulation time. Although, if I understand this correctly, anything above 33FPS should run in real time (a max of 30ms of game time can pass for each frame, and 33FPS is about 30ms/frame), so that larger difference in the later stages shouldn't affect simulation time. That slight increase, especially around 200-300 seconds could be enough to account for the difference though. I would have expected the 2500k to run a little bit faster than the 2320 at stock speeds, but there are a lot of factors that could account for a 10% or so performance difference, so it's not too surprising to see them running the test at similar levels. The 2320 is really just a slightly slower, locked version of the 2500k; I don't think there is any other difference between the two CPUs. And the right side of the graph probably isn't a valid comparison, I did some tinkering around with those frametime datasets to avoid making the graphs too messy, so the FPS and frametime graphs don't match up exactly.

I second the idea of using docking tugs instead of putting excess parts on each module, it really cuts down on your final part count. However, doing this can be bait for docking port bugs. The best way to avoid this is to make sure that each station component has its own control point, either a probe core or a command pod. There are ways to fix the docking port bugs, but they don't always work and can be complicated. I would also suggest that you consider putting the station just above 160km instead of 150km. This is the altitude where the terrain detail cuts off. If you have any slow down or choppiness when looking down at Kerbin you can get around this by staying above 160km.

I updated the front page with all of the new results. I also added high-resolution version of all of the framerate graphs. You can just click on them to open up a new page, you might have to click on the zoom button a few times to get to the actual full-resolution images (they are about 4000x2000). This makes it much easier to see the small differences in the early stages. I'll update those full-resolution images again at some point to make them a bit easier to read, and I'll make a labelled, high-resolution image for the Passmark/Cinebench graph as well. I've only added the "New Drivers" run from your data sets Justy. I'll take a look at the others at some point. I may add a few graphs with comparisons at different resolutions and settings. I have results from a few different people, so that could be useful. It's not too surprising that running KSP from a USB drive or using Readyboost didn't help. Even USB 3 drives have pretty crappy flash memory compared to any decent SSD, but even using a slow HDD shouldn't really affect performance once everything is loaded. And I think Readyboost only really helps with really low RAM situations. I wouldn't have expected MSSE to have much of an effect on a quad core system (it wouldn't be surprising on a dual core system though), but I guess it's not too surprising that background processes could affect KSP, even with lots of CPU headroom.

This would be cool, but don't get your hopes up. There is some technical limitation in KSP that prevents having planets or moons with axial tilts, so unless they have fixed that we won't be seeing any tilted planets.

Thanks for collecting all of those runs. I'm going to have to make a new graph to split up those C2Q and 920s since there are so many of them. I've considered adding labels to that first plot, but I didn't want to make it too cluttered. I think what I'll do is make a high resolution version that you can click on to make it easier to zoom in. I should do that for all of the graphs actually.

I am a little curious about this too. I used the red rocket from the KSP logo on my Curiosity tribute, Indifference, but I was a little worried about stepping on someone's toes. I figured it was fine as long as it was limited to the forums.

Thanks for running all those tests. That 10-20% increase in performance is definitely interesting (the much bigger jump later on is probably less meaningful than the early performance difference). It's easy to convert the x-axis to time so that I can compare it directly to the other results. But it will be a few days before I can get to it; those 50000 row excel files give my macair a heart attack. I'll also see about running some tests of my own when I get back. Does anyone know if KSP runs OK on live disc instances of Linux? I always keep a copy of Ubuntu on a flash drive, so I'll give that a try. I could also just install it on my second SSD and try it that way. Thanks for bringing up that benchmarking tool too. I have been looking for a way to measure performance under Linux.

NASA announced last week that they are declaring Deep Impact dead after being unable to regain contact. The probe originally launched and met the comet P9/Tempel, crashing an impactor into the comet’s surface and recording the results. It visited several other comets and was scheduled to pass by another asteroid. The probable cause of the probe’s death: an error related to the 32bit time keeping code… This seems like a spacecraft well suited to being Kerbalized. Like my Curiosity tribute, this is another Stock++ mission. I use Engineer and Procedural Fairings (the first +) in addition to using several modified stock parts (the second +). I’m also trying something new with my mission reports. I normally don’t really like .gifs, but they seem well suited to KSP. I’ve tried to keep the size down, they are all less than 750kB which is less than some of the regular images, and I’ll try not to have too many on the same page. Let me know if anyone has issues with them. I’ll start with a pre-launch glamor shot of the probe on the pad. The rocket has one LOX/Fuel engine and six solid rocket boosters strapped on the side. The liquid engine starts up a few seconds before launch, when all six solid boosters ignite. Initial TWR is a little, um, high, starting somewhere around 5 and only climbing from there. It reaches around 300m/s by the time the solid boosters burn out, far higher than terminal velocity, but that’s not going to stop any Kerbal probe. After climbing out of the dense part of Kerbin’s atmosphere the fairings separate, revealing the probe inside. The second stage orbital insertion burn puts the probe into a stable ~120km orbit where the probe can wait for the interplanetary burn window. Not having any asteroids or comets handy to visit, the small moon of Eve, Gilly, will stand in for Deep Impact’s target. When the Eve transfer window comes around the probe's upper stage engine ignites, pushing it into an encounter with Eve. After a few months in interplanetary space the probe approaches Eve. After scraping the top of Eve’s atmosphere the probe enters a stable, elliptical orbit around Eve. After a final, short burn, a brief encounter with Gilly approaches. The probe can be seen in its final configuration now. We can stop here and take a look at the probe’s instrument panel. On the back side you can see the large single solar panel, a bigger resize of the standard OX-STAT panel. At the top is the steerable high-gain antenna. At the bottom is the impactor, a sepratron boosted small hex probe with a conical impactor mass at the front. On the instrument panel is the blue medium resolution imager, the yellow high resolution imager, a low-gain antenna, the flight computer and image processor in the center, and the two star trackers used for navigating and positioning. The probe makes its final approach over Gilly, passing about 1.5km at its closest point. Now the fun part begins. We’ll start with the images from the, um, companion probe that just follows Deep Impact around taking pictures. You can clearly see the impactor launch, followed by a repositioning of the imagers and the impact. Next up are the images from the medium resolution imager. Again, you can see the launch and impact. Finally, we have close up images from the high resolution imager. These images clearly follow the spin-stabilized probe as it approaches and crashes into Gilly’s surface. Let me know how these .gifs work out and whether or not you like them. I think they can work well with KSP.

Collected here, I present all of my mission logs and records. Rather than continue to make new threads for every mission, I’ve decided to collect everything into one big thread; one-off missions, tributes, major, multi-part missions, future career mode logs, I’ll collect it all here. Click on the pictures below for links to the respective thread/post; some of the older missions don’t have links associated with them. KSP v0.22: KSP v0.21: KSP v0.20: KSP v0.19 (some of these old missions don't have threads associated with them or they were lost at some point):

My opinion is that we should have female Kerbals, but that this shouldn't be a development priority. In fact, since these are aliens with arbitrary characteristics, we should have a whole range of customization options. Gender, color, physical size (within limits of course), age, etc... could all be options for choosing new Kerbalnauts. We already have the Kerbalizer; that can be improved upon and added to KSP itself. I understand that some people couldn't care less about this, and that's fine, but others would really benefit from being able to customize our Kerbals. For a recent example of this just look at X-Com Enemy Unknown. That game allows for a range of customization options for your soldiers. This allows some people to really get into the game and care more about their squad; it can really make a difference in how you play and experience the game. KSP, I believe, is perfectly suited to this style of interaction. For many of us the defining characteristic of the game is the ability to build crafts exactly the way we want them (and if you can't find a way to that you can find a mod or make one yourself that will fulfill your need). The ability to do something similar with the Kerbals is a great way to complement that. And if you don't think people care about who their Kerbals are just take a look at some of the mission write-ups. There is a tremendous amount of creativity to be found in those forum threads, and increasing our ability to customize and interact with our crews can only add to that.

Your computer should be fine, it won't be the fastest, but it should do alright. Don't worry too much about graphics effecting you performance, you might have to turn a few settings down, but that shouldn't be a problem. The game is really limited by CPU power. If you can overclock your CPU a bit that would be great, but even without that you shouldn't have too many problems with relatively small crafts.

There are many ITX cases that allow for full sized video cards, some of them are a bit big, but they work. Or if you want you can go much smaller like mine and be limited to low-profile video cards. For KSP a low-profile HD7750 works fine.

Do you have a budget in mind? What kind of case are you using, one that will allow for at least some overclocking? For a high end combo I would go with one of the ASUS ITX boards, the ones with the daughter board for some of the power circuitry, and a newer Intel i5 k edition CPU, a 3570k or 4570k. You probably won't be able to get a big OC, but you should be able to get a little above stock speeds. If you aren't doing any overclocking then you can probably go for a cheaper motherboard and a non-k i5, maybe a low power version if you are worried about heat. AMD CPUs, in my experience, tend to underperform on KSP, that's why I recommend sticking with Intel. I currently run an i5 3470 on an EVGA H77N ITX board with an AMD HD7750. Some of the CPUs I mentioned above perform better than mine, but it's not a huge difference. And cooling isn't an issue even in my extremely small case (~4.5L), so you can probably get away with some overclocking if you want. You can check out my database if you want to see more about how different CPUs compare. http://forum.kerbalspaceprogram.com/showthread.php/42877-CPU-Performance-Database

90o north or south; or, the poles.

I updated the front page. I suspect there are a lot of things that can affect performance by 5 or 10% (aside from GPU limitations), such as testing in a fresh session, having certain mods installed even if they aren't being used, using a clean install or save file, and so on. So I'm not surprised that people can get slightly different results when retesting. In any case, it seems that _Aramchek_ has regained the lead, if only slightly, which is to be expected given your CPU and clockspeed. I also dug a little deeper on the comparison chart and added another data set with Cinebench 11.5 scores as well. This is another CPU benchmark widely used as a general indicator of CPU performance. It's pretty easy to find scores for different CPU models at various clockspeeds. For the missing Passmark scores I had to search a bit harder to find user reported values. In some cases I had to estimate based on similar overclocks (a 4.6GHz i5 3570k instead of 4.5GHz), but I think they are within a reasonable range. The general trend is the same. Performance seems to fall within about 3-4 FPS of the trendline at any given Passmark or Cinebench score. It's not perfect, but running these benchmarks should give you an idea of what kind of performance to expect with my test rocket.

Your GTX 260 may be over 5 years old, but it's around 5 to 10X more powerful than the GT 625. There's really no comparison between the two cards. I've switched from an AMD HD7850 to an HD 7750 (which is still far more powerful than the 625) and I definitely noticed a difference in performance at 1680X1050. With the 7850 I can run with just about everything maxed and not really be GPU limited, but with the 7750 I have to turn down the terrain settings (really just the ocean settings), AA, and maybe a few other settings.

Using a bunch of mechanical HDD's in a RAID isn't likely to make any difference here. You can get really high sequential read and write speeds doing this (this applies generally to moving around really big files), but the real advantage of SSDs is in their high random read and write speeds. These can be as much as 50-100X faster than a mechanical drive and putting 2, 4 or 50 drives in an array won't do anything to help that. Random read speeds are what generally affect loading times, such as windows bootup, game loading, application startup and other things like that. Either way, disk read speed doesn't seem to really be the bottleneck in KSP's initial load time.

That system really is very unbalanced. I would love to see your results on my CPU test thread with that CPU, but your GPU will almost certainly cause problems, even at the lowest settings I wouldn't expect much out of that thing. I think your integrated GPU may even be better than that thing, it would probably at least provide similar performance. And about, Windows 8, I don't think that will really affect performance either way. There's not a huge difference between 8 and 7; I'm on 8 and I don't think my performance is better or worse than that of people running 7.

Wow, that is a pretty big difference from the other 920. The difference in simulation time isn't very surprising (a small change in initial performance can make a big difference in simulation time), but your initial performance is very high. You're getting just a bit better performance than the i5 2500k at 4.0GHz and the i5 3570k at 4.5GHz (I don't have the actual results for CaptainKorhonen's i7 2600k, but your performance looks just a bit higher). I wouldn't compare the later stages from these tests, they were created from frametime logs that I massaged a bit to clear out what I think are spurious, fast frames (<5ms, which would be 200 FPS) and to make the graphs look a little cleaner. superm18's i7 920 also performs very well at 3.2GHz, about the same as a stock i5 2500k. I guess 800MHz is a 25% boost in clock speed, but that's still an impressive jump. Maybe there's something about those Nehalem CPUs that really works well with KSP.

Actually, I recommend not doing this. In my experience this tends to cause the other docking port bug, the "state=acquire" bug. This one prevents the docking port from activating, causing the broken port to just bounce off of the other port. It's easier to fix than the can't undock bug (just change "state=acquire" to "state=ready" in the persistence file), but I still wouldn't tempt these kinds of things. My advice for preventing the can't undock bug is to always have, and keep, at least one control point (probe core or command pod) on every, individually docked component of your station, vessel, or base. Most of my encounters with the can't undock bug have involved a tug moving a component that has no control point on it. As for Squad fixing this, I still haven't seen anyone report being able to reliably replicate this and I don't think it's on the bug tracker. I've tried many times to force this bug on a stock install, but I've never been able to do it. Edit: For the can't undock fix check out this thread. It's not at all straightforward, but it works. http://forum.kerbalspaceprogram.com/showthread.php/35777-Can-t-Undock-Bug-How-To-Fix

Can you send me the log file for your 0.03 second physics delta time run and your CPU specs? I can add your results to my database. It's not too surprising that you don't see much change at different settings. Except for a few options, terrain (especially the ocean terrain settings), and maybe really high light counts, or AA, KSP isn't really GPU limited. Most any midrange card can handle max, or almost max settings reasonably well. Also, delta-time affects game-time, but it can cause physics errors if you move the slider too far left (lowering it below 0.03 in the settings.cfg can also cause issues). I think it's something like turning on physics warp; the game can't really keep so weird things can happen. And I'm glad you noticed that performance seems to drop on subsequent runs during the same session of KSP. I'm not sure if this only happens with high part-count rockets or if it happens all of the time, but I've noticed it too and I should add that to my thread.

Just got back from watching it launch in the south sky over New York; that was very cool.

I agree with this idea, but instead of making a separate part they could just add the function to the already existing decouplers and stack separators. Just make a right-click option, or allow us to set a hot-key for a no-force separation in addition to the regular, space-bar activated function.

You can't really compare clock speed between different generations or families of processors (i7 is a little vague as well, there are are three generations of CPUs that use that name, not to mention mobile and the consumer level Xeon parts). Speeds for high-end CPUs have been around the 3-4 GHz mark for the past 5 or so years, but we have seen huge gains in performance. For Intel at least, each generation has seen somewhere around a 10-20% improvement in performance at the same clock speed, so it's not surprising that you see a big improvement with your new CPU. You should also note that CPUs don't usually run at the advertised clock speed. Pretty much all CPUs from the past few years use some kind of dynamic boost based on the workload, temperature, power usage, etc... Your clock speed while playing KSP might actually be much higher than 3.2GHz (don't rely on task manager to figure out what it really is, it can be very far off).