Practical limit on reads and writes?

[BrunoBL]

Pete,

Sorry if this has been asked before.

I have been playing with FSUIPC and Delphi to do some reads (and a few writes) into FS. From your replies to a number of people here, I understand that FSUIPC won't by itself do much of anything unless asked to do so by some application.

I coded a program in Delphi which runs in another PC and talks to FS via WideFS/FSUIPC. The Reads are within a loop (a Delphi timer) and the writes are done on the fly after pushing a switch or something like that (to avoid unecessary Writes inside the loop). So... is there a practical limit to the number of different offsets I Read or Write before advesely affecting the FS perfrmance? Of course this may depend heavily on processing power, available memory, efficient coding of the guest application, etc, but I wonder if there is a ballpark figure for a limit to this. Are we talking about a dozen offsets? Tens? More?

Also, since my application doesn't care much about precise timing (I am displaying radio frequencies, NAV radials and lighting up external LEDs and lights), I am using a relatively large time interval between loops (500ms). Am I correct to assume that a tighter loop, so to speak, would request more reads and thus contribute to degrading FS performance? I fugure that FS has only 40ms to do everything it has to do between screen refreshes if it is going to run at, say, 25FPS. That is why I chose my timer to run at a (I hope!) conservative 500ms.

Thanks for all your educating replies here.

Best regards,

Bruno.

[Pete Dowson]

is there a practical limit to the number of different offsets I Read or Write before advesely affecting the FS perfrmance?

It isn't really a meaningful question like that. Over a period of 24 hour I excpect you could do millions of reads and writes without impinging on anything. It is the rate at which you call FSUIPC_Process which will be limiting performance.

If you mean the number of reads and writes in one FSUIPC_Process, then the only limit is the total size of the request. Count each separate FSUIPC_Read call as about 16 bytes and each separate Write as 16 bytes plus the data length. The total before the FSUIPC_Process shouldn't be more than that allowed by the interface programming, which is about 30000 bytes or so -- if you are using my Library then it checks this in any case and you will get an error on the first Read or Write which won't fit.

One thing that is bad is doing lots of Process calls when you could combine all the reads and writes and do one Process call -- the reads and writes are local to your process and are merely accumulating data ready for transfer by the process call.

Regards

Pete

[BrunoBL]

Pete,

Good to know for sure that it is not the reads that may affect performance.

One thing that is bad is doing lots of Process calls when you could combine all the reads and writes and do one Process call

I imagined that this could be the case, and was already doing all the reads before calling one FSUIPC_Process after the last one.

It is the rate at which you call FSUIPC_Process which will be limiting performance.

In my program all this actually happens in a loop, so I am calling a FSUIPC_Process once in every cicle. From the above, I assume that if I expect a too frequent refresh rate in my program (now at 500ms), this could in fact degrade FS performance. Due, not to the rate of reads as I had implied before, but rate of FSUIPC_Process. What is left to be determined (by trial and error?) is whether or not 500ms is a reasonable interval for repeated calls to FSUIPC_Process in a loop.

Best regards,

Bruno.

[Pete Dowson]

What is left to be determined (by trial and error?) is whether or not 500ms is a reasonable interval for repeated calls to FSUIPC_Process in a loop.

500 msecs is very slow. I wouldn't worry about that. If that is adequate for your purposes, stick to it.

There are programs looping every 20-50 mSecs which seem to run fine without noticeable impact. If you are running your program on the same PC as FS you are more likely to affect its performance by hogging the processor for your own purposes than by giving it control via FSUIPC_Process.

If you run your program on a Client PC under WideFS, your Process calls aren't actually relayed to FS at all except once for each new location read, though of course all the writes are forwarded. Once WideServer knows you are reading a location it sends it out on every single change. For locations changing on every FS frame (and there are many), that should be the rate the memory in WideClient is updated -- even if you only read it at 2 fps.

Regards,

Pete

[BrunoBL]

Pete,

Yes, I am running my application under WideFS in another PC, to free the PC running FS from other chores.

Once WideServer knows you are reading a location it sends it out on every single change. For locations changing on every FS frame (and there are many), that should be the rate the memory in WideClient is updated -- even if you only read it at 2 fps.

So if I read things like airspeed, altitude, geographic coordinates I should expect a lot of traffic (not only the FS-related FPS issue, but traffic over the network as well), as opposed to things like fuel levels, flap and gear setting, etc, which will probably not change on every frame.

Regards,

Bruno

[Pete Dowson]

So if I read things like airspeed, altitude, geographic coordinates I should expect a lot of traffic (not only the FS-related FPS issue, but traffic over the network as well), as opposed to things like fuel levels, flap and gear setting, etc, which will probably not change on every frame.

Yes, but the frames are short and your network should very easily cope. Take a look sometime at the Project Magenta web site http://www.projectmmagenta.com and the many multi-PC cockpits using WideFS with full instrumentation for, in many cases, pilot and co-pilot -- no instruments on the FS PC at all. My own setup is like that. Also see the Jet Cockpit made by PFC (http://www.flypfc.com) -- that uses 6 PCs linked by WideFs and PM.

Of course it helps if your Network is 100 mbps or more, not the outdated 10 mbps type. And if you have more than 2 PCs, a switch rather than a hub. But such network gear is cheap these days -- even switches can now be had for the same price as a hub.

Regards,

Pete

[BrunoBL]

Take a look sometime at the Project Magenta web site http://www.projectmmagenta.com and the many multi-PC cockpits using WideFS with full instrumentation for, in many cases, pilot and co-pilot -- no instruments on the FS PC at all.

Ultimately, a simulator like one of those is the goal. The PC running FS will be exclusive to it, and to the display of the front view.

I am starting a little shy on all this, given the ambitious and very challenging nature of a project like this one. The multitude of abilities involved (mechanics, electronics, some programming, the integration of all sorts of hardware and software from many different suppliers) suggest that I am in for years of fun. But... will there be time left to fly? :D

Pete, thanks for the wonderful and very educating chat. I trully apreciate it.

Best regards,

Bruno.

[Pete Dowson]

But... will there be time left to fly? :D

Oh, I doubt it. Most sim cockpit enthusiasts spend most of their time tweaking! You get very critical, so each time you start a flight you see something else that, well, may be a little better ifetc. :wink:

Regards,

Pete