Randall Fortee22

That frame time dump was the missing piece — thanks for pointing me at it. Ran the numbers on the one from my own log and it's conclusive: 600 samples over exactly 10.0 s, median 16.63 ms (60.1 fps), even-index median 16.64 vs odd-index 16.63 — no alternating pattern. 60 fps is my post-FG rate, so the RTSS buffer is capturing generated frames just as you suspected, and my PresentMon median for the same flight was ~16.5 ms. Both tools are reading the same series. My theory that we were dividing by different baselines is dead — we weren't. I should say plainly that none of this digging was ever meant as criticism. I've built myself a flight performance logger over the last while and I genuinely enjoy the analytics side of it — pulling frame data apart, chasing down what a chart is telling me. AutoFPS is a permanent part of my setup and it's doing its job every flight; when I go poking at a graph it's curiosity, not complaint. If anything this whole exchange has been the fun part. Lowering my Max TLOD for the light aircraft, which sorts it at my end. Congratulations on 0.5.2.0 — and thanks for talking through the internals, I learned a lot.

Ha — sorry about the timing! 😄 Thanks for the recovery explanation, that corrects me. I inferred "fixed timer" from four similar activation→recovery gaps, but that was reading too much into it — in level cruise the 30 s minimum would be the binding gate and the distance/altitude/trend factors would all be at their minimum contribution, which fits exactly what I saw. That's a smarter mechanism than I gave it credit for, and I wouldn't want you changing those thresholds on my account — losing usable TLOD range to fix something I didn't actually feel is a bad trade. Agreed it was working; the episodes stayed short and the flight felt fine. The graph is what surprised me, not the seat. On the detection latency — thanks for explaining the criteria, that's useful to know. I went back to my own per-frame data out of curiosity and got a count I can't quite reconcile, though I suspect that says more about where I'm measuring than about the detector. I'm reading PresentMon MsBetweenPresents with a rolling ±5 s median, so my baseline isn't your RTSS buffer median. On that basis the two windows look similar to me: Window Spikes >1.8× my median ≥2.0× my median 21:02:45–21:04:13 59 44 21:04:16–21:06:52 67 49 Not suggesting anything's wrong — different measurement point, different numbers, and yours is the one wired into the actual detection. What I'm genuinely curious about: I run FSR3 frame generation at 2×. Does the RTSS buffer see the same frame series PresentMon does under FG, or could the two be sampling either side of the generated frames? If they differ there, the median each of us divides by wouldn't match, which would explain why my counts look different to yours without anything being off in the detector. Happy to pull any slice of the per-frame data if it's ever useful. Appreciate you digging through all this — and thank you the 0.5.2.0 release.

AutoFPS 0.5.2.0-RC3 — periodic spike protection fires correctly, but recovery re-arms the triggerYou'd asked for a real periodic-spike episode. This flight had 12 of them — 10.5% of 40 minutes — with protection activating 4 times and each time recovering back into the condition that caused it. Setup: AutoFPS 0.5.2.0-RC3 (auto-updated from test25 15 min pre-flight) · MSFS 2024 1.7.35.0 Steam/DX12 · RTX 3080 Ti 12GB, driver 566.36 · FSR3, FG 2× · TLOD Min 125 / Max 500, IFR · Citation Sovereign+ (light bizjet) · EDDF→LOWS over the Alps, 40.1 min · offline, no injected traffic, default arrival scenery. Flight: P99 21.58 ms · P99.9 49.77 ms · stutter 0.36% · 99.9% CPU-bound (CPU busy 16.46 ms, GPU busy 7.71 ms). During the episodes GPU sat at 41–51% and VRAM 87–89%, so VRAM+ never engaged and the GPU was never the limit. AutoFPS ran TLOD at median 457, max 500 (21% at cap). The episodesDetected from the PresentMon per-frame record on my side — separate data from your RTSS buffer, so this is an independent read rather than a re-parse of your log. Spikes are 39–46 ms against a steady 16.5 ms base. # Wall clock Dur Spikes Cadence Spike ms TLOD at onset 1 21:02:45–21:03:28 43 s 30 1.02 s ±0.02 41.1 486 2 21:03:35–21:04:13 38 s 25 1.01 s ±0.02 40.4 500 3 21:04:16–21:04:27 11 s 10 1.02 s ±0.02 42.3 486 4 21:05:51–21:06:08 17 s 13 1.01 s ±0.02 39.5 486 5 21:06:30–21:06:52 22 s 20 1.02 s ±0.03 39.3 490 6 21:10:43–21:10:57 14 s 13 1.01 s ±0.05 44.8 491 7 21:12:51–21:13:06 14 s 12 1.02 s ±0.03 39.5 494 8 21:13:25–21:13:40 15 s 11 1.02 s ±0.03 43.1 500 9 21:15:59–21:16:12 12 s 12 1.03 s ±0.05 43.9 487 10 21:16:15–21:16:47 33 s 25 1.02 s ±0.03 46.0 489 11 21:17:46–21:18:04 18 s 14 1.02 s ±0.03 45.2 464 12 21:18:22–21:18:37 14 s 12 1.02 s ±0.02 41.2 453 227 periodic spikes of 683 total, 253 s in episodes. Every episode starts with TLOD at 453–500. What protection didActivated @ TLOD Recovery Gap 21:04:27 485 21:04:59 32 s 21:06:37 486 21:07:20 43 s 21:16:38 477 21:17:11 33 s 21:18:28 453 21:19:00 32 s The reductions work — SRed climbs, TLOD drops, stutter stops every time: Time SRed TLOD 21:04:31 55 445 21:06:54 74 426 21:16:54 103 397 21:18:46 107 388 The loopThen SRed decays, TLOD climbs back to the cap, and the stutter returns. The second cycle in full: Time TLOD SRed 21:06:37 activated 486 — 21:06:54 reduced, stutter stops 426 74 21:07:20 recovery (43 s later) 432 55 21:07:34 SRed nearly gone 441 5 21:12:51 episode 7 494 — 21:13:25 episode 8 500 — Same pattern at 21:04→21:05:51 and 21:17:11→21:17:46. The scene hadn't changed between recovery and re-trigger — same aircraft, same terrain, same ceiling — so TLOD came back to 485–500, which is where every episode starts. A few things I couldn't work out from the outside: Is recovery on a fixed timer, or is it meant to see some change in conditions before giving TLOD back? From the log it looks like elapsed time alone. Would holding a floor after a re-trigger at similar TLOD make sense, rather than returning to the previous ceiling? The first activation needed SRed 55; the last two needed 103–107, which made me wonder whether the earlier recoveries gave back too much. Is there a case for backing off the session's effective Max TLOD after a few re-triggers, or does that cut across what VRAM+ is doing? Detection latencyEpisodes 1 and 2 ran 21:02:45→21:04:13 — 55 spikes at a 1.02 s cadence — with no verification attempts in the log until 21:04:26. There are no "RTSS buffer stale" messages anywhere in the flight and no MSFS-not-active gating, so neither of those explains the ~100 s gap. On the aircraftI'd assumed a light aircraft would be my smoothest flight and got the opposite. With a heavy add-on the aircraft takes the main-thread headroom and AutoFPS settles TLOD lower; with the Citation there's nothing else using it, so TLOD goes to ~500 and terrain LOD becomes the bottleneck. Light aircraft + high Max TLOD + dense terrain may be the harder case for periodic overload. I'll lower my own Max TLOD for this aircraft class regardless. Happy to send the full log or the per-frame data if it's useful. I have posted log on Git.

VRAM limiter TLOD hunting in cruise + FPS-priority reductions on a CPU-bound rig (0.5.2.0-test19) @Reset XPDR — another logged flight, nothing broken this time; two control-loop observations from watching the VRAM limiter work a 12GB card at altitude. Flown on test19 — test20 landed right after I shut down, will fly the collapsed-spike detection next. Same daily config as my last report, two changes since (TMax 700→600, Sens 3→5): MSFS:24 Expert Mode:FSR3 TgtFPSOpt:Fixed FltType:IFR TgtFPS:60 TLODMethod:Sens Tol:5 SDet SMult:2.0 SProt TMin:125 TMax:600 TLODBAlt:1500 TLODTAlt:6000 VRAM+:Max Vrec:93% Vhld:96% Vred:98% RTX 3080 Ti (12GB), Citation Sovereign+, LBPD→LFMD, 2h23m, VATSIM, cruise FL430–440. 1. Spike detection: correctly silent for 2h23m. Zero detections, zero reductions. My independent pass over the full PresentMon record agrees — 460 spikes all flight, none periodic (no stable cadence anywhere). So on top of my last flight's true positives, this one is a clean true negative: it stayed quiet with genuinely nothing periodic to act on. Flight was smooth throughout (P99 17.45ms, 0.07% stutter). 2. The VRAM limiter works, but hunts instead of settling. At TLOD 600 my VRAM sits 93–95% in cruise and keeps brushing Vhld 96%. LTD fired 35 times airborne — one for every sample that touched 96%, so the guard is doing exactly its job. But each correction dropped TLOD deep into the 300–400s, VRAM fell to ~75–80%, TLOD ramped back to 600, VRAM crept back toward 96%, repeat — a continuous few-minute sawtooth for most of cruise: t+100min TLOD:477 AGL:43017 GPU:43% VRAM:96% LTD t+101min TLOD:329 AGL:42232 GPU:43% VRAM:95% t+105min TLOD:600 AGL:42800 GPU:44% VRAM:94% (climbing back toward the wall) Mean TLOD by VRAM band (airborne): <80% → 419 · 80–89% → 577 · 90%+ → 591. Is the drop-deep-then-re-probe behavior a deliberate safety-margin choice, or would there be room for the reduction to converge on the TLOD that holds VRAM near target once it's seen the same ceiling a few times? A 12GB card at a high TMax basically lives at Vhld in cruise, so the loop never settles. (The pragmatic fix is obviously on me — I'm dropping TMax to ~500 so I don't live at the limiter — but 12GB cards will meet this a lot, so the loop behavior seemed worth showing.) 3. A thought on FPS-priority reductions when the GPU isn't the constraint. A few TLOD cuts in the same stretch were FPS-driven (Pri:FPS, momentary 58 FPS), and in every one of those samples the log itself shows the GPU ~40% busy with the dominant core pegged: t+101min FPS:58 Pri:FPS TLOD:329 GPU:43% CPU:36% Dom:71%(#0) i.e. the dip was a main-thread stall, which a TLOD cut doesn't relieve on a rig like mine. Worth noting Dom under-states the bind: my per-frame PresentMon capture shows the sim's CPU busy time at 16.47ms of a 16.71ms average frame — ~99% of the frame budget all flight — so the ~71% Dom reading is just 10-second averaging and core-hopping hiding a pegged thread (it sat on core #0 for all 846 samples). Since GPU% and Dom% sit side by side in the line already, would it be worth the FPS path checking which side is actually bound before reducing — same spirit as the own-goal verification you added for spike detection? Or is TLOD simply the only lever, so it fires regardless? Not a complaint — the flight was glass-smooth either way. Log posted on Git.

Periodic spike detection — real detections at normal settings, but SRed never recovers (0.5.2.0-test18) @Reset XPDR — you said you wanted to know whether periodic spikes get detected at more normal settings, and whether they're actually real rather than false detections. I have a data point on both, plus one issue. Setup, nothing exotic — this is my daily config: MSFS:24 Expert Mode:FSR3 TgtFPSOpt:Fixed FltType:IFR TgtFPS:60 TLODMethod:Sens Tol:3 SDet SMult:2.0 SProt TMin:125 TMax:700 TLODBAlt:1500 TLODTAlt:6000 VRAM+:Max Vrec:93% Vhld:96% Vred:98% RTX 3080 Ti (12GB), Citation Sovereign+, KASE→KSEA, 2h14m, offline. 1. The detections are real. Your detector fired on the climb out of Aspen, and the frame time buffer it dumped is textbook — ~16.5–17.4ms baseline with 33–50ms spikes landing about once a second: ...17149, 37251, 16561, ... 17127, 37707, ... 17162, 37812, ... I also log raw PresentMon frame times for the whole flight separately, and an independent pass over that full record found the same thing: 5 periodic episodes at a 0.98–1.02s cadence, interval std 0.00–0.04s. So these aren't false positives, and they turn up at TMax 700 — not just at the 1000–2000 you had to force on your own systems. 2. The issue — SRed accumulates, then never releases. Protection activated three times on the climb (@TLOD 700, 640, 664), while I was in VRAM overflow (Vred firing at 98–99%). SRed built to 384 and then froze there for the remaining ~80 minutes: t+30min SRed:156 TLOD:475 AGL:37722 FPM:-7 GPU:42% VRAM:90% t+50min SRed:384 TLOD:125 AGL:38563 FPM:-23 GPU:41% VRAM:65% t+60min SRed:384 TLOD:316 AGL:37389 FPM:-4 GPU:43% VRAM:74% t+100min SRed:384 TLOD:316 AGL:42901 FPM:1 GPU:44% VRAM:78% TMax 700 − SRed 384 = 316, and TLOD sat pinned at exactly 316 for the rest of the flight — with VRAM back down to 74–78% and the GPU at ~44%, so there was plenty of headroom by then. I was level at FL370–420, hundreds of miles from where it activated and well above TLOD Base, which I thought met your recovery criteria. Does recovery actually make progress in level cruise (VS ≈ 0), or does it need a positive climb rate? If the rate is VS-scaled, level cruise would give near-zero recovery, which would explain what I'm seeing. 3. A thought on the trigger. The spikes that drove SRed occurred while VRAM was at 96–99% and your VRAM limiter was already reducing TLOD for it. Both limiters were reacting to the same root cause — but the VRAM one released when VRAM recovered, and the spike one didn't. Would it be worth suppressing spike accumulation while VRAM limiting is active, since spikes under memory overflow are arguably thrash rather than graphics engine overload? I have the raw 7.3mb log if you want it. - Posted on Git discussion

Ha. Easy enough. The email suggested the link would expire in 48 hours, so it never dawned on me to try it. Appreciate the response.

If you purchased directly from Bijan's store site, how do you update to newer versions?

Some of my observations since the recent SU3 Beta Update. Images and textures seem grainy or a bit fuzzy. Noticed some gradation oddities too. I run the FSR3 frame gen. Dev Mode - Show FPS - Used to show the generated frames (45fps capped in RTSS / Dev Mode would show 90). No Dev Mode Show FPS shows 45. Not sure if it's functioning or not.

My system has no file, including other drives, named ROLLINGCACHE.CCC

C:\Users\<YourUsername>\AppData\Roaming\Microsoft Flight Simulator 2024\ROLLINGCACHE.CCC I'm on Steam, but I believe this is the default for Store.

I did try the search tools suggested, however, since I deleted the temporary directory I created to disable rolling cache and can't recall exactly where or what folder name I created, I'm unable to revert to enabling rolling cache. I’m having trouble restoring the rolling cache in Microsoft Flight Simulator 2024 (Steam version) after using a trick to disable it. Here’s what I did and the issue I’m facing: What I Did to Disable Rolling Cache: I followed a common trick to disable the rolling cache. I created a temporary folder in my Documents directory (C:\Users\[MyUsername]\Documents), named it something (I can’t remember the exact name), and set the rolling cache path to this folder in MSFS 2024’s settings (Options > General > Online). After saving, I closed the sim, deleted the folder, and emptied the Recycle Bin. When I reopened MSFS, the rolling cache showed 0GB, indicating it was disabled, as expected. The Problem: Now I want to re-enable the rolling cache, but I can’t remember the temporary folder’s name, and MSFS seems stuck on that missing path. When I try to set the cache back to the default path (C:\Users\[MyUsername]\AppData\Roaming\Microsoft Flight Simulator 2024) or a new folder, I get an “invalid file size” error. The settings revert to the old (missing) folder path, and the cache size stays at 0GB. I checked UserCfg.opt, but it doesn’t list the rolling cache path. This is preventing me from using the rolling cache, causing performance issues like stuttering during flights. What I’ve Tried: Used EaseUS Data Recovery Wizard to scan the Documents folder for the deleted folder’s name, but it didn’t find it (likely overwritten). Tried resetting the cache in-game by setting the size to 0GB, then choosing a new or default path, but the settings don’t save. Searched for ROLLINGCACHE.CCC files on my 😄 drive and deleted any found, but this didn’t fix the issue. Verified game files in Steam and ensured 😄 has plenty of free space (over 50GB). Questions: Is there a way to reset the rolling cache path without knowing the original folder name? Are there other config files (besides UserCfg.opt) where the cache path might be stored? Has anyone else run into this after using the disable trick? Any fixes? I’m running the latest MSFS 2024 version via Steam on Windows 11. Any help or suggestions would be greatly appreciated! Thanks!

I'm battling a similar problem. I followed the guidance to disable the rolling cache by creating a temporary folder and pointing the Sim to it. Then, I closed the Sim, deleted the temporary folder, and started the Sim, and I confirmed that the rolling cache was disabled by seeing the size was set to 0. I foolishly don't recall what I named my temporary folder in my 'Documents' directory, and from what I can tell, I need to know this to restore the rolling cache. It's been frustrating, and I'm hopeful future updates may address this.

Looking for clarity on something. If I use the FPS Cap method, do I use what I'm locking my frames to (say 60), or what I expect my FPS to be if using Frame Gen or Lossless Scaling (120)?

I'm stumped. I have followed all the steps people have discussed here with the three files and forced profile J under global (hit apply and restarted the PC). However, when I load the sim, the DLSS Indicator shows Profile E is being used. https://imgur.com/a/evqUJTW