v0.5.2.0-test Minor Maintenance Update

[ResetXPDR]

MSFS Compatibility: 1.39.12.0, 1.7.27.0, 1.7.33.0.

Release notes for 0.5.2.0-test

Test1:

• Updated TLOD Base option visibility so it no longer appears in the UI when using Auto Target FPS, since only Fixed TLOD Base is supported and automatically enforced with that upgrade option.
• Improved update visibility so updates for the selected upgrade option and channel always appear on the status line outside flight sessions, reducing the chance of missing an available update.
• Updated test‑update status line so the app now shows the version number of a newly available test update when advising that one is available.
• Updated settings logging to more clearly indicate whether Expert or Non‑Expert settings are in use.
• Streamlined TLOD/OLOD verification by moving the read/write check out of the Reset function and into the end of the initial memory compatibility check, avoiding repeated runs and preventing false failures after MSFS CTDs.
• Added active OLOD calculation function to centralise the OLOD computation and ensure correct OLOD logging in Non‑Expert mode.
• Removed legacy FPS logging now that Log+ fully replaces the old manual and automatic FPS‑detail logging system.

---

This discussion was created from the release v0.5.2.0-test Minor Maintenance and SU5 Beta Placeholder Update.

[jerryyyyy]

Here is a 2D flight as I am still having VR problems. There were two false starts in VR and eventually I gave up.

2D CJ4 Carribean MSFS_AutoFPS20260613.log

[ResetXPDR]

Here is another long flight (actually 2 legs) that seemed to work well on the wired connections.
Tunis MSFS_AutoFPS20260620.log

Looks pretty good to me:

The Quest actually seems to remain connected and you just pick up to use. At rest it is using 3-5W... wonder if just leave it on shut down. It is drawing 8V through the USB.

Even though I use Wifi, I have my Quest 3 permanently connected to a phone charger and never turn it off, just letting it sleep when I take it off. It has worked fine that way for 2.5 years.

PS Before I forget there is a lot in security news about supply chain attacks on developers. I don't think that you are too vulnerable but I get worried when I see very frequently things like GPU-Z want to update and I wonder how carefully they are checking their repositories and dependencies for malware. Many around here are taking a long time out to update applications (not Windows) to give time for hidden/unrecognized attacks to surface.

Thanks for the heads-up. FYI, I check mine every now and again when someone reports what has always ended up to be a false positive virus/malware detection and have never found any issues in my repositories. This includes packages that I bundle with app, such as the RTSS and GPU-Z interface dlls, which haven't changed at all for more than a year.

[jerryyyyy]

If you are interested in computer security at all here is my source of information that makes an amusing listen:

https://twit.tv/shows/security-now

They get deep into the tech but in general it is humorous. Right now the topics are 80% AI.

I checked the Quest 3 power status and the green light on just means the power is full but it still goes into sleep mode. I am getting some additional wiring today to make the connection more convenient and less of a kluge.

I can keep the device on the floor with the power connection and then just run one USC C extender up to the Quest. (I hope).

FYI, this was a long canyon run in the gyrocopter in VR,

China Canyons MSFS_AutoFPS20260621.log

Looks like I had not looked and it selected the wrong GPU. But ran very smoothly.

[jerryyyyy]

Hi today I took a nice relaxing flight with the Aussi Group and there was a lot of discussion of graphics setting and I thought I would write up a VR cheat sheet. I send it to you because you had asked if I was using "balanced" and I verify that I am. Here is what I said and that insert.

These are my settings that I use to get 72FPS and TLOD of 400 from my set up as wired above.

The graphics pipeline starts from 36 FPS frame limited in MSFS and doubled in the Quest to 72 FPS using the asynchronous spacewarp (ASW), The graphics settings in the NVIDIA APP use the application settings under DLSS, which I have copied into the word file. I use "balanced", which fit my 5080 and are not wasting pixels that are not mapped. Thus there is really only one set of settings that matter. The document provides the MSFS Forum reference where this is discussed.

VR Settings.docx

This is in the same spot where I put the wiring information for a wired Quest.

[ResetXPDR]

Thanks for that document. I use balanced with good success too, in both 2D and VR.

[jerryyyyy]

Yes, I think it is correct. Way back when we went over the math and concluded it was the best compromise.

I rechecked and my 2D is also balanced and it is full 4K screen resolution. There is not a pixel out of place. This is how I look at astronomy images. You can see single pixel lines around some colors that provide edge resolution.... this is really very sophisticated. on the developers part... like in the magenta where best seen.

Fingers crossed but my Q3 has been reliable with those wired connection and settings. I put that information up on the Aussi site also. I think those settings are pretty much what you need to optimize the hardware and I do not think you can get much more out of the existing optics. We tried a few more optimizations and I had to go back.

[jerryyyyy]

I saw you had an updated test version. Here is a partial file with a long lead in and that premature termination of the VR flight.

I may be able to do a longer 2D Reno flight later.

VR Short partial test run MSFS_AutoFPS20260701.log

RNO

2D RNO MSFS_AutoFPS20260701.log

[ResetXPDR]

Thanks for the logs. The new test update (another one today) adds periodic spike detection for situations when the graphics load in MSFS is so high that it starts periodically stuttering. Even with high settings, like yours, it should not normally occur and your logs show that it wasn't detected, so all is good.

If you want to try pushing it to induce these spikes, the instructions are here. With those settings at a complex airport surrounded by PG and a complex aircraft (787 should do the trick), it triggers for me around 1100 TLOD. Note that you need to specifically enable frametime monitoring in MSI AB settings otherwise it won't work eg.

This will show up as follows in the OSD, where you can clearly see the periodic spikes when they occur and are then cleared:

[jerryyyyy]

Yeah, looks pretty demanding but did a long VR flight with the group today that looked good subjectively.

VR MexicoMSFS_AutoFPS20260703.log

[ResetXPDR]

You're getting very solid performance now, with TLOD rarely dropping below 400 during your entire VR run:

[jerryyyyy]

Yes, I think the new versions of MSFS are pretty stable. Here is another from today, only quantify if you are interested. We went to Bogata. I still do not know why I cannot get that display up properly. In the past I had gotten up to > 1000 TLOD in the 787 in 2D with some of your settings. Maybe will try that later.

VR Bogata MSFS_AutoFPS20260704.log

EDIT: I did get up to TLOD1000 manipulating your settings but seemed to be capped at 1000. Maybe you can drop the cap and I can run up to 1200.... who knows.

2D Reno TLOD 1000 MSFS_AutoFPS20260704.log

[ResetXPDR]

In the past I had gotten up to > 1000 TLOD in the 787 in 2D with some of your settings. Maybe will try that later.
I did get up to TLOD1000 manipulating your settings but seemed to be capped at 1000. Maybe you can drop the cap and I can run up to 1200.... who knows.

I posted this over at Avsim the other day, which should help you out here:

The app defaults to a max possible TLOD of 1000, so if you need to go past this you will have to edit your MSFS2024_AutoFPS.config file in the %appdata%\MSFS_AutoFPS folder and edit this key eg.

<add key="simMaxLod" value="2000" />

[jerryyyyy]

When I get the chance will try 1200 and see if I get some perceptible spikes. I still do not see the OSD or where to enable it in MSI...

Had uninstalled RTSS, reinstalled and will see if it works now.

Oh, I see why I had installed it because it limits frame rates and I was doing this entirely in MSFS so I removed it.

Here was an attempt to run with it on and poor performance so I stopped it. Turned MSI & RTSS off and see if I get back to baseline trying to run at TLOD 1200.

2D Reno RTSS MSFS_AutoFPS20260704.log

Back to baseline. Climb out of Reno TLOD close to 1200 and GPU not strained. About 1/3 in did an experiment trying to increase speed 4X with a plug in as was getting late so ignore that data.

2D Reno RTSS Off .log

I recall now that all ran smoother without RTSS and MSI just limiting frames and using DLSS directly in MSFS.

[jerryyyyy]

Took two flights with your new version trying to figure what is going on in my system.

This is without MSI or RTSS at1200 and it can stay at 1200 TLOD without much bother of the GPU. IT does drop on landing and is stepped down on take off also.

2D Reno TLOD 1200 RTSS MSI OFF MSFS_AutoFPS20260705.log

This is just the first part of the flight with RTSS and MSI on this time setting RTSS to 36 with FG target of 72 with DLSS 2X.

Anyway, all settings dropped right down so I only did the first part of the flight (the climb out of Reno).

2D Reno TLOD 1200 RTSS MSI ON Partial Poor Performance Stepped Down MSFS_AutoFPS20260705.log

This is a screen shot of RTSS and MSI... maybe my settings are wrong as they do not look like yours... remember I have a RYZEN 7950X. I do not get the In OSD Text Graph line.

Another mystery... I do get the lightning bolt showing on your program.

[jerryyyyy]

I found there was a new versions of MSI (thought they gave up) so uninstalled everything, rebooted and tried to set up the new version but not sure it worked.

I am not sure this will provide you anything of use.

I did try to start another flight but started OK then deteriorated when I tried to do the normal flight plan edits.

NEW MSI MSFS_AutoFPS20260705.log

[ResetXPDR]

I worked because you had a periodic frame spike detected:
2026-07-05 09:58:55.142 [DBG] [ ServiceController:DetectPeriodic ] Total Spikes: 15, Periodic Spikes: 4, AvgInterval: 0.91s, StdDev: 0.05s, SteadyAvg: 28.1777ms, SteadyStd: 0.8728ms, SpikeFreeAvg: 27.9447ms, SpikeFreeStd: 0.4087ms, SpikeAvg: 30.2096ms, SpikeStd: 0.4471ms, Detected: True
which looked like:

As excited as I am that you are the first tester to produce data like this other than myself, this particular detection turns out to be a false positive as there is too much noise in your frametimes because it occurred when your system was already struggling under reduction settings being active. Nonetheless, it is good that I know this and can now work to filter such instances out.

Please keep testing as this is very helpful. Can I ask that you disable settings reduction in your test profile and set TLOD Min to 100 or even 50 so that there is plenty of headroom for a periodic spike reduction to bring TLOD down without immediately hitting TLOD Min. I find that you don't even need to be moving to test this. Just load up in your 787 at KSFO at a gate, let TLOD start ramping up from min towards 1200 and see if and when periodic detection cuts in and see what it does.

[jerryyyyy]

Yup, looks like you found what you wanted. I did just what you said at SFO with the 787. I could see the TLOD cycling and occasionally the FPS drop. What I can read in the log looks good for spikes....

NEWTEST AT SFO GATE MSFS_AutoFPS20260705.log

PS I do have a touch of worry that this is created by RTSS and MSI... as I do not see this when I run without them. But maybe they are there and I cannot see them without those tools.

I got you a control file with RTSS and MSI off... still seemed to be some FPS stutters but the TLOD appeared to be higher... goes through some larger amplitude cycles... maybe some background process like OneDrive.

NEW TEST WITH RTSS MSI OFF AS CONTROL MSFS_AutoFPS20260705.log

[ResetXPDR]

I could see the TLOD cycling and occasionally the FPS drop. What I can read in the log looks good for spikes....

NEWTEST AT SFO GATE MSFS_AutoFPS20260705.log

Indeed it is detecting valid spike sequences eg. this is the most obvious one I have ever seen:

PS I do have a touch of worry that this is created by RTSS and MSI... as I do not see this when I run without them. But maybe they are there and I cannot see them without those tools.

That is precisely why. RTSS is monitoring, not changing anything, so the app overhead should be negligible. The best way to tell you are getting the spikes without RTSS running is to slowly pan the view when the app has set a very high TLOD that would trigger periodic spike detection if it was running. The view will stutter roughly every 1.1-1.5 seconds.

[jerryyyyy]

Well, you have found another ghost in the machine. I assume you are measuring frametime but a shame I cannot get my OSD to work. I have the latest versions.

Looks like Kevin's spikes are worse than mine. Assuming he has a different processor and GPU, so must be coming from the program (MSFS).

Frankly I never noticed this but will try to pan at high TLOD and see if I see it.

Congratulations?

[jerryyyyy]

Well, you have quite the set up and you still get stutters! Your settings are maxed out so I would expect something on the edge. I have a RTX 5080 and a Ryzen 7950X and seem to have less severe problems, but my settings are not maxed out across the board. I do Ultra on the Trees and Clouds. I do normally run TLOD at 600 in 2D and 400 in VR. I keep the Texture Resolution at Low since I know that eats processors with no apparent visual benefit. Generally my performance is pretty much smooth at 72 FPS using DLSS 2X at Balanced.

Good luck.

[jerryyyyy]

Here is a Group Flight to Greece today I recorded in VR.... looks like stutters in the log... did not notice any visually.

Uploading VR Greece MSFS_AutoFPS20260706.log…

[ResetXPDR]

Test8 is now out. I just tried a quick run at default EGLC, in the default caravan, FSR3 and it detects immediately at TLOD 25! Here is the frametime data set it is triggering on, which shows the app isn't mis-detecting for how I coded it, but in the panning test I did I do not notice these stutters so I am thinking it is too sensitive and needs to look for a fatter/larger spike sequence.

I have guests arriving imminently so will not be able to look at this until at least tomorrow, so I suggest holding off any extensive testing until I do.

BTW, I stayed on the MSFS beta channel and it looks like SU6 Beta just dropped too, with MSFS now showing as 1.8.5.0. At least the app is compatible with the new beta but unfortunately it looks like the noisy stutters are still present.

[jerryyyyy]

I ran the standard Reno flight with the SU6 Beta and your latest version.

I let it sit on the runway at 4000' in Reno and it went through its changes in LOD. I did a scan of the surrounds from the cockpit and you could see a FPS drop and the lightning bolts.

I let it return and took off with the AP to SFO.

AT 16000' over Lake Tahoe and the Mountains you could see some small changes and I did another scan with changes again.

Left it alone and did a chase plane view later with again changes.

Rest of the flight normal and left it on the runway for a while.

There the FreTLOD was 50-387 and stabilized at the later number.

Looks like there are stutters all over the place but in my system I do not notice them much.

2D Reno MSFS_AutoFPS20260707.log

[ResetXPDR]

2D Reno MSFS_AutoFPS20260707.log

My guests have gone now, so I am taking a look at this again. It still looks like it is triggering too easily with the noisy frame generation frame time data sets, so I will tone things down.

I am starting to thing this is a fruitless exercise, as these periodic spikes come with such different characteristics (width, interval, amplitude) in a potential sea of noise and, worse, they vary significantly in notice-ability, ranging from not at all to obvious stutters while panning. Nonetheless, I will persist a few days longer because with the app working with the first SU6 beta out of the box, I have some spare time to look at it.

[ResetXPDR]

I've played with this for a couple of hours now and have found that while I can tune the detection for a particular periodic spike signature and it works, as soon as I change aircraft or gate or airport or FG flavour, the signature changes enough to break it or at the very least make it sporadic enough to not be of use, and that's just on my system let alone anyone else's.

As such, I am going to stop working on it for now and unless I have an epiphany in the next day or so and come up with a magical solution that can read any spike signature and respond with ease I will remove it entirely. The simple fact is that, when FG is used in particular, MSFS is currently very prone to graphics engine stutters and overloads in complex scenarios and really the onus should be on MS/Asobo fixing their mess not me.

My original advice with this periodic spiking issue therefore still stands, namely if you find your app TLOD settings get you into this territory too often, turn them down until they don't.

[jerryyyyy]

I agree from my perspective I just do not notice them. If you think about it if the spikes are of very short duration they will be hard to discern in the rest of the stream. I just cannot see them except on the display that shows they are there but the sim is still running at 60+ FPS at worst. Now for some other situations they are longer and I guess chop things up more.

Not sure what is going on with the other folks that often have higher quality equipment like the 5090 than I do. I know in the Aussi Group there are people with such equipment that have stutters but they often have a lot of other issues like with the signal bandwidth in VR or the like. I sent them all my settings that obviously work and should work with others with the same level of equipment (the electrons are the same). You have to have a baseline starting point. Of course that is always why I always use the baseline Reno flight when in doubt. If you just look in the Reno flight performance is way different at different point in the flight. Imaging using a different flight every day and trying to get consistent settings. Can't change two things at once.

[ResetXPDR]

Alright, after calming down a bit I had go at rewriting the periodic spike detection function using a completely different technique. The results are promising, with it detecting quite reliably with different aircraft, airports and FG/NFR scenarios, and not being trigger happy with low level spiking that is otherwise hard to see visually in-game.

As such I have decided to put it out as Test9 to see how others find it performs. Feel free to drop a few logs of normal flights you do with Test 9 with spike protection enabled. If it is at least semi-useful I will continue refining it, otherwise into the bit bucket it all goes! Thanks.

[jerryyyyy]

Been busy but after a false start took a VR flight to Berlin with the AussiGroup. I think this is your latest version.

VR C-210 Berlin MSFS_AutoFPS20260708.log

[ResetXPDR]

Sorry guys, I have actually read your latest logs and I am look at another detection method entirely with the aim to only trigger on true big stutter causing sequences. I managed to capture the signature of one on my system that looks like this and have been playing with it in my test bed:

You can see not only are there long sequences of higher spike times, but they have matching near zero dips. There are also massive spikes up to 0.19 seconds long and maybe that is what I should look for. Of course this may not be the exact sequence others see, but it is good I have something solid to test against.

[ResetXPDR]

Unfortunately, this latest idea did not pan out so it is back to the drawing board. As I wanted to put out a test release to solve another user's issue, I have temporarily disabled periodic spike detection and reduction in Test10 until I can get my act together.

While I have another idea I am currently pursuing, I am also thinking that I need to better characterise the issue when other testers consider it to be an actual problem rather than me trying to guess. As such, the next test release I will put out will give testers a button to press when they are experiencing periodic stutters that are bad enough to affect their user experience, which will capture the last 10 seconds of frametimes in their log which I can then use to test my next fruity idea against. You will see this in Test11 shortly, so when you do please get those stutters happening, hit record then send me the log. Thanks.

[ResetXPDR]

Test11 is out now.

• Rouse the stutter monster with high TLOD in a complex scenario like:

- Click the Spike Rec button - Send your log so I can see this:

2026-07-09 23:54:42.183 [INF] [ MainWindow:btnSpikeRec_Click ] User initiated recording of last 10s of frame times
2026-07-09 23:54:42.183 [DBG] [ ServiceController:DetectPeriodic ] FrameTimesCSV: 37970,22334,21852,22455,21842,22188,19777,24054,19694,23876,28565,21429,21740,21339,21943,20376,25202,22564,20325,21550,28282,21097,20689,23553,18152,22308,18545,21107,19662,19529,19953,21675,33732,2946,32679,2001,77698,472,38418,1801,44142,2687,33032,1705,33079,1835,36837,1950,35348,1183,97679,1133,121058,21686,22360,9758,32234,21961,20314,23678,21682,23589,22682,23789,24899,22888,67057,22517,21990,21983,23373,21854,23359,21477,22822,20779,21759,20389,23978,22459,24262,22176,24713,21003,23216,21625,20437,19983,17879,21695,18768,20222,19816,21500,34974,1883,34125,2351,77844,541,45858,572,34217,1904,30670,1938,35082,2124,36508,4644,34142,1862,98068,1237,138825,22798,38363,22960,21917,22333,22171,22880,18023,26396,17268,26883,21052,23493,19515,24816,22174,22322,25246,21797,23108,21518,23202,21707,22777,21712,23785,21352,22200,21343,24396,21075,24744,20624,22132,19961,19875,19280,19513,19248,19702,21407,27438,4069,38529,3018,79449,1033,44436,583,34233,1748,33136,1644,33930,1641,34210,4043,34211,1970,98618,1170,139390,23568,31377,25098,21995,22436,21598,24295,22064,22491,21872,22947,20652,24008,21974,22618,22433,22424,22747,22421,19539,24812,22817,20906,25696,20485,23236,21392,23560,21273,23857,21129,23850,20504,24524,19972,19404,23022,18292,20079,19211,21063,31846,1984,32152,1718,81475,500,40656,1404,41533,800,30952,1911,32879,3436,33163,1610,35390,1180,95746,1758,138268,23030,33914,25968,19686,24515,21933,22552,21497,22760,20912,23481,19805,24620,22141,22277,21042,23747,27156,22923,22641,22065,23892,21195,24478,20670,23417,21560,22948,21770,23892,21546,24416,20844,24684,20169,24312,21194,17585,21504,18446,22110,31813,1507,34695,1419,76814,426,44597,735,41279,1512,29206,2160,31993,1558,35042,2267,34618,1594,94238,1171,138933,23412,35284,23883,21848,22764,23027,22538,21856,23295,22197,22660,22622,22600,22269,22283,22657,22342,22411,22286,24601,21725,22630,20887,26438,20510,23764,21478,23294,21323,24952,21159,24083,20822,24997,20570,19211,19452,19852,19396,19256,21113,34295,2037,32952,1450,83145,480,41698,1466,38171,1696,30476,2239,32375,4025,33140,2385,36304,1780,92916,1151,137727,23436,36306,25459,18288,26501,23233,24196,17794,27525,22410,22525,22641,22671,21343,23755,19524,26164,22698,22624,22609,22261,24287,21511,24355,20771,22756,21474,24064,22266,19592,26185,23748,20813,26019,20534,24424,19731,15984,22698,20760,21952,33380,2077,30583
So that I can reproduce for testing and make pretty graphs like:

[jerryyyyy]

Will try to do a flight later but ran across a MSFS bug having to do with spikes... fyi:

https://forums.flightsimulator.com/t/fps-spikes-every-1-2-second-in-the-cockpit-while-stopped-within-a-photogrammetry-area/761785/8

You can see this on the DEV FPS monitor.

[ResetXPDR]

https://forums.flightsimulator.com/t/fps-spikes-every-1-2-second-in-the-cockpit-while-stopped-within-a-photogrammetry-area/761785/8

I hadn't seen this particular bug report, which shows what looks like the same issue, although at a much faster interval than I experience myself. Our fellow tester who originally raised this issue with me @kevinfirth has also raised a bug report here https://forums.flightsimulator.com/t/1hz-stutter-caused-by-photogrammetry-and-tlod/769634

Hopefully when I get some clear frametime data from others on this issue's frametime data, it will be similar to mine. If so, it seems to have two clear signatures which shouldn't be too difficult to detect (he says after failing numerous times trying other ways to do this already 😆 ) because the first is a very distinct sawtooth pattern where frametimes vary nearly +- the median for around 10 cycles and the second is the mega high single frametime spike of at least 5x the median at the end of the sawtooth pattern.

[jerryyyyy]

Well good luck, it looked suspicious to me. Here is a log from a long flight today I think with your latest update. Looked different.

VR Borneo MSFS_AutoFPS20260709.log

Have had a couple system crashes recently one fingering MSI. Will not run unless necessary for testing.

[ResetXPDR]

Test12 has just been released with what hopefully addresses the large single spike periodic sequences that have been regularly coming up in my test runs when the issue is present. These spikes have to be very large, being the greater of either 3x your median frame time or 100ms, consistently periodic and numerous enough to not be accidental to be detected which should correspond with visually noticeable periodic stutters. I have also re-enabled TLOD reduction when these detections occur because it should be far less sensitive than before.

Hopefully this will work much better. If not, I will focus on the detecting the other main indicator I saw in my runs, namely the sawtooth patterns preceding a big spike. The app will now auto capture the 10s frame time data when it detects what it thinks is a valid sequence, so I will see that in your logs and just need you to verify that it did it under appropriate conditions. If it is not detecting when you think it should, hit that spike record button then tell me what approx time to look for in your log so that I can fish it out and analyse it.

Example log of a solid hit is as follows:

TLOD marching up from 600, encounters first hint of spikes at 980, pauses and they go away so it gets as high as 1040 whereby they don't go away by pausing, so down TLOD comes

Here is a mid reduction detection log segment:

2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=30 rawUs=203228 elapsedUs=769586
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=92 rawUs=198372 elapsedUs=2129926
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=154 rawUs=211139 elapsedUs=3518736
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=216 rawUs=210292 elapsedUs=4902569
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=278 rawUs=209329 elapsedUs=6285511
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=340 rawUs=207537 elapsedUs=7685353
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=402 rawUs=198763 elapsedUs=9056135
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=30 idxCurr=92 intervalUs=1360340
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=92 idxCurr=154 intervalUs=1388810
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=154 idxCurr=216 intervalUs=1383833
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=216 idxCurr=278 intervalUs=1382942
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=278 idxCurr=340 intervalUs=1399842
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=340 idxCurr=402 intervalUs=1370782
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=1 intervalUs=1360340
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=2 intervalUs=2749150
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=3 intervalUs=4132983
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=4 intervalUs=5515925
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=5 intervalUs=6915767
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=6 intervalUs=8286549
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=1 j=2 intervalUs=1388810
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=1 j=3 intervalUs=2772643
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=1 j=4 intervalUs=4155585
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=1 j=5 intervalUs=5555427
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=1 j=6 intervalUs=6926209
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=2 j=3 intervalUs=1383833
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=2 j=4 intervalUs=2766775
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=2 j=5 intervalUs=4166617
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=2 j=6 intervalUs=5537399
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=3 j=4 intervalUs=1382942
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=3 j=5 intervalUs=2782784
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=3 j=6 intervalUs=4153566
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=4 j=5 intervalUs=1399842
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=4 j=6 intervalUs=2770624
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=5 j=6 intervalUs=1370782
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] SortedIntervals count=21 min=1360340 max=8286549
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=1360340
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=1370782 diff=10442
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=1382942 diff=12160
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=1383833 diff=891
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=1388810 diff=4977
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=1399842 diff=11032
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=6 first=1360340 last=1399842
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=2749150
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=2766775 diff=17625
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=2770624 diff=3849
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=2772643 diff=2019
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=2782784 diff=10141
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=5 first=2749150 last=2782784
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=4132983
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=4153566 diff=20583
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=4155585 diff=2019
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=4166617 diff=11032
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=4 first=4132983 last=4166617
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=5515925
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=5537399 diff=21474
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=5555427 diff=18028
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=3 first=5515925 last=5555427
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=6915767
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=6926209 diff=10442
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=2 first=6915767 last=6926209
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=8286549
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=1 first=8286549 last=8286549
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] LargestCluster size=6 first=1360340 last=1399842 periodicityUs=1383833
2026-07-10 16:55:36.021 [DBG] [ ServiceController:DetectPeriodic ] PeriodicCheck earliestIdx=30 earliestElapsedUs=769586 clusterPeriodUs=1383833 clusterMaxIntervalUs=1399842

Decoded, this says it found 6 consistent 1.38s interval ~ 200ms fresh spikes, so that's a solid detection of 7 spikes.

After a few more of these while reducing TLOD, there are no more spikes and TLOD has settled at 880

[ResetXPDR]

To add to this I have not been able to get nVidia FG working on my system for a couple of weeks but this afternoon I DDUed and reinstalled a bunch of stuff and got it working. I was worried that its periodic spike signature may be different enough from the FSR3 FG I have been using alternatively that the detection wouldn't work. Turns out it is different by having every other frame very low, presumably when FG is doing its thing and explaining why the frametime graphs look coloured-in, but that did not impact it detecting correctly, so that is good.

2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=50 rawUs=120108 elapsedUs=963195
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=112 rawUs=119413 elapsedUs=2147147
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=174 rawUs=119122 elapsedUs=3330930
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=236 rawUs=118978 elapsedUs=4500495
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=298 rawUs=126399 elapsedUs=5704336
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=360 rawUs=123864 elapsedUs=6920454
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=362 rawUs=116494 elapsedUs=7037273
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=50 idxCurr=112 intervalUs=1183952
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=112 idxCurr=174 intervalUs=1183783
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=174 idxCurr=236 intervalUs=1169565
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=236 idxCurr=298 intervalUs=1203841
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=298 idxCurr=360 intervalUs=1216118
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] Interval idxPrev=360 idxCurr=362 intervalUs=116819
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=1 intervalUs=1183952
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=2 intervalUs=2367735
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=3 intervalUs=3537300
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=4 intervalUs=4741141
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=5 intervalUs=5957259
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=0 j=6 intervalUs=6074078
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=1 j=2 intervalUs=1183783
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=1 j=3 intervalUs=2353348
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=1 j=4 intervalUs=3557189
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=1 j=5 intervalUs=4773307
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=1 j=6 intervalUs=4890126
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=2 j=3 intervalUs=1169565
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=2 j=4 intervalUs=2373406
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=2 j=5 intervalUs=3589524
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=2 j=6 intervalUs=3706343
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=3 j=4 intervalUs=1203841
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=3 j=5 intervalUs=2419959
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=3 j=6 intervalUs=2536778
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=4 j=5 intervalUs=1216118
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=4 j=6 intervalUs=1332937
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] AllIntervals i=5 j=6 intervalUs=116819
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] SortedIntervals count=21 min=116819 max=6074078
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=116819
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=1 first=116819 last=116819
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=1169565
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=1183783 diff=14218
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=1183952 diff=169
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=1203841 diff=19889
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=1216118 diff=12277
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=5 first=1169565 last=1216118
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=1332937
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=1 first=1332937 last=1332937
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=2353348
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=2367735 diff=14387
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=2373406 diff=5671
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=2419959 diff=46553
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=4 first=2353348 last=2419959
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=2536778
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=1 first=2536778 last=2536778
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=3537300
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=3557189 diff=19889
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=3589524 diff=32335
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=3 first=3537300 last=3589524
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=3706343
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=1 first=3706343 last=3706343
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=4741141
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterAdd value=4773307 diff=32166
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=2 first=4741141 last=4773307
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=4890126
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=1 first=4890126 last=4890126
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=5957259
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=1 first=5957259 last=5957259
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterStart value=6074078
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] ClusterEnd size=1 first=6074078 last=6074078
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] LargestCluster size=5 first=1169565 last=1216118 periodicityUs=1183952
2026-07-10 19:01:18.524 [DBG] [ ServiceController:DetectPeriodic ] PeriodicCheck earliestIdx=50 earliestElapsedUs=963195 clusterPeriodUs=1183952 clusterMaxIntervalUs=1216118

Hopefully other tester's logs show the same good results.

[jerryyyyy]

Hi,

I looked at the first 1/3 of the previously enclosed "Borneo" flight that is 2h in VR at TLOD 400 and I did not see any glitches visually or in the log. It runs at 36 FPS that goes to 2X FG and the GPU and CPU are not overloaded. (Frankly this looks very good beyond what I ever could have hoped for when I started VR... the 2D runs of course even better).

Not sure what else I can look at or run. I have another long Aussi flight today in a different aircraft.

Here is the long flight from today. We had to change aircraft so a bit disjointed. I did not watch closely but no obvious stuttering I could see.

VR Tetons MSFS_AutoFPS20260710.log

[ResetXPDR]

Thanks for the logs nonetheless, as it shows it is no longer super sensitive. It really should only happen at complex airports in PG areas at very high TLOD.

Periodic stutter hunting aside, it is amazing how high we can push TLOD nowadays, especially in VR, and still get our desired FPS.

[jerryyyyy]

One more from today. I guess the more variations perhaps the more learning? This is the CJ4 in VR in not very comp[lex airports but seemed to run more slowly. A lot of factors.

VR Oregon MSFS_AutoFPS20260711.log

[ResetXPDR]

One more from today. I guess the more variations perhaps the more learning? This is the CJ4 in VR in not very comp[lex airports but seemed to run more slowly. A lot of factors.

VR Oregon MSFS_AutoFPS20260711.log

No periodic spike detections in this flight at all, which I would expect because your VR Max TLOD was a reasonable 400. Again, at least no false positives.

[jerryyyyy]

2D Oregon MSFS_AutoFPS20260712.log

[jerryyyyy]

One more long flight looking a geysers with the Aussis. One of the organizers (Phibzy) is having chronic stutters despite a high end system (believe 5090). It is beyond what I would normally see as problems since he has 5G bandwidth but gets red lines occasionally showing up on the DEV FPS indicator. Only thing I can think off is intermittent internet issues of something like OneDrive or a background process.

He had them on this flight. Have not mentioned your software but he would be a good candidate to run it to find out what is happening, if you know him.

VR Geisers MSFS_AutoFPS20260712.log

Cheers,

JY

[jerryyyyy]

Curious why I do not see it badly (not asking for it) but you see it on Kevin's system and Phil seems to have it in spades. He had it on the same flight I recorded and I just looked at it and it was pretty demanding VR but not at the level of sitting at the gate in SFO with all that is going on there. Maybe Phil has all his settings cranked up even higher than mine. It seems to come and go with him. Only thing I could suggest for Phil was shut off the PG based on that Forum thread. I verified mine is ON. I am on a very reliable GB fiber connection at the University and it runs at close to a real GB. Maybe that makes a difference. I doubt it as you really do not need that much bandwidth.

[ResetXPDR]

You could always get Phil to run the latest test version, hit spike record when he is experiencing these spikes, send me the log then I can take a look. The main hurdle here is getting Phil to have MSI AB installed and configured correctly to share the frame time buffer (remember the struggle you had to achieve this!) then be able to find and share his log, ie he needs to be fairly tech savvy to get this working. If you are willing to work with him to get him configured and recording, then by all means I will take a look at anything he sends and see whether it is what we are currently hunting or if it is something else entirely.

[jerryyyyy]

Let me think about it. Not too sure Phil would follow my technical advice, but if I could cite you maybe. If he were running AUTOFPS, the easiest first step might be to look at a log then try to get MSI installed.

[ResetXPDR]

I have helped Phil with AutoFPS config a long time ago, when he was having performance issues on his system at the time, so he is aware of me and my app. I don't know if he runs it any more (many users with 5090s and 9800X3Ds think they don't need to, despite it still being possible to get low FPS because TLOD is too high where it doesn't need to be).

Anyway, even without my app potentially painting what the performance picture of the issue is for him, he can simply try manually changing TLOD to progressively lower levels as a test and see if the stutters go away. If they do, then AutoFPS could help him out, even without relying on the experimental periodic spike capability. ie. The issue could probably be resolved by setting lower TLOD on the ground through the app.

[jerryyyyy]

Well, will see how it works out. My last suggestion for him after I verified that his 5G connection was good was to drop the settings to LOW and see if the stutter goes away. If it does not, then it is some other structural/hardware issue.... will try to run the new version when I get time later today maybe...

[ResetXPDR]

Test13 has been released with a major rewrite of the UI for the periodic spike detection/protection feature, mostly so that you can tweak a few key settings on the fly and see the real time status of the detection logic in its own status line:

Associated release notes/instructions are:

• Redesigned the UI for the periodic spike detection feature, adding user‑adjustable controls on a revealable panel shown when spike detection is enabled:
  • Moved the Spike Prot checkbox from beside the Sens textbox into the revealable panel, and added a Spike Det checkbox in its place to independently enable or disable periodic spike detection.
  • When Spike Det is enabled, detected periodic spikes display a lightning bolt icon next to the FPS reading.
  • When Spike Prot is enabled, TLOD reduces when periodic spikes are detected, and the TLOD range shows a lightning bolt icon to indicate active reduction.
  • Added a Spike Multiplier textbox (1.1×–10.0×, default 2.0×) to adjust the spike‑detection threshold relative to the median frame time, allowing users to tune sensitivity for their system and scenery.
  • Added a Spike Detection Status line showing whether detection is dormant or, when active, the current detection outcome.
• Changed 2 seconds periodic spike verification to reduce to 1 second if the last tlod change was not a TLOD increase, allowing faster response to persistent periodic spikes while still preventing false positives from TLOD‑driven cadence offsets.

The best way to test with it is to start with a scenario where you usually get periodic spikes, enable detection and observe outcome of the detection logic on the new status line. If necessary, adjust the spike multiplier up or down for it to detect when you think it should. If it still doesn't detect, hit spike record and point the timestamp out to me in your log file. If it does detect, let me know what multiplier was best. If you want to see it rectify a detection, enable protection.

[jerryyyyy]

Here is a short flight into SFO. Did not see any apparent stutters but this is high workload theoretically.

3D NUQ MSFS_AutoFPS20260713.log

[ResetXPDR]

Are you sure you have Spike Det enabled and RTSS is configured properly to share the frame time buffer, as your log contains no spike log entries at all, not even No large spikes detected messages?

Spike Det should be have been enabled by default with the Test13 update, so it is not likely that. If you don't have RTSS configured correctly you would have seen Awaiting RTSS frame time data for the entire flight. If that was the case, you need to reconfigure MSI AB to share that data.

With RTSS frame time buffer data available to the app, at a minimum you should have seen the No large spikes detected when you are in a flight and FPS settle is not active:

Even when detecting no spikes like this, the log should look similar to this:

2026-07-14 08:00:03.929 [DBG] [ LODController:OutputPerfLog      ] FPS:35.3/36.0/Δ+15.3 TLOD:1200/1190 AGL:15 CPU:60% Dom:75/75%(#2) MSFS:50/50% Top2Avg:77/79% GPU:81% VRAM:70% 
2026-07-14 08:00:03.929 [DBG] [ ServiceController:DetectPeriodic ] PeriodicDetect medianUs=27765 multiplier=2 floorUs=0 thresholdUs=55530 spikeCount=1 
2026-07-14 08:00:03.929 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=281 rawUs=87681 elapsedUs=8010026 
2026-07-14 08:00:03.929 [DBG] [ ServiceController:DetectPeriodic ] NoIntervals: no spikes or no valid intervals → periodic detection skipped 
2026-07-14 08:00:04.961 [DBG] [ LODController:OutputPerfLog      ] FPS:35.5/35.0/Δ+15.5 TLOD:1200/1190 AGL:15 CPU:61% Dom:75/77%(#2) MSFS:50/53% Top2Avg:78/82% GPU:81% VRAM:70% 
2026-07-14 08:00:04.961 [DBG] [ ServiceController:DetectPeriodic ] PeriodicDetect medianUs=27765 multiplier=2 floorUs=0 thresholdUs=55530 spikeCount=1 
2026-07-14 08:00:04.961 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=318 rawUs=87681 elapsedUs=9051622 
2026-07-14 08:00:04.961 [DBG] [ ServiceController:DetectPeriodic ] NoIntervals: no spikes or no valid intervals → periodic detection skipped 

[ResetXPDR]

FYI, I am working on an update to improve logging and messaging for periodic spike detection that should be out in the next hour or so.

[ResetXPDR]

Test14 has been released, with the following changes that mainly improve periodic spike detect logging and status messaging:

• Improved periodic spike detection:
  • Added logging of the new Spike Mult and Spike Det settings.
  • Changed spike detection settings changes to always require a UI reload in order to force logging of all current settings.
  • Added logging of RTSS frame buffer being empty every 10 seconds when RTSS is running, to indicate that RTSS is not currently providing frame time data to the app.
  • Updated RTSS frame‑time reading to start at the true newest sample, ignore zero values, and maintain consistent newest‑first ordering across reads.
  • Revised RTSS and periodic spike detection status line messaging to provide clearer information, including RTSS, MSFS, flight session and FPS settling states and spike detection status.

eg if RTSS is not running you will see:

Other state messages are:

• Awaiting MSFS connection
• Awaiting flight session
• Awaiting FPS settling
• RTSS frame time data unavailable

Spike detection status messages have been refined too.

Now someone get out there and detect some periodic spikes! 😄

[jerryyyyy]

Here is some helicopter practice NUQ/SFO.

VR NUQ SFO Bell 407 MSFS_AutoFPS20260715.log

They did eventually have the Aussi flight but only partial.

Uploading VR Germany C 210 MSFS_AutoFPS20260715.log…

[ResetXPDR]

Your second log did not come through as the link for it takes me to this discussion topic, but the first one did and has a few spikes in very quick succession and the detection function correctly discarded them, so all good.

[jerryyyyy]

VR Germany C 210 MSFS_AutoFPS20260715.log

Late night astronomy here but let me see if this uploaded correctly. [seems a 3.1MBdownload]

[jerryyyyy]

One more today C-208

VR C 208 Borneo MSFS_AutoFPS20260716.log

[ResetXPDR]

Sorry, I got distracted with snkeye95's issue from today, which I think I have resolved, but I have been looking at your logs.

Of the last three logs, and I have seen this before with your logs, this one VR Germany C 210 MSFS_AutoFPS20260715.log shows attempted detection of a couple of continuous sequence of spikes, ie. a wide spike sequence, that end up getting rejected as their cadence is too short eg.

2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] PeriodicDetect medianUs=27777 multiplier=2 floorUs=0 thresholdUs=55554 spikeCount=12 
2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=134 rawUs=64241 elapsedUs=4048211 
2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=140 rawUs=62743 elapsedUs=4351384 
2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=141 rawUs=68134 elapsedUs=4419518 
2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=142 rawUs=67204 elapsedUs=4486722 
2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=143 rawUs=66396 elapsedUs=4553118 
2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=144 rawUs=87453 elapsedUs=4640571 
2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=145 rawUs=121040 elapsedUs=4761611 
2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=146 rawUs=582920 elapsedUs=5344531 
2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=147 rawUs=132470 elapsedUs=5477001 
2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=149 rawUs=61142 elapsedUs=5565932 
2026-07-15 12:24:00.337 [DBG] [ ServiceController:DetectPeriodic ] Reject: periodicityUs=132470 outside allowable range [300000..1800000] 

Technically there is no cadence because they are contiguous. I will have a think about whether to filter these out earlier, count them as one wide spike, or just leave it be because they get caught later in the cadence checker anyway. I am away tomorrow so it will probably be the day after I get to look at this again.

[snkeyez95]

MSFS_AutoFPS20260716.log

Follow up to RandallForte22 forum post.

[ResetXPDR]

Thanks for the log and your detailed description of events over on Avsim.

Firstly, here is the frametime graph of your first confirmed detection @ FL332 when you were at TLOD Max of 700 while climbing:

As you say, a text book detection, which I am really pleased with. In this particular instance it did reduce and recover as follows, so it worked as expected at least once:

2026-07-16 14:42:28.640 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:60 Pri:FPS TLOD:700 TLODRng:125-700 OLOD:120 AGL:33164 FPM:1439 GPU:47% VRAM:96% LTD CPU:44% Dom:73%(#0) Top2Avg:70% MSFS:33% 
2026-07-16 14:42:38.793 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:56 Pri:FPS SRed:12 TLOD:700 TLODRng:125-700 OLOD:120 AGL:33402 FPM:1494 GPU:47% VRAM:96% LTD CPU:44% Dom:74%(#0) Top2Avg:72% MSFS:33% 
2026-07-16 14:42:48.944 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:60 Pri:FPS SRed:24 TLOD:676 TLODRng:125-676 OLOD:120 AGL:33856 FPM:1211 GPU:47% VRAM:97% LTD CPU:44% Dom:72%(#0) Top2Avg:69% MSFS:32% 
2026-07-16 14:42:59.100 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:60 Pri:FPS SRed:24 TLOD:676 TLODRng:125-676 OLOD:120 AGL:34128 FPM:991 GPU:47% VRAM:95% LTD CPU:51% Dom:73%(#0) Top2Avg:68% MSFS:32% 
2026-07-16 14:43:09.255 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:60 Pri:FPS SRed:24 TLOD:676 TLODRng:125-676 OLOD:120 AGL:33865 FPM:1403 GPU:47% VRAM:96% LTD CPU:46% Dom:72%(#0) Top2Avg:67% MSFS:33% 
2026-07-16 14:43:19.406 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:58 Pri:FPS SRed:5 TLOD:640 TLODRng:125-693 OLOD:120 AGL:33875 FPM:1366 GPU:42% VRAM:97% LTD CPU:46% Dom:73%(#0) Top2Avg:70% MSFS:35% 
2026-07-16 14:43:29.539 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:60 Pri:FPS SRed:41 TLOD:640 TLODRng:125-659 OLOD:120 AGL:34173 FPM:1357 GPU:47% VRAM:95% CPU:45% Dom:69%(#0) Top2Avg:67% MSFS:34% 
2026-07-16 14:43:39.690 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:60 Pri:FPS SRed:41 TLOD:659 TLODRng:125-659 OLOD:120 AGL:34571 FPM:1014 GPU:47% VRAM:94% CPU:46% Dom:74%(#0) Top2Avg:71% MSFS:34% 
2026-07-16 14:43:49.849 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:60 Pri:FPS SRed:41 TLOD:659 TLODRng:125-659 OLOD:120 AGL:35008 FPM:1105 GPU:47% VRAM:95% CPU:48% Dom:74%(#0) Top2Avg:73% MSFS:33% 
2026-07-16 14:44:00.011 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:60 Pri:FPS SRed:26 TLOD:665 TLODRng:125-672 OLOD:120 AGL:35444 FPM:1194 GPU:47% VRAM:95% CPU:44% Dom:73%(#0) Top2Avg:70% MSFS:34% 
2026-07-16 14:44:10.167 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:60 Pri:FPS TLOD:670 TLODRng:125-697 OLOD:120 AGL:36100 FPM:1273 GPU:46% VRAM:95% CPU:43% Dom:74%(#0) Top2Avg:71% MSFS:34% 
2026-07-16 14:44:20.332 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:60 Pri:FPS TLOD:700 TLODRng:125-700 OLOD:120 AGL:36335 FPM:1546 GPU:46% VRAM:96% CPU:50% Dom:74%(#0) Top2Avg:68% MSFS:34% 
2026-07-16 14:44:30.491 [INF] [ LODController:UpdateVariables    ] Mode:FSR3 FPS:60 Pri:FPS TLOD:700 TLODRng:125-700 OLOD:120 AGL:36250 FPM:981 GPU:47% VRAM:96% LTD CPU:53% Dom:76%(#0) Top2Avg:71% MSFS:34% 

Then, as you say, it happened again dropping down over a few minutes to a capped max TLOD of 316, where it stayed for the rest of the flight, despite your aircraft being level in cruise for the next 54 minutes, after which you commenced descent.

I've looked into this and the reason is likely a combination of your Sens value of 3 being low, especially for such a large TLOD range, and that vertical speed trend, even at cruise, is factoring in too much, resulting in a rounded recovery TLOD step value ie. no recovery. Specifically with vertical speed trend, level flight is allowed but it severely reduces the recovery rate, as it turns out unnecessarily at cruise.

As such, I will put out a new update shortly that tones down the VS trend influence quite drastically, to the extend where it will only start to come into play at Alt TLOD Top and proportionally increase its influence to max by Alt TLOD Base, by which time you are in final approach and shouldn't really want TLOD increase then anyway. I will also add extra logging to recovery events so that I can clearly see what is going on when attempting recovery and, as you suggested at Avsim, exclude settings reductions events (VRAM+ or FPS driven) from activating spike protection while present.

I also recommend you put your Sens value back to at least the default of 5 when using such a high TLOD Max of 700.

BTW, thanks for your detailed explanation of events and provision of your log without my prompting. Makes it a lot easier for me to find or reproduce and fix!

[ResetXPDR]

I think I have sorted it in Test19 just released, which has the following of relevance:

• Improved periodic spike detection:
  • Refined vertical‑trend blending to improve stability in spike‑recovery calculations, ensuring smoother transitions between raw trend input and altitude‑based weighting.
  • Hardened spike‑reduction gating to also require auto‑settings reduction to be inactive, ensuring recovery only runs in pure spike‑reduction mode.
  • Expanded LogPlus diagnostics to expose all recovery‑factor inputs and final step values, providing full visibility into spike‑recovery behaviour for empirical debugging.
  • Added spike‑recovery status reporting to indicate recovery in progress by showing the current TLOD recovery step value in the spike detection status line.

eg. showing spike recovery in action:

Re the vertical trend change, in simple terms it means the existing weighting applies maximally below Alt TLOD Base, is ignored above Alt TLOD Top and proportionally weighted in between. For your flight that you provided me the log, the only factor in play in late climb and cruise for recovery was distance since last reduction and, according to my rough calculations, with this new code the aircraft you flew would have started recovering within the minimum 30 seconds delay I still have imposed and would have met the distance requirement of 1.5nm at the 12 second mark within that so would have started increasing at that 30 second mark.

Give it a go and let me know if that has fixed it. Send the log either way.

[snkeyez95]

Quick work, thanks. I'll be sure to check it out. Respect your great work.

[jerryyyyy]

Most recent version.

VR Spain MSFS_AutoFPS20260717.log

[jerryyyyy]

Instrument approach into Katmandu. 2D.

Nepal MSFS_AutoFPS20260718.log

[ResetXPDR]

Thanks. A couple of quick succession spikes in both of these logs, but nothing that resulted in a false positive. eg:

2026-07-17 11:50:42.368 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=2 rawUs=62760 elapsedUs=165210
2026-07-17 11:50:42.368 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=5 rawUs=81760 elapsedUs=349325
2026-07-17 11:50:42.368 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=6 rawUs=109855 elapsedUs=459180
2026-07-17 11:50:42.368 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=7 rawUs=120046 elapsedUs=579226
2026-07-17 11:50:42.368 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=8 rawUs=739612 elapsedUs=1318838
2026-07-17 11:50:42.368 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=9 rawUs=141260 elapsedUs=1460098
2026-07-17 11:50:42.368 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=10 rawUs=139830 elapsedUs=1599928
2026-07-17 11:50:42.368 [DBG] [ ServiceController:DetectPeriodic ] Spike idx=12 rawUs=59736 elapsedUs=1695167

(wow, that 739612 ms spike is the biggest one I have ever seen!)

Having a think about what to do with them right now, but since they are one off and not causing false positives then the answer is probably nothing more than count them as a single spike, counting only the biggest one a continual sequence like this.

[jerryyyyy]

I really wonder if these are not some hidden Windows processes that raise their ugly head once in a while, like OneDrive. I can tell you it is bad with the University computers that are brought to their knees by all the security systems. Citrix, Bigfix, CrashPlan to name just a few... this would be different across machines....

[ResetXPDR]

I'm just about to roll out a fix for this, which will collapse contiguous spikes into a single peak entry, so the peaks in that last graph I posted would be:

Edit: It is in Test20 that has just been released.

[snkeyez95]

MSFS_AutoFPS20260718.log

Log for Randall Fortee22's post on forum.

[jerryyyyy]

One more VR with high detail.

Seattle Gyrocopter MSFS_AutoFPS20260719.log

[ResetXPDR]

Nothing of note in that one as it doesn't appear you had RTSS running.

[jerryyyyy]

Busy today but wanted to take an SFO Gate file for you. There has been some discussion on the MS Forum about improvements in DLSS. The implication is you can use more demanding settings. In this I switched from Balanced to Quality in the middle. I really need to do ABA testing but rendering changes from 2227x1101 to 2560x1357 in the DEV FPS window.

SFO Balanced versus Quality MSFS_AutoFPS20260720.log

Had some time to take a short local flight at the higher setting (Quality). I thought I saw a spike/stutter but did not see much in the log. IMHO the VR looks better at this setting as long as it does not bother the frame rate.

VR Quality C-208 NUQ MSFS_AutoFPS20260720.log

[ResetXPDR]

SFO Balanced versus Quality MSFS_AutoFPS20260720.log

VR Quality C-208 NUQ MSFS_AutoFPS20260720.log

RTSS was running this time but again no actual periodic spike detections. Nonetheless, your partial detects are helping me fine tune early exit code, so I have two new changes that will go into the next release that are derived from these logs:

• Added early‑exit to periodic spike detection so it stops when fewer than 4 spikes are found, since at least 3 intervals are required for periodicity.
• Removed redundant interval‑empty check in periodic spike detection, as new early‑exit logic prevents reaching that state.

[jerryyyyy]

Latest version. AT higher "Quality" DLss level.

2D VR RNO 787 MSFS_AutoFPS20260721.log

[jerryyyyy]

Incomplete run from today but has your new version.

VR Germany MSFS_AutoFPS20260722.log

[ResetXPDR]

VR Germany MSFS_AutoFPS20260722.log

A minor anomaly with the median not showing as its usual 27777 after a long run on 36.0 FPS, which it equates to, that I've seen in all your previous logs. eg. after 10 seconds at 36.0 in previous logs it has usually been similar to:

2026-07-21 12:43:30.354 [DBG] [ LODController:OutputPerfLog      ] FPS:36.0/36.0 TLOD:1127/1127 AGL:8753 CPU:18% Dom:41/38%(#8) MSFS:19/15% Top2Avg:54/50% GPU:41% VRAM:71% 
2026-07-21 12:43:30.355 [DBG] [ ServiceController:DetectPeriodic ] PeriodicDetect medianUs=27777 multiplier=2 floorUs=0 thresholdUs=55554 spikeCount=0 
2026-07-21 12:43:30.355 [DBG] [ ServiceController:DetectPeriodic ] NoIntervals: no spikes → periodic detection skipped 

Whereas in this log it shows as:

2026-07-22 11:58:40.994 [DBG] [ LODController:OutputPerfLog      ] FPS:36.0/36.0/Δ0.0 TLOD:400/395 AGL:4 CPU:25% Dom:48/29%(#4) MSFS:23/21% Top2Avg:61/57% GPU:66% VRAM:79% 
2026-07-22 11:58:40.995 [DBG] [ ServiceController:DetectPeriodic ] PeriodicDetect medianUs=28057 multiplier=2 floorUs=0 thresholdUs=56114 spikeCount=1 
2026-07-22 11:58:40.995 [DBG] [ ServiceController:DetectPeriodic ] Reject: spikeCount=1 < 4 (need ≥4 spikes for ≥3 intervals) 

What also concerns me is that all, not just some, spike detect log lines for VR have a spikeCount of 1, which is highly improbable.

I shall investigate ...

[ResetXPDR]

Investigation complete. Your RTSS data went stale when you switched to VR and it stayed that way for the rest of your flight. I have added a stale data detector to Test23, which has just been released. I have only seen this once from your logs, so don't worry too much about it.

BTW, Test23 also includes the ability to have extra flight profiles. It will still default to 6, but you can increase it as high as 12, or drop as low as 4 if you want, by changing this line in the common config file in the root directory after running the app at least once:
<add key="ProfileCount" value="6" />

I made this change as I am always running out of profiles testing multiple user's specific configs at any point in time and I end up having to use an existing one that I'd rather not. I have set mine to 10, so now I get:

[jerryyyyy]

One more switching to VR... always start in 2D.

VR Bali MSFS_AutoFPS20260723.log

[ResetXPDR]

One more switching to VR... always start in 2D.

VR Bali MSFS_AutoFPS20260723.log

Well that's a fail on stale data detection with test23. Looks like your RTSS data was frozen for your entire VR flight component of the log ie from:

2026-07-23 12:54:20.411 [DBG] [ ServiceController:DetectPeriodic ] PeriodicDetect medianUs=28440 averageUs=31335 minUs=27777 maxUs=704732 sampleCount=320 multiplier=2 thresholdUs=56880 spikeCount=1 
2026-07-23 12:54:20.411 [DBG] [ ServiceController:DetectPeriodic ] Reject: spikeCount=1 < 4 (need ≥4 spikes for ≥3 intervals)

to:

2026-07-23 14:50:05.038 [DBG] [ ServiceController:DetectPeriodic ] PeriodicDetect medianUs=28440 averageUs=31335 minUs=27777 maxUs=704732 sampleCount=320 multiplier=2 thresholdUs=56880 spikeCount=1
2026-07-23 14:50:05.038 [DBG] [ ServiceController:DetectPeriodic ] Reject: spikeCount=1 < 4 (need ≥4 spikes for ≥3 intervals)

ie. the same result on every log ling for nearly 2 hours! The code I wrote to detect staleness looks at the data end time stamp and flags it as stale if it is the same three times in a row, but it obviously didn't work in your case. I shall investigate further!

[jerryyyyy]

Thought I uploaded this from today with your new version but not there. I did not notice any stuttering but the "count" is 1.

VR C-208 Venezuela MSFS_AutoFPS20260724.log

Been very busy but will take a flight tomorrow and set the DLSS up one more notch as a stress test. I do not think it will improve the visual in VR as am at the limit of the display, but maybe will get you a few stutters.

[jerryyyyy]

Will remove and reinstall tomorrow.

[ResetXPDR]

Don't worry too much about it. I have found that it is very hard, if not impossible sometimes, to trigger periodic spikes in the latest SU6 beta anyway, so it looks like Asobo has nearly fixed it just as I get my detection/protection working. 😆 Oh well, at least I enjoyed the challenge of detecting those spikes in a sea of other data!

[jerryyyyy]

OK, I have uninstalled both programs and rebooted. Latest version 4.6.6 of MSI is supposed to be installed and check the RTSS to install along side. Then check the Frametime in OSD. Done. Will now rerun VR run NUQ/SFO.

I can see the Frametime overlay in 2D but when I run in VR AUTOFP says RT datastale... this is beyond me.

I think most normal people no longer see stutters or spikes. That chart of the DL settings I think is crucial. I can bring my system to its knees in DLAA... the Balanced or Quality settings seems fine for my system.

Test 1 MSFS_AutoFPS20260725.log

[ResetXPDR]

Still stale in VR in this one too. Don't worry about it any more. As you say, the issue has largely gone away so fixing this properly is moot. Thanks for your continued input, as always.

[jerryyyyy]

OK, but I have to say I remain irritated that was not able to solve that issue after reinstall... I had a similar issue with my expensive work laptop (Dell 16" Max Pro). Was slowing and fan going on. 6 months old and $3600! Turned out the power supply was dying... I noticed battery was not charging after days of diagnostics and software reinstalls. University IT no help.

Well all this screen resolution will change for me tomorrow as I have cataract surgery. Hope it works out. I have a problem primarily in my R eye but will get both done.

Keep up the good work. I never really saw much of the stutters.

[snkeyez95]

MSFS_AutoFPS20260727.log

[jerryyyyy]

Back with one eye fixed. Fingers crossed for number 2. Here seems to be your RC3.

Gyro MSFS_AutoFPS20260728.log

[ResetXPDR]

I hope it went well. 0.5.2.0 has been formally released, with only a minor bug fix since RC3 not relevant to your setup. Let's continue the discussion on the new discussion thread here #264