Stuttering Observations

[jase439]

Just a curious observation on the alleged FSUIPC stuttering that many (including myself) observe when receiving weather updates from a 3rd party app. Even with the fix that was provided in 3.08, the stuttering is still fairly aggregious if and only if I the 3rd party app is running concurrently on the *same* system as FS.

If the updates come over the wire via WideFS, however, the wx updates are as smooth as a hot knife through butter.

I wonder if the stuttering has anything to do with FSUIPC at all. Perhaps it has more to do with running FSUIPC-enabled apps locally on the same host as flight simulator can rob the sim of precious CPU resources as those apps work in the background. Or maybe the blocking/signaling of synchronization objects between applications and FSUIPC are more disruptive to the sim simply blocking on a socket. That, or WideFS uses the NWI interfaces "more correctly/efficiently" (when acting as a proxy to these apps) than the apps do themselves. I don't know how these two mechanisms might differ, but it's verifiably clear that apps interfacing through WideFS cause little, if any, disruption to the sim as opposed to those apps who interface through the NWI directly.

Any other WideFS users noticed this?

[Pete Dowson]

the stuttering is still fairly aggregious if and only if I the 3rd party app is running concurrently on the *same* system as FS.

If the updates come over the wire via WideFS, however, the wx updates are as smooth as a hot knife through butter.

It sounds like you need to set the frame rate limiter in FS2004 a bit lower, otherwise it is grabbing all the processor it can, so that when a third party program does get control it has more to catch up on. If FS is forced to relinquish more often because it hits the limiter, then the third party activities will be spread out better.

Or maybe the blocking/signaling of synchronization objects between applications and FSUIPC are more disruptive to the sim simply blocking on a socket.

There are no synchronisation objects between apps and FSUIPC. It's a simple message passing/message processing interface.

That, or WideFS uses the NWI interfaces "more correctly/efficiently" (when acting as a proxy to these apps) than the apps do themselves. I don't know how these two mechanisms might differ

There's no difference -- data arrives at FSUIPC in exactly the same format, whether routed by a Message from another process in the same PC, or from WideServer. they all go through exactly the same code. Of course WideServer isn't switching processes all the time, only threads.

but it's verifiably clear that apps interfacing through WideFS cause little, if any, disruption to the sim as opposed to those apps who interface through the NWI directly.

As far back as I can remember it has ALWAYS been beneficial to FS's smooth performance to move all of the other processes you might want to run off that PC. It really isn't anything at all specific to the NWI, it wouldn't make any difference what the other processes were doing with FS, it is what they are doing with the processor and other scarce resources which matters.

It may seem worse with programs using the NWI rather than any of the older methods of weather control, but that is only because they are doing a lot more. Before the NWI, programs could only set one global set of weather data. With the NWI they can and do set all the nearby weather stations, separately.

Regards,

Pete

[jase439]

Interesting thought. I have the limiter set at 30 - but could easily stand to bring it down to 20.

Thanks for the insightful feedback.\

J

PS. Out of curiosity, what is the IPC mechanism between an app and FSUIPC. Is it socket based, named pipes, or just plugging data into a memory mapped file which FSUIPC periodically polls?

[Pete Dowson]

what is the IPC mechanism between an app and FSUIPC. Is it socket based, named pipes, or just plugging data into a memory mapped file which FSUIPC periodically polls?

It is the method originally designed by Adam Szofran in FS5IPC back in FS95 days. It has been kept all the way through for compatibility. It uses a memory mapped file but it isn't polled, the details are passed by a message. FSUIPC not keep track of applications, the file belongs to the application and if only read/written by FSUIPC.

There don't think there were any named pipe facilities available on Windows 95 (not that it would be very efficient for a many-to-one relationship), and sockets were also primitive and needing User installation, as far as I can recollect.

Memory mapped file methods of transferring data betwen processes in efficient enough. In fact it is basically the same method underlying the way some of the debugging aids work, although there they are wrapped up in high level functions like "ReadProcessMemory".

You can find all the details in the FSUIPC SDK on http://www.schiratti.com/dowson.

Regards,

Pete