FYI, I am readying 0.5.2.0 for release in the next couple days, and the test version has advanced to RC status accordingly.

I was hoping to get confirmation that periodic spike detection was behaving properly before pushing this release. I finally matured the feature to the point where it worked exactly how I wanted… and now, with the latest SU6 beta, I can’t get periodic spikes to trigger at all. So ironically, it looks like I finished polishing the feature right as the sim stopped producing the very spikes it was designed to handle. Such is life!😄

In any case, 0.5.2.0 still will offer the following over 0.5.1.0:

1. Added 2 additional flight type profile slots to Expert mode, bringing the total to 8.

2. Updated non-Expert mode to correctly identify SU5.1.

3. Added flight type profile reset capability in Expert mode to the Reset button's actions.

4. Added dynamic/adaptive FG support via the DynFG option to the Manual FG drop down.

5. Added Periodic spike protection, available when RTSS is running.

6. Improved VRAM+ with reductions now proportional to threshold exceedance.

7. Added FPS dead zone when FG is inactive to prevent unnecessary TLOD reductions.

8. Made Minor UI refinements such as new Pause symbol, generic FSR to replace FSR3 references, and VRAM+ HLD and RED indications.

9. Added ability for the app to be configured to auto exit after a flight session.

10. Improved app auto update reliability.

11. Various minor bug fixes and improvements.

Edited Monday at 03:48 AM4 days by Reset XPDR

3 hours ago, Reset XPDR said:

Those settings you are using should be fine with either version of the app. The setting I am talking about in 0.5.1.0, that could possibly cause audio stutter compared to 0.4.6.6 and is only accessible in non-Expert mode if you go in to Expert settings and enable it in the first place, is this one:

Without that option enabled and with your settings it should look something like this and not cause audio stutters:

Right. I did not enable that in either version I'm using. And I used 5.2RC is that version known to be problematic? Should I try 5.1? 4.6.6. works fine.

3 hours ago, Reset XPDR said:

Those settings you are using should be fine with either version of the app. The setting I am talking about in 0.5.1.0, that could possibly cause audio stutter compared to 0.4.6.6 and is only accessible in non-Expert mode if you go in to Expert settings and enable it in the first place, is this one:

Without that option enabled and with your settings it should look something like this and not cause audio stutters:

Right. I did not enable that in either version I'm using. And I used 5.2RC is that version known to be problematic? Should I try 5.1? 4.6.6. works fine.

52 minutes ago, Virtual-Chris said:

Right. I did not enable that in either version I'm using. And I used 5.2RC is that version known to be problematic? Should I try 5.1? 4.6.6. works fine.

It should not matter whether 0.5.1.0 or 0.5.2.0-RC, but to be safe just try 0.5.1.0 as it has all test overhead removed. 0.5.2.0, should be fine to upgrade to for this matter as well, when it is formally released in the next few days.

4 hours ago, Reset XPDR said:

FYI, I am readying 0.5.2.0 for release in the next couple days, and the test version has advanced to RC status accordingly.

I was hoping to get confirmation that periodic spike detection was behaving properly before pushing this release. I finally matured the feature to the point where it worked exactly how I wanted… and now, with the latest SU6 beta, I can’t get periodic spikes to trigger at all. So ironically, it looks like I finished polishing the feature right as the sim stopped producing the very spikes it was designed to handle. Such is life!😄

In any case, 0.5.2.0 still will offer the following over 0.5.1.0:

1. Added 2 additional flight type profile slots to Expert mode, bringing the total to 8.

2. Updated non-Expert mode to correctly identify SU5.1.

3. Added flight type profile reset capability in Expert mode to the Reset button's actions.

4. Added dynamic/adaptive FG support via the DynFG option to the Manual FG drop down.

5. Added Periodic spike protection, available when RTSS is running.

6. Improved VRAM+ with reductions now proportional to threshold exceedance.

7. Added FPS dead zone when FG is inactive to prevent unnecessary TLOD reductions.

8. Made Minor UI refinements such as new Pause symbol, generic FSR to replace FSR3 references, and VRAM+ HLD and RED indications.

9. Added ability for the app to be configured to auto exit after a flight session.

10. Improved app auto update reliability.

11. Various minor bug fixes and improvements.

Thank you as always, Reset!

I'm using the RC, but I don't use RTSS. I did have a quick question on the right way to configure when looking to maintain the auto TLOD as high as possible on landing. I've currently got it set to FPS Sensitivity with native frame gen and FPS set at 90. It works great to increase TLOD as much as possible on the ground and on climb out.

However, when landing, I always drop from my Max TLOD to my min TLOD by the time I reach my min TLOD altitude. Any way to keep the TLOD maxed as much as the headroom will allow while landing?

I'll go back and read the readme file, just thought I'd ask if anyone knew.

Thank you.

Edited Monday at 04:56 AM4 days by mmcmah

3 hours ago, mmcmah said:

Thank you as always, Reset!

I'm using the RC, but I don't use RTSS. I did have a quick question on the right way to configure when looking to maintain the auto TLOD as high as possible on landing. I've currently got it set to FPS Sensitivity with native frame gen and FPS set at 90. It works great to increase TLOD as much as possible on the ground and on climb out.

However, when landing, I always drop from my Max TLOD to my min TLOD by the time I reach my min TLOD altitude. Any way to keep the TLOD maxed as much as the headroom will allow while landing?

I'll go back and read the readme file, just thought I'd ask if anyone knew.

Thank you.

You say that the app increases TLOD as much as possible on the ground, which implies you are using TLOD Extra to achieve these increases because Fixed would otherwise limit you to TLOD Min. If that is the case, then you should also be able to achieve increased TLOD on landing with available headroom.

Therefore, if you are using TLOD Extra and are not achieving increased TLOD above TLOD Min on landing, the reason would be that you do not actually have the headroom you think you do, which is not uncommon on approaching a complex airport. If you PM me the contents of your log file, located in %appdata%\MSFS_AutoFPS, I can tell you for sure what is going on.

Edited Monday at 08:22 AM4 days by Reset XPDR

21 hours ago, Reset XPDR said:

It should not matter whether 0.5.1.0 or 0.5.2.0-RC, but to be safe just try 0.5.1.0 as it has all test overhead removed. 0.5.2.0, should be fine to upgrade to for this matter as well, when it is formally released in the next few days.

So today I did a few test flights...

• No AutoFPS - I now get occasional stutters without AutoFPS now. I think this is new. Ugh.

• v4.6.6 - Didn't have stutters the other day, but did today. Seems slightly worse than no AutoFPS

• v5.1 - Stutters a fair amount more than 4.6.6 but not as bad as my experience with 5.2RC

I don't know what's going on now. I had several stutter free flights on 4.6.6 over the last few days but now anything has stutters. So probably best to ignore my feedback for now. Not sure whats going on.

Quick question... Is removing the directory in Appdata/Roaming sufficient to completely uninstall? Or is there other elements I need to remove?

1 hour ago, Virtual-Chris said:

So today I did a few test flights...

• No AutoFPS - I now get occasional stutters without AutoFPS now. I think this is new. Ugh.

• v4.6.6 - Didn't have stutters the other day, but did today. Seems slightly worse than no AutoFPS

• v5.1 - Stutters a fair amount more than 4.6.6 but not as bad as my experience with 5.2RC

I don't know what's going on now. I had several stutter free flights on 4.6.6 over the last few days but now anything has stutters. So probably best to ignore my feedback for now. Not sure whats going on.

There should be no difference in stuttering between the three versions of AutoFPS you have tried as they all interface with MSFS the same way. It is probably just MSFS being MSFS.

1 hour ago, Virtual-Chris said:

Quick question... Is removing the directory in Appdata/Roaming sufficient to completely uninstall? Or is there other elements I need to remove?

• To uninstall:

  • Ensure you have completely exited the app (ie. it is not hiding still running in your SysTray),

  • Run the installer and select Remove on the first window.

  • This will remove all traces of the app, including the desktop icon, MSFS or FSUIPC autostart entries if you used them, and the entire app folder, including your configuration file.

Edited Tuesday at 02:31 AM3 days by Reset XPDR

---

AutoFPS 0.5.2.0-RC3 — periodic spike protection fires correctly, but recovery re-arms the trigger

You'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 episodes

Detected 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 did

Activated	@ 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 loop

Then 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 latency

Episodes 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 aircraft

I'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.

---

21 minutes ago, Randall Fortee22 said:

---

AutoFPS 0.5.2.0-RC3 — periodic spike protection fires correctly, but recovery re-arms the trigger

You'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 episodes

Detected 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 did

Activated	@ 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 loop

Then 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 latency

Episodes 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 aircraft

I'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.

---

Just as I was about to formally release 0.5.2.0! 😄

I am looking through your data now but the quick answer is that while recovery is gated by a minimum time, it is distance, altitude and vertical speed trend that determine the recovery rate. ie:

• Minimum activation conditions: step stays at 0 until 30 s have elapsed, distance has grown past 1.5 NM, altitude has risen above the mode‑specific base (500 ft or AltTLODBase), and vertical trend is level flight, so all factors begin contributing.

• Maximum activation conditions: step reaches its full value only after 30 s, distance reaches 5 NM, altitude reaches 3000 ft or AltTLODTop, and vertical trend is a continuous climb, allowing all factors to hit 1.0 and maximise the step multiplier.

I can increase these thresholds if you like, but it looks to me as it was actually working quite well, especially if you didn't even get long enough to notice the periodic stutters. The issue with increasing them too much is that you could be missing out on available TLOD range.

Re:

Detection latency

Episodes 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.

The log shows that while there were spikes in that 100 second time frame, none met the the periodic spike criteria (4+ fresh spikes > 2x of median frame time and the same 0.3-1.8s cadence) until 21:04:26 when they did. This is most likely because most of the spikes you were seeing were below 2x median frame time, wherever you were reading them from. You can reduce that threshold in the common config file (SpikeThresholdMultiplier key) but just be aware that you were the one who had me increase it to 2x as a default as it was triggering too often in earlier iterations of this feature, so chose your poison wisely. FWIW, my own observation is that 2x is just right as there is negligible stuttering when they are just below that - it is the big ones that cause observable stuttering.

Edited Tuesday at 04:12 AM3 days by Reset XPDR

35 minutes ago, Reset XPDR said:

Just as I was about to formally release 0.5.2.0! 😄

I am looking through your data now but the quick answer is that while recovery is gated by a minimum time, it is distance, altitude and vertical speed trend that determine the recovery rate. ie:

• Minimum activation conditions: step stays at 0 until 30 s have elapsed, distance has grown past 1.5 NM, altitude has risen above the mode‑specific base (500 ft or AltTLODBase), and vertical trend is level flight, so all factors begin contributing.

• Maximum activation conditions: step reaches its full value only after 30 s, distance reaches 5 NM, altitude reaches 3000 ft or AltTLODTop, and vertical trend is a continuous climb, allowing all factors to hit 1.0 and maximise the step multiplier.

I can increase these thresholds if you like, but it looks to me as it was actually working quite well, especially if you didn't even get long enough to notice the periodic stutters. The issue with increasing them too much is that you could be missing out on available TLOD range.

Re:

The log shows that while there were spikes in that 100 second time frame, none met the the periodic spike criteria (4+ fresh spikes > 2x of median frame time and the same 0.3-1.8s cadence) until 21:04:26 when they did. This is most likely because most of the spikes you were seeing were below 2x median frame time, wherever you were reading them from. You can reduce that threshold in the common config file (SpikeThresholdMultiplier key) but just be aware that you were the one who had me increase it to 2x as a default as it was triggering too often in earlier iterations of this feature, so chose your poison wisely. FWIW, my own observation is that 2x is just right as there is negligible stuttering when they are just below that - it is the big ones that cause observable stuttering.

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.

4 minutes ago, Randall Fortee22 said:

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.

No worries. I have been testing this feature quite a lot lately and, as I mentioned in a recent post, I have been on the SU6 beta and recently have been unable to reproduce this periodic spikes at all, so it looks like Asobo may fixed it just to spite my efforts to work around it 😄

Re what the RTSS frame buffer contains versus PresentMon, I cannot say for sure. You can see in the logs that the app now does a dump of the first 10 seconds of frame time data whenever you switch graphics mode, so you can perhaps see for yourself eg:

2026-07-27 20:43:28.601 [DBG] [ ServiceController:GetRTSSFrameTi ] BufPos:87 FrameTimesCSV:16605,16886,16630,16570,16641,16873,16659,16690,16577,16541,16625,16893,16621,16696,16614,16390,16722,16967,16581,16631,16582,16714,16664,16489,16853,16740,16592,16517,16621,16913,16601,16691,16618,16775,16625,16708,16571,16718,16582,16597,16702,16837,16544,16728,16622,16682,16718,16744,16586,16657,16616,16712,16648,16699,16644,16693,16600,16472,16651,16866,16576,16743,16613,16688,16604,16902,16651,16445,16665,16813,16662,16542,16657,16728,16716,16520,16680,16681,16736,16680,16498,16592,16629,16890,16697,16683,16658,16826,16672,16573,16706,16715,16632,16558,16652,16841,16581,16788,16637,16640,16688,16474,16594,16975,16622,16531,16715,16543,16576,16808,16589,16807,16637,16559,16632,16920,16631,16553,16642,16667,16628,16487,16663,16878,16646,16714,16774,16340,16802,16765,16728,16625,16658,16729,16615,16576,16648,16845,16500,16904,16587,16677,16625,16399,16772,16854,16642,16651,16620,16853,16578,16662,16616,16720,16630,16757,16617,16671,16637,16595,16658,16735,16690,16602,16644,16440,16669,16486,16589,16554,16629,16500,15977,15863,16249,16167,16224,16166,16217,16211,16221,16143,16195,16253,16253,16218,16088,16345,15901,16470,15935,16568,16691,27128,16661,16784,16655,16580,16637,16922,16576,16688,16606,16592,16610,16914,16595,16509,16606,16948,16570,16751,16585,16688,16629,16771,16568,16735,16626,16526,16619,16718,16600,16878,16617,16607,16608,16635,16747,16713,16626,16542,16646,16779,16613,16786,16638,16731,16630,16610,16597,16797,16620,16557,16668,16619,16721,16859,16584,16586,16625,16818,16597,16670,16763,16474,16673,16774,16638,16796,16581,16584,16643,16816,16645,16779,16611,16674,16605,16611,16566,16765,16603,16811,16604,16612,16627,16891,16586,16721,16546,16709,16595,16815,16571,16507,16590,16478,16655,17061,16654,16445,16818,16488,16671,16600,16731,16541,16663,16617,16756,16573,16615,16797,16662,16587,16767,16801,16650,16573,16687,16630,16679,17053,16637,16605,16644,16782,16659,16791,16591,16631,16630,16487,16730,16782,16616,16840,16592,16699,16621,16578,16719,16736,16593,16720,16570,16668,16599,16722,16606,16738,16604,16696,16613,16594,16693,16566,16645,16608,16646,16635,16646,16599,16607,16726,16711,16305,16710,16931,16768,16746,16675,16793,16751,16635,16692,16541,16831,16664,16662,16585,16695,16597,16869,16304,16872,16837,16661,16550,16716,16513,16683,16343,17112,16758,16715,16591,16669,16627,16689,16778,16670,16339,16750,16492,16856,16530,16877,16484,16684,16597,16865,16451,16878,16580,16813,16573,16823,16510,16667,16647,16762,16595,16683,16677,16612,16686,16672,16780,16646,16525,16701,16660,16733,16702,16690,16552,16646,16564,16756,16757,16529,16920,16630,16674,16647,16690,16637,16556,16541,16813,16708,16357,16814,16832,16559,16611,16841,16675,16644,16800,16661,16672,16640,16536,16614,16873,16618,16537,16587,16928,16644,16594,16638,16565,16667,16837,16641,16726,16628,16603,16697,16554,16689,16780,16648,16571,16720,16558,16642,16667,16828,16535,16806,16496,16757,16672,16702,16651,16658,16766,16620,16593,16707,16469,16814,16710,16663,16631,16593,16810,16648,16490,16841,16576,16624,16763,16766,16419,16633,16946,16557,16658,16632,16432,16626,16390,16656,16413,16595,16459,16574,16483,16593,16359,16670,16460,16632,16394,16635,16354,16699,16488,16597,16489,16641,16213,16862,16507,16660,16427,16614,16567,16174,16177,16304,16310,16483,16553,16469,16502,16483,16532,16369,16410,16210,16223,16042,16141,16000,16201,15656,16232,15983,16446,15679,16348,14775,14759,14037,14039,15383,15167,15577,15186,15825,15366,15847,15512,15910,15626,15952,15750,15954,15702,16063,15722,16963,16554,17717,65958,16715,16474,16927,16822,16620,16548,16719,16803 

From what I have observed, this frame time buffer captures FG frames too because when using nVidia FG every other frame is a really low value, sometimes zero.

16 minutes ago, Reset XPDR said:

No worries. I have been testing this feature quite a lot lately and, as I mentioned in a recent post, I have been on the SU6 beta and recently have been unable to reproduce this periodic spikes at all, so it looks like Asobo may fixed it just to spite my efforts to work around it 😄

Re what the RTSS frame buffer contains versus PresentMon, I cannot say for sure. You can see in the logs that the app now does a dump of the first 10 seconds of frame time data whenever you switch graphics mode, so you can perhaps see for yourself eg:

2026-07-27 20:43:28.601 [DBG] [ ServiceController:GetRTSSFrameTi ] BufPos:87 FrameTimesCSV:16605,16886,16630,16570,16641,16873,16659,16690,16577,16541,16625,16893,16621,16696,16614,16390,16722,16967,16581,16631,16582,16714,16664,16489,16853,16740,16592,16517,16621,16913,16601,16691,16618,16775,16625,16708,16571,16718,16582,16597,16702,16837,16544,16728,16622,16682,16718,16744,16586,16657,16616,16712,16648,16699,16644,16693,16600,16472,16651,16866,16576,16743,16613,16688,16604,16902,16651,16445,16665,16813,16662,16542,16657,16728,16716,16520,16680,16681,16736,16680,16498,16592,16629,16890,16697,16683,16658,16826,16672,16573,16706,16715,16632,16558,16652,16841,16581,16788,16637,16640,16688,16474,16594,16975,16622,16531,16715,16543,16576,16808,16589,16807,16637,16559,16632,16920,16631,16553,16642,16667,16628,16487,16663,16878,16646,16714,16774,16340,16802,16765,16728,16625,16658,16729,16615,16576,16648,16845,16500,16904,16587,16677,16625,16399,16772,16854,16642,16651,16620,16853,16578,16662,16616,16720,16630,16757,16617,16671,16637,16595,16658,16735,16690,16602,16644,16440,16669,16486,16589,16554,16629,16500,15977,15863,16249,16167,16224,16166,16217,16211,16221,16143,16195,16253,16253,16218,16088,16345,15901,16470,15935,16568,16691,27128,16661,16784,16655,16580,16637,16922,16576,16688,16606,16592,16610,16914,16595,16509,16606,16948,16570,16751,16585,16688,16629,16771,16568,16735,16626,16526,16619,16718,16600,16878,16617,16607,16608,16635,16747,16713,16626,16542,16646,16779,16613,16786,16638,16731,16630,16610,16597,16797,16620,16557,16668,16619,16721,16859,16584,16586,16625,16818,16597,16670,16763,16474,16673,16774,16638,16796,16581,16584,16643,16816,16645,16779,16611,16674,16605,16611,16566,16765,16603,16811,16604,16612,16627,16891,16586,16721,16546,16709,16595,16815,16571,16507,16590,16478,16655,17061,16654,16445,16818,16488,16671,16600,16731,16541,16663,16617,16756,16573,16615,16797,16662,16587,16767,16801,16650,16573,16687,16630,16679,17053,16637,16605,16644,16782,16659,16791,16591,16631,16630,16487,16730,16782,16616,16840,16592,16699,16621,16578,16719,16736,16593,16720,16570,16668,16599,16722,16606,16738,16604,16696,16613,16594,16693,16566,16645,16608,16646,16635,16646,16599,16607,16726,16711,16305,16710,16931,16768,16746,16675,16793,16751,16635,16692,16541,16831,16664,16662,16585,16695,16597,16869,16304,16872,16837,16661,16550,16716,16513,16683,16343,17112,16758,16715,16591,16669,16627,16689,16778,16670,16339,16750,16492,16856,16530,16877,16484,16684,16597,16865,16451,16878,16580,16813,16573,16823,16510,16667,16647,16762,16595,16683,16677,16612,16686,16672,16780,16646,16525,16701,16660,16733,16702,16690,16552,16646,16564,16756,16757,16529,16920,16630,16674,16647,16690,16637,16556,16541,16813,16708,16357,16814,16832,16559,16611,16841,16675,16644,16800,16661,16672,16640,16536,16614,16873,16618,16537,16587,16928,16644,16594,16638,16565,16667,16837,16641,16726,16628,16603,16697,16554,16689,16780,16648,16571,16720,16558,16642,16667,16828,16535,16806,16496,16757,16672,16702,16651,16658,16766,16620,16593,16707,16469,16814,16710,16663,16631,16593,16810,16648,16490,16841,16576,16624,16763,16766,16419,16633,16946,16557,16658,16632,16432,16626,16390,16656,16413,16595,16459,16574,16483,16593,16359,16670,16460,16632,16394,16635,16354,16699,16488,16597,16489,16641,16213,16862,16507,16660,16427,16614,16567,16174,16177,16304,16310,16483,16553,16469,16502,16483,16532,16369,16410,16210,16223,16042,16141,16000,16201,15656,16232,15983,16446,15679,16348,14775,14759,14037,14039,15383,15167,15577,15186,15825,15366,15847,15512,15910,15626,15952,15750,15954,15702,16063,15722,16963,16554,17717,65958,16715,16474,16927,16822,16620,16548,16719,16803 

From what I have observed, this frame time buffer captures FG frames too because when using nVidia FG every other frame is a really low value, sometimes zero.

---

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.

13 minutes ago, Randall Fortee22 said:

---

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.

No criticism taken. In fact, I have been impressed with the level of analysis you have done with all of this. I probably wouldn't have taken this feature on if you didn't make it so easy to quantify the issue. Also, just because I will formally release 0.5.2.0 soon doesn't mean it has to be over. If it can be improved further, we can continue on in the next release test build.

MSFS_AutoFPS v0.5.2.0 has just been formally released, available either through auto update in the app or from here. My thanks goes out to all who provided valuable feedback during the test phase.

This release delivers additional profile slots, profile reset capability, Dynamic/Adaptive FG support, periodic spike protection, improved VRAM+, steadier FG‑inactive behaviour, clearer UI and broad reliability fixes.

Please review the release notes and the updated readme here, which provides a detailed description of the app, installation, features and settings, before asking any questions or raising any issues about this new version.