Sim speed is sitting at 0.6, someone's jump drive has been charging for ten minutes, and the group chat has decided the server is broken. It isn't, usually. Sim speed is Space Engineers telling you, quite precisely, that there's more simulation than it can fit into real time, and most of what causes that is visible, measurable and fixable without spending anything.
We've written a fair bit about Space Engineers by now, and this is where the rest of it ends up. Getting a server running, knowing which file your settings live in, keeping mods from eating your world: it all leads to a Saturday night where the sim drops and somebody has to work out why.
What sim speed actually is
Space Engineers runs its world at a target of real time, and sim speed is the ratio it's actually achieving. 1.0 means the simulation is keeping up. 0.6 means one second of game time now takes nearly two seconds of yours, because the server doesn't drop things to catch up: it stretches time instead. That's why low sim speed feels so distinctive. Nothing breaks. Nothing disconnects. Everything just happens underwater. Refineries take longer, doors open lazily, and a fight becomes a slow-motion argument.
Press Shift+F11 in game to toggle the performance overlay. The line you want is Server simulation speed, and the Server-prefixed rows are the dedicated server's own numbers rather than your machine's, so you're reading the actual world instead of your PC having a moment. Teach your regulars that one. "The server feels slow" and "sim speed reads 0.55" are very different tickets, and the second gets solved faster.
One thing sim speed is not: frame rate. FPS is your graphics card's problem and every player has their own, while sim speed belongs to the server and everyone shares it.
Where it actually goes
The main simulation thread is the bottleneck, and it has been for years. Keen have multithreaded plenty (physics went parallel back in 1.181, and 1.196 was literally titled "Server Optimizations"), but one thread still owns the world, and when it's full, sim speed is what gives.
What fills it, in roughly the order we see it in tickets:
- Subgrids. Rotors, pistons, hinges: every one is a physics joint that gets simulated continuously. A base with twelve piston doors costs more than its block count suggests, and someone's articulated mining rig with forty subgrids can cost more than the rest of the world combined.
- Sheer grid count, especially moving grids. A parked station is cheap-ish. A hundred drifting wrecks are not.
- Programmable block scripts, which run on the very thread that has no time to spare.
- Floating objects. Every dropped ore chunk and loose component is a tracked entity.
- NPC traffic. Cargo ships and encounters are grids too, they just arrive on their own.
RAM tracks the size of the world rather than the speed of it. A big world eats memory; a busy one eats the thread. When sim speed drops it's almost never a memory problem, whatever the graphs are doing.
Which settings the panel can actually change
Now the bit that decides whether any of the tuning below does anything at all.
Space Engineers splits its dedicated config into two halves that don't look like halves. Most of the performance levers (floating objects, autosave interval, in-game scripts) sit inside a <SessionSettings> block, and session settings only seed a world at the moment it's created. After that, the copy inside WORLD\Saves\<yourworld>\Sandbox_config.sbc is what the server loads, and Service Settings quietly stops having a vote. So on a world that's been up longer than five minutes, changing max floating objects in the panel and restarting achieves nothing. The value sits there looking correct. The server ignores it. That whole two-files problem is written up properly in the configuration guide, and I'd read it before touching anything.
The rule for everything below: new world, Service Settings. Existing world, the world file.
Max floating objects is the one I'd move first. The game's own dedicated server interface caps it at 100 and defaults to the same, and we provision at 512. Everything in that budget is an entity the server tracks, and on a mining-heavy world the budget fills up and stays full. Bringing it back toward 100 is about as close to a free sim-speed win as this game offers.
Autosave is a spike rather than a drain. Our servers ship at five minutes, so if the world hitches on a rhythm, that's what you're feeling. The instinct is to shorten the interval so each save has less to do. It doesn't work like that (you get more spikes, not smaller ones), so push it out to ten or fifteen instead.
In-game scripts can go off entirely if your group doesn't write them. Programmable blocks run on the thread that's already full, so an unused scripting feature is a standing cost against nothing.
Then the one that genuinely works from the panel on any world, because it sits outside the session-settings block and gets read fresh on every boot: pause-when-empty. Ours ship with it on, and it shows up plainly in the numbers. Pulling a fortnight of samples off one of our servers, CPU averages about 4% while people are playing and settles to roughly 1% once the last player leaves, then holds flat until somebody logs back in. So if you've ever wondered why the overnight line looks dead, that's not the server dying. That's the sim taking the night off.
Two things in there I'd be wary of. The trash-removal toggle writes the old RemoveTrash element, which doesn't appear in the current session settings reference at all. The modern system is a different set of keys and lives in the world file. And view distance isn't a sim-speed control, no matter how much it looks like one. The setting that actually governs entity streaming isn't in the panel at all, which is its own story and also in the configuration guide.
Limits, before you need them
Block limits are the other half of this, and they're not in the panel either. BlockLimitsEnabled in the world's Sandbox_config.sbc is the master switch, and it takes four values: NONE, GLOBALLY, PER_FACTION and PER_PLAYER. A world built from the dedicated server's defaults tends to come up with limits off, while a world you made in game and uploaded usually arrives with GLOBALLY already set and a PCU budget attached, which is why "out of PCU" reaches us from people who never deliberately turned anything on. Opposite situations, opposite fixes. Read the file first.
Then the order matters more than the numbers. Get the switch where you want it, watch what your heaviest grids actually measure, and only then decide where the ceiling goes. Clamping hard on an established world puts every over-limit builder in an awkward spot the moment you restart, and that's an argument you can choose not to have.
Cleanup: the lever nobody uses
Press Alt+F10 in game as an admin (the setup guide covers making yourself one) and you get the admin screen, which is most of a server-maintenance toolkit that nobody opens.
The entity list shows every grid in the world, sortable by PCU, block count, mass, or owner last logout. That last one is the useful one, because sorting by it gives you a ranked list of what the departed left behind. You can stop entities, depower them, or remove them, and there's a single action that clears an inactive owner and their grids together.
The same screen carries the modern trash removal settings across a few panels of thresholds, with a Suspend button if you'd rather the game collected nothing automatically. Configurable in game, live, no config file involved. Given how much of this game's tuning lives in XML, I find it slightly funny that the best housekeeping tool is a menu.
Two cautions from experience. Stop a grid before you delete it, because "abandoned wreck" and "mining ship whose owner is at work" look identical in a list. And announce cleanup days in advance, because deleting a dead player's base is maintenance right up until their friend was storing things in it.
If you'd rather this ran itself, that's the usual argument for Torch, which carries plugins aimed at parking idle grids and scheduling housekeeping. The mods and Torch piece covers what's in the curated list.
Heavy world, or busy node?
The honest section. Sometimes the world is fine and the hardware is having a day, and you deserve a way to tell them apart.
A heavy world degrades gradually. Sim speed drifts down over weeks as bases grow and wrecks accumulate, it survives restarts, and it improves when you clean up, cause and cure both sitting in the entity list. A struggling node looks nothing like that. It drops suddenly, nothing changed on your side, and no amount of cleanup moves it.
One trap worth knowing when you read CPU graphs, ours included: an averaged figure can look perfectly relaxed while the one core that matters is flat out. A Space Engineers server showing 40% CPU at 0.6 sim speed isn't coasting. It's a maxed main thread hiding in an average. We've been caught by exactly that on other games, which is why when you open a ticket about sim speed we look at per-core load on the node rather than the headline number.
So: slow decline with an entity list like a museum, and the world wants a tidy. Cliff-edge drop with nothing changed at your end, open a ticket with the service name and roughly when it started, and we'll check our side. And if you're reading all this before you've even got a server, the Space Engineers hosting page is where to start, ideally before your first articulated mining rig.