Long(er) frames with FSUIPC

[Kosta]

Hello,

while doing some analysis how and what my FS is doing in the background, I came across the fact that FSUIPC is causing longer frames repeating ever xx ms. In a clean P3D scenario, adding only FSUIPC is causing this, see screenshots. Note that the FSUIPC profile is default (renamed my own). Any ideas what is causing that and can I avoid it somehow?

Without FSUIPC:

With FSUIPC:

 

Best regards,

Srdan

[Pete Dowson]

52 minutes ago, Kosta said:

while doing some analysis how and what my FS is doing in the background, I came across the fact that FSUIPC is causing longer frames repeating ever xx ms. In a clean P3D scenario, adding only FSUIPC is causing this, see screenshots. Note that the FSUIPC profile is default (renamed my own). Any ideas what is causing that and can I avoid it somehow?

What are you using FSUIPC for? What is does depends on what it is asked to do.

What is the frequency of these "longer frames"? (Sorry, I can't read the data on your pictures. Why didn't you simply cut and paste the text?)

FSUIPC is receiving changes to the data is provides to applications every time it changes, and the timing of that is up to whatever changes the data. Obviously things like the time changes every second, so that's one data item per second. When flying many things are changing much more, many at least every frame. FSUIPC asks SimConnect to send data when it has changed by a certain amount, or more (the "delta" in order to cut down -- after all many values aren't needed on every miniscule change. This has been finely tuned over the years to give the best results in terms of both performance and smoothness.

To discover if it is SimConnect supplying data which is worrying you, try enabling SimCcnnect logging and see if the log timings match your occasional longer frames. Take care, a verbose SimConnect log gets very very big!

The only other things done would bt button and joystick axis scanning, but with a default settings file that won't be happening as there will be no assignments.

BTW whenever you submit a question or problem I need to know the VERSION numbers of both FSUIPC and FS!

Pete

 

[Kosta]

Hello Pete,

Using FSUIPC mainly for profiles and joystick calibration - basically having all controller assignments disabled in P3D, and everything going over FSUIPC. Also for VAS display. But those jumps are also present with the default fsuipc.ini file.

The frequency of the long frames is not always the same, but it is about 270 frames, which would at 30fps come to about 9 seconds. 2nd one is at 565(18), 863(28), 1160(39) etc. So I'd say in average would be 10 seconds.

I'll see if I can find something out with the Simconnect log (never did that yet).

Versions: P3D3.4 HF2 (latest) and FSUIPC 4.9.6.0

[Kosta]

Okay, got the log. However no idea where to begin with the analysis. It's only 3mb big, but lots of entries, as expected.

[Pete Dowson]

1 hour ago, Kosta said:

So I'd say in average would be 10 seconds.

Ah, 10 seconds is a good clue. There's nothing requested from SimConnect which is that long an interval.

Try disabling the OOM checking. That asks Windows to supply the free memory and the maximum free block every 10 seconds. You can change that using the "OOMcheckInterval" parameter (it's in seconds), or disable it altogether using "OOMcheck=No".

The only other one is the broadcasts by WindeServer to tell clients it is there. You can turn that off in the [WideServer] options with "AdvertiseService=No". If you don't use WideFS that won't be happening anyway (and your default INI won't have it enabled in any case).

Pete

 

[Kosta]

It was the OOM checking, apparently. Thank you. I guess I'll turn if off, because honestly don't need it... my system is virtually OOM free, as I keep it clean of the ORBX stuff :)

[Pete Dowson]

35 minutes ago, Kosta said:

It was the OOM checking, apparently. Thank you. I guess I'll turn if off, because honestly don't need it... my system is virtually OOM free, as I keep it clean of the ORBX stuff :)

I think when you ask Windows for such information, it has to go into a loop adding up the memory for each individual block, and also remembering the largest. If may even concatenate adjacent free ones at the same time, but I'm not sure about that.

I might consider putting the OOMcheck facility into a separate thread. I'm not sure that will help, though, because I suspect Windows has to freeze memory allocation (and freeing) while it counts up, and that probably freezes the whole process.

Pete

 

[Kosta]

So in case of Process Explorer, this information is queried way more often, most likely every second, as far as the refresh goes? The art of query stays the same?

Srdan

[Pete Dowson]

29 minutes ago, Kosta said:

So in case of Process Explorer, this information is queried way more often, most likely every second, as far as the refresh goes? The art of query stays the same?

Er, sorry. I don't really understand what you are asking. 

Pete

 

[Kosta]

I just meant, the query that FSUIPC sends to windows, to check the VAS, is probably the same what Process Explorer is using to query the Virtual Size.

Because if that's the case, by theory, open PE should also cause the said longer frames, do you think?

I ask, becasue it doesn't. Running PE, refresh 2 seconds, no regular (or high) spikes (longer frames).

[Pete Dowson]

3 minutes ago, Kosta said:

open PE should also cause the said longer frames, do you think?

I don't know. Certainly if PE has to freeze the process to do it. Though perhaps if it does it every second there's less change and therefore less totting up to do. I really don't know how it works internally. 

Are you measuring longer frames every second with PE doing the monitoring? If not then try setting the OOMcheckInterval in FSUIPC to 1 (though I'm not sure I let it be set lower than 10).

If doing the OOMcheck in a separate thread would help, I could do that relatively easily. 

Off now till tomorrow -- visiting eldest's family.

Pete

 

[Kosta]

So, I did a test: set Process Explorer to refresh every 10 seconds. And still, no sign of anything in FS (FRAFS). Neither 1sec, 5sec or 10sec.

I didn't try changing anything in FSUIPC.

If you can try to move OOMCheck to another thread, maybe that solves the problem in the root. That would probably be the best solution. If it works...

Have a nice day!

Srdan

[jannier]

I am so glad Srdan "Kosta" narrowed down this issue.

I have Intel 6850K @ 4.4GHz water cooled, 16GB DDR4 @ 2666MHz, with a NVidia GTX 1080 water cooled, Windows 10 1607, Samsung 950 Pro NVMe SSD for OS, Samsung 840 Pro SSD for Flight Simulator, and OCZ Vertex 4 SSD for all Flight Simulator Add-on's.

Having installed only P3D 3.4.18 and fsuipc, I use fsuipc only to assign and calibrate my Yoke and rudder axis's and assign buttons and key strokes. (All axis and button shortcuts in P3D deleted)
I am using a BenQ XL2420G monitor, it is equipped with a G-Sync module by default, so this eliminates every and all types of stutters, you only get butter smooth gaming.

So I was noticing always this very annoying micro stutter/freeze/ripples that was very visible on the G-Sync monitor because everything was always smooth, but at this every 9-10 seconds came this micro ripple/stutter effect over the screen.

After a long test process of elimination I narrowed it down to if I disabled fsuipc from running then all was perfectly smooth again.
So I knew for a while now of this issue but I have never had the technical know how to test it like Srdan "Kosta" did in this thread.

I now set the entry OOMCheck=No and low and behold, everything is back to butter smooth flying as if fsuipc was disabled.

Just a huge thank you to Srdan and Pete for discovering the culprit.

Cheers,
Jannie

[Pete Dowson]

On 1/29/2017 at 7:22 PM, Kosta said:

If you can try to move OOMCheck to another thread, maybe that solves the problem in the root. That would probably be the best solution. If it works...

Email me on petedowson@btconnect.com and I'll reply with a test version attached with exactly that change. Please let me know ASAP please.

Pete