SendMessage timeouts

[Luke Kolin]

One challenge I have with my software is that FSUIPC_Process calls will take a variable amount of time, with some significant delays at times. I've instrumented the SendMessageTimeoutA call on my end and while it usually averages around 16-20ms to return, there are significant outliers where it can take up to 2000ms or more. Even on my own machine I'm seeing data like this:

FSUIPC!!SendMessage 71,377x Avg:16.47ms Min/Max=0.03/681.98ms

... which is a max of almost 700ms. This is of course less than ideal because in previous versions the UI would block. I've moved on and made those calls in their own thread, but the FSUIPC interface itself on my end is single threaded.

John/Pete, when I make that SendMessage call to either FSUIPC or the simulator process, if the frame rate remains decent (double-digits, say) what would cause such delays? I assume that FSUIPC is listening for these Windows messages on a per-frame basis, so it should get handled in under 100ms? My users all swear up and down that their frame rates are excellent (and I'd rather not instrument that any more than I have) but are there any cases that you know of where FSUIPC will take an excessive amount of time to respond?

Cheers!

[Pete Dowson]

1 hour ago, Luke Kolin said:

My users all swear up and down that their frame rates are excellent (and I'd rather not instrument that any more than I have) but are there any cases that you know of where FSUIPC will take an excessive amount of time to respond?

There are two possibilities I can think of:

1.  You have made a request via FSUIPC which involves FSUIPC asking FS for something and waiting for the result.  Typical would be reading L:Vars, as an example.

2.  The high (unlimited?) frame rates being allowed in the simulator are precluding sufficient time for other interfacing applications. This would typically be occasional, not constant. Best always to advise users to limit frame rates (either directly by the FR limiter, or via VSync), to something just below the average attained.

Without knowing more about exactly which requests are timing out I can't really help further. You should also state the versions of both FSUIPC and FS/P3D.

Pete

 

[Luke Kolin]

On 8/20/2021 at 10:15 AM, Pete Dowson said:

1.  You have made a request via FSUIPC which involves FSUIPC asking FS for something and waiting for the result.  Typical would be reading L:Vars, as an example.

2.  The high (unlimited?) frame rates being allowed in the simulator are precluding sufficient time for other interfacing applications. This would typically be occasional, not constant. Best always to advise users to limit frame rates (either directly by the FR limiter, or via VSync), to something just below the average attained.

Without knowing more about exactly which requests are timing out I can't really help further. You should also state the versions of both FSUIPC and FS/P3D.

Thanks for that - the good news is that I can replicate it myself so I'll give you what I know. I'm using P3D v4.5 and FSUIPC 6.0.14 on Windows 10.

1) Thanks for the information on LVAR reading. I do read LVARs extensively, but it greatly depends on the detected equipment. Aircraft such as the CS757/767 or the PMDG MD-11 extensively use LVARs for autopilot state so I read them regularly, but I've noticed this issue with the PMDG 737 and 777 which uses offsets (thanks!) and so my LVAR reading is only every five minutes or so to refresh some different state/capabilities variables. (Oddly enough that call rarely blocks for long.)

2) Just so I am clear, if I'm setting the frame rate limiter in the driver (via NV Inspector?) I assume that does the same thing as the internal P3D limiter or vsync? I'm never getting below 15 or so fps, but with the limiter never above 45.

Cheers!

 

[Pete Dowson]

20 hours ago, Luke Kolin said:

2) Just so I am clear, if I'm setting the frame rate limiter in the driver (via NV Inspector?) I assume that does the same thing as the internal P3D limiter or vsync? I'm never getting below 15 or so fps, but with the limiter never above 45.

I don't know about the limiter in NVI. My frame rate 'limiter' is VSync set in P3d. The FR Limit is set to infinity. 

I can get 25fps pretty consistently (mainly by limiting the AI Traffic with a frame-rate controlled lower limit in FSUIPC. So I set both Projectors to 25Hz refresh rate with VS on in P3D.

With a single P3D screen I think the frame rate control in RTSS does well. There you can set a limit using a divisor of the sync rate. Unfortunately it doesn't work properly with more than the one screen.

If you can identify exactly what FSUIPC requests are taking so long then John or I could have a look as see if there is a reason other than lack of processing time.

Pete

 

[Luke Kolin]

Sorry this dragged a bit. Thank you Pete for the information - I'm matching via the driver rather than Vsync but I suspect it's having the same effect on the P3D (it's in the driver rather than the sim, set to infinity here too).

Feedback from the affected user has moved into broader issues which makes me question the sim configuration on his end, but I have a question - is there an enumeration of what offsets are being used by third parties? I'm using the range from 66C0 to 66FF for reading LVARs, but I assume if I'm not the only one playing in that space it may cause issues. I'd prefer to have a 64-byte block of offsets but I'm unsure as to whether I can reserve such a block or at least make it user configurable so that it can be adjusted around a bit based on what other add-ons the user is using.

Is there a listing of what's reserved in the 7300, 7840 and 8600 blocks, are there more these days and can I get 64 bytes for my software?

Cheers! 

[Pete Dowson]

4 hours ago, Luke Kolin said:

I have a question - is there an enumeration of what offsets are being used by third parties?

We have many registered for third parties, yes. But we don't publish those details. It's left to them if they wish to (for example, Project Magenta publish their own lists).

4 hours ago, Luke Kolin said:

I'd prefer to have a 64-byte block of offsets but I'm unsure as to whether I can reserve such a block

If you ask I expect you can be accommodated -- John is in charge of that now. Send him a PM.  If you describe your application it would be best as it may be obviously one which would never clash with some other app which has a range of offsets, so making it more easily granted. Such an example would be SimAvionics v ProSim v Project Magenta -- no one would use any two of those at the same time as they do similar jobs.

There are also a number of areas which have been reserved but were for applications never updated for use with today's sims,  However, some of those we would just be guessing as we've lost contact with the authors.

Pete

 

[John Dowson]

17 hours ago, Luke Kolin said:

I'm using the range from 66C0 to 66FF for reading LVARs, but I assume if I'm not the only one playing in that space it may cause issues.

Yes, this offset area is free for general use and many users use this area for lvars.

12 hours ago, Pete Dowson said:

If you describe your application it would be best as it may be obviously one which would never clash with some other app which has a range of offsets, so making it more easily granted. Such an example would be SimAvionics v ProSim v Project Magenta -- no one would use any two of those at the same time as they do similar jobs.

There are also a number of areas which have been reserved but were for applications never updated for use with today's sims,  However, some of those we would just be guessing as we've lost contact with the authors.

Yes - if you let me know what your software does, I'll let you know an area you can use. I am also planning to update the offset status document with info on that the reserved areas are reserved for, and if they can also be used as 'free user offsets' if the user isn't using the 3rd party app that the area was reserved for.

John