Frametime Consistency in iRacing: Why Smooth Beats Fast

Two setups can both report “200 FPS” and feel completely different on track. One smooth and predictable, the other subtly jittery in exactly the moments that matter, like a 40-car standing start. The difference isn’t frame rate. It’s frametime consistency, and it’s the single most underrated setting target in sim racing.

Most iRacing graphics guides chase one of two things: maximum FPS, or a fix for stuttering after it’s already ruined your race. This guide takes a different approach. We’ll treat consistency as a deliberate goal you tune toward: with a repeatable method, the display-sync stack done correctly, and a framework for finding the right values for your hardware rather than copying someone else’s numbers.

FPS is the wrong scoreboard

Frame rate is an average. Frametime is the truth. A “120 FPS” average can be a rock-steady 8.3 milliseconds per frame, or it can be a mix of 4 ms and 20 ms frames that averages out on paper while feeling like a stutter under braking.

Your eyes and hands don’t perceive the average, they perceive the worst frames. That’s why the metrics that actually correlate with a smooth, trustworthy image are your 1% lows and the shape of your frametime graph, not the average frame rate.

For racing specifically, predictability beats peak. A frame delivered every 8.3 ms, every single time, gives you consistent visual motion and consistent input timing, which is what your brain uses to judge grip, rotation, and braking points. A spiky 240 FPS that collapses to 120 in traffic teaches you nothing reliable. A flat line at a lower number beats a jagged line at a higher one. Internalize that and every decision below gets easier.

Diagnose before you tune: find your real bottleneck

Before changing a single setting, find out what’s actually limiting you. Guessing wastes hours and often makes things worse. (iRacing’s own guide to freezing and stuttering is the official starting point; this guide goes deeper on consistency specifically.)

Turn on iRacing’s on-screen performance meters (in the graphics options, or via the FPS meter hotkey). You’re looking for the relationship between your CPU/render thread and your GPU load. If the CPU or render bar is consistently pegged higher than the GPU, you’re CPU-limited; if the GPU bar is higher, you’re GPU-limited.

This matters because iRacing is heavily CPU-bound, especially in traffic. Its simulation does an enormous amount of physics and draw-call work on the CPU, and a big pack at a race start is the hardest moment for it. That means many of the classic “turn down graphics for FPS” tips do nothing for your worst frametimes, because your worst frametimes are the CPU choking on 40 cars, not the GPU running out of muscle. Know which wall you’re hitting, and you’ll know which settings can actually help.

The safe way to change settings

Consistency tuning is iterative, so set up a process that lets you experiment without risk.

• Back up first. Copy your renderer configuration files somewhere safe before you touch anything, so any change is one step away from being undone.
• Change one thing at a time. If you flip five settings and it improves, you’ve learned nothing about which one mattered, and if it breaks, you can’t isolate the cause.
• Benchmark the same way every time. Pick a repeatable scenario: the same car, same track, same time of day and weather, ideally a saved replay of a full field so the traffic load is identical each run. Watch the frametime graph, not the average.
• Know that iRacing rewrites its own files. When you change settings inside the sim, iRacing overwrites its configuration files. So make your edits in the sim’s options where possible, and if you do hand-edit a file, do it with the sim closed, otherwise your changes get clobbered.

This discipline is the difference between tuning and flailing. It’s slower for the first hour and far faster over the following ten.

Know which file you’re actually editing

Here’s a trap that catches even experienced racers. iRacing doesn’t keep one graphics configuration. It keeps a separate renderer file for each output device, in your Documents\iRacing folder:

• rendererDX11.ini and per-device variants like rendererDX11Monitor.ini for flat-screen setups
• rendererDX11OpenXR.ini for VR and streaming (OpenXR) devices, including Apple Vision Pro

The sim loads whichever file matches the display device you’ve selected. The trap: it’s entirely possible to painstakingly tune a file that isn’t the one your race sessions actually use, for example editing a leftover monitor profile while you actually race on a different one. You’ll swear you turned dynamic shadows off, and the spikes will still be there, because the setting you changed lives in a file the sim never loads.

Verify which file is live before you trust any hand edit. Launch iRacing on the display you actually race with, drive briefly, exit, then sort the rendererDX11*.ini files by “date modified”: the one that just changed is your active file. It’s a ten-second check that saves an evening of confusion.

The sync stack, done right

More stutter complaints trace back to a misconfigured display-sync stack than to any graphics setting. Get these four working together and you’ve solved most of the problem. The goal is tear-free, evenly paced frames with the lowest latency the setup allows. Blur Busters’ G-SYNC 101 is the definitive testing behind the method below.

1. Variable refresh (G-Sync / FreeSync), if your monitor supports it. This is the most powerful consistency tool there is. With VRR, the display refreshes in lockstep with whatever frame rate the sim produces, so when your FPS swings in traffic, there’s no tearing and no judder, the monitor just follows. Enable it in your GPU’s control software (and turn on Adaptive-Sync or FreeSync in the monitor’s on-screen menu first).

2. VSync, at the driver level, not in the sim. This is the mistake almost everyone makes. For the variable-refresh-plus-VSync method to work, VSync belongs in your GPU control panel, with the sim’s own VSync left off. Driver-level VSync acts as a safety net that eliminates tearing at the refresh ceiling, and combined with a frame cap and low-latency mode it adds almost no lag. In-sim VSync, by contrast, tends to add a latency penalty. If you only remember one thing from this guide: VSync goes in the driver, off in the sim.

3. A low-latency or Reflex mode. iRacing supports NVIDIA Reflex, which trims the render queue so the VSync safety net costs you almost nothing in input lag. Turn it on. (Reflex also overrides the driver’s separate “Low Latency Mode,” so you don’t need both.)

4. A frame cap just below your refresh rate. The cap keeps you inside the VRR window and off the VSync ceiling, which is what preserves low latency. This is the number you’ll tune next.

If your monitor has no VRR, the same stack still applies, but the frame cap becomes more important: with fixed refresh and VSync on, any FPS below the refresh rate drops you to a lower division (240 down to 120, say), and that division drop is judder. So you pick a refresh you can actually hold in your worst-case moment, and cap to it.

Find your own frame cap (a framework, not a number)

Skip the temptation to copy a stranger’s cap value. The right number is a function of your refresh rate and your worst-case frame rate. Derive it:

1. Know your refresh rate. Set the display to the highest rate you can reliably run, and confirm the desktop is actually at that rate (not silently reset lower).
2. With VRR on: cap roughly 3 to 5 percent below your max refresh (for example, around 138 to 141 on a 144 Hz panel, or around 225 on a 240 Hz panel). VRR handles the swings below the cap, so you don’t have to “hold” the cap, you just want the ceiling inside the VRR range.
3. With fixed refresh (no VRR): cap at a rate you can hold in the worst case: a full grid at a demanding track in the rain. Test it: load that scenario and watch whether your frametimes ever break. If they do, you’re capping too high; step down to a rate you never miss. A lower rate you always hit is smoother than a higher rate you sometimes don’t.
4. Cap in one place only. Use either the sim’s limiter or the driver’s, not both. A double cap can occasionally fight itself. With Reflex on, the in-sim cap plus Reflex is a clean combination.

The settings that actually spike frametimes

Not all graphics settings are equal. Some add a constant cost (they lower your average evenly, which VRR and a sensible cap absorb without any hitching). Others add a variable, event-driven cost: they’re fine until a specific trigger, then they spike a frame. For consistency, you hunt the second category first:

• Dynamic car shadows. Shadows that update per car, per frame are a classic spike source, worst exactly when there are many cars around. Turning dynamic (moving-object) shadows off is often the single biggest frametime win with minimal visual loss at speed.
• High shadow-map filtering. The most expensive shadow filter settings are known stutter contributors. Stepping the filter down a notch smooths things with little visible difference in motion, most impactful during night and low-light sessions.
• Dynamic reflections and cubemaps. Rendering the scene again for reflections is costly and bursty. Keep these modest.
• Cockpit mirrors. Every active mirror re-renders part of the scene, which makes mirrors one of the most expensive things to render, and the cost rises with every car reflected in them. The car count in mirrors, covered next, is the lever that matters most here.
• Cars drawn, which is not the same as Max Cars. This is the setting people most often get wrong. Max Cars is a network setting: it caps how many cars the server sends you, and telemetry and overlay tools need the full field to work, so leave it at 63. Lowering it starves those tools of data. What actually helps frametimes is a separate, purely visual pair of settings: how many of the cars you are sent iRacing then renders, in the main view (MaxCarsToDraw) and in mirrors (MaxCarsToDrawInMirrors). Cutting the rendered count, mirrors first, trims the draw-call spike at race starts without touching telemetry. iRacing’s own reference values are around 30 in the main view and 18 in mirrors; the mirror number can go lower still, since you only need to see who is right behind you. Keep the main-view number high enough to draw every car you could be racing side by side: set it too low and a car alongside you may not appear, which is a safety issue, not just a visual one.
• Texture streaming and the VRAM allocation. If textures stream in while you drive, you get hitches. iRacing caps its video memory with VidMemToUseMB (and system RAM with SysMemToUseMB) in the renderer file, and its auto-detection can under-allocate, which is why iRacing documents setting it by hand. A manual value is honored: iRacing uses it instead of the auto figure on the next launch. Its guidance is to leave about 20 percent headroom (roughly 80 percent of your VRAM). Edit it with the sim closed, and re-check after any in-sim graphics change, since iRacing rewrites the file when you change settings in the sim.

Notice how many of these are about traffic and events, not raw scene complexity. That’s the CPU-bound nature of iRacing showing through.

Attack the CPU-side spikes

Because your worst frametimes are usually the CPU, the highest-leverage consistency moves often aren’t “graphics” at all:

• Trim the per-frame rendering load in traffic: with Max Cars kept at 63 for telemetry, a full field’s simulation cost is a given, but you can still cut draw-call spikes by rendering fewer of those cars, in mirrors first and then the main view, alongside dynamic shadows.
• Protect the sim from your desktop. If you run a second monitor with timing tools or a browser, make sure iRacing is set to hold full frame rate when another window has focus (rather than throttling when you glance away). A background app stealing a core mid-corner is a stutter you’ll never see coming.
• Close the noise. Overlays, capture software, and chatty background apps all inject occasional hitches. For a clean benchmark and a clean race, quit what you don’t need.

Build a tuning loop, not a settings list

The reason “best settings” lists disappoint is that your rig, your displays, your CPU headroom, and the series you race are not the author’s. What transfers isn’t the values, it’s the loop:

1. Baseline. Benchmark your repeatable scenario and record the frametime behavior.
2. One change. Make a single adjustment aimed at a specific spike source.
3. Measure. Run the exact same benchmark and compare the frametime graph and 1% lows.
4. Keep or revert. If it helped, keep it and note why. If it didn’t, roll it back.
5. Repeat. Move to the next spike source.

Do this a handful of times and you’ll end up with a setup tuned to your worst case, which is the only case that matters, because races are won and lost in the hard moments, not the empty practice laps.

The takeaway

Stop optimizing for the average frame rate. Optimize for the flatness of the frametime line beneath it. Diagnose your bottleneck, get the sync stack right (VRR where you can, VSync in the driver, Reflex on, a cap below refresh), hunt the event-driven spikes before the constant costs, and change one thing at a time against a repeatable benchmark. That’s how you get an image and an input feel you can trust when it counts, regardless of whether you’re on a budget GPU or a flagship.

Smooth beats fast. Tune for smooth.

Racing in VR or curious about Apple Vision Pro? See our companion guide, setting up and optimizing iRacing on Apple Vision Pro.