Performance Problems

[FranklinJS]

Guys, I am developing a system in C # that you want to act as an ACARS, tracking and flight black box of the VA in which I participate. I'm reading via FSUIPC offsets many of the FS and what could not be offset via, I'm reading through LVARS with LUA. Unfortunately, the performance is catastrophic, I think multitude of memory access, sending data (tracking and flight events) via http protocols, writing local files (log), etc. .. are consuming too many system resources and FS. Could anyone give me a tip on how to improve performance, perhaps using more LUA than the C # (I guess the ideal would be to use C, but do not know)? Increasing the waiting time of the routine reading of changes in state of switches? Log in routine?

[Pete Dowson]

Guys, I am developing a system in C # that you want to act as an ACARS, tracking and flight black box of the VA in which I participate. I'm reading via FSUIPC offsets many of the FS and what could not be offset via I'm reading through LVARS with LUA. Unfortunately, the performance is catastrophic, I think multidação of memory access, sending data (tracking and flight events) via http protocols, writing local files (log), etc. .. are consuming too many system resources and FS.

Are you accumulating all the reads from offsets and doing just one FSUIPC_Process call per cycle? If not you should. If you are using Process for each and every item it will be trying to switch back and forth between the processes furiously. That's the main reason most folks add-ons are inefficient.

Similarly with Lua. If you are reading a lot of stuff every time it changes that could be far too often. Best to use a Timer event and just poll information at intervals.

How frequent is the cycle you are using? An ACARS system should only need a fairly infrequent update, like a second or even several? You should interleave data extraction and file activities to even out the processing load.

Regards

Pete

[FranklinJS]

Are you accumulating all the offsets and reads from doing just one call per FSUIPC_Process cycle? If You Should not.

R: Are two or three different calls in at most parts of the program. That's because frenquência is different, there is a call to the tracking data for heading, altitude, speed etc ... second. And another call to check switches, from 15 to 15 seconds.

If you are using for each Process Every item and it will be Trying to switch back and forth furiously Between the processes. That's the main reason most folks add-ons are inefficient.

Similarly with the lua If you are reading a lot of stuff Every Time That Could be it changes far too often. Best to use the Timer event and just poll information at intervals.

R: In the case of a event.control am using LUA to each switch, all the overhead, panels etc ...

How frequent is the cycle you are using? Should an ACARS system only need to update fairly infrequently, like a second or even Several? YOU SHOULD interleave data extraction and file even to Activities Out The processing load.

R: The frequency would be up for one second track which is sent to the VA Web site, and 15 seconds for other variables in the case of switches monitored tied for the moon in a given time is when the event occurs.

Suggestions?

[Pete Dowson]

R: Are two or three different calls in at most parts of the program. That's because frenquência is different, there is a call to the tracking data for heading, altitude, speed etc ... second. And another call to check switches, from 15 to 15 seconds.

So very few switches for Process calls per second?

R: In the case of a event.control am using LUA to each switch, all the overhead, panels etc ...

Only switches etcetera operated by the pilots? so very infrequent, in fact?

R: The frequency would be up for one second track which is sent to the VA Web site, and 15 seconds for other variables in the case of switches monitored tied for the moon in a given time is when the event occurs.

So, there should be nothing happening most of the time! I'm afraid you'll need to work out what is causing your problems, then, probably by a process of elimination. Try without one thing at a time. From what yoyu say it cannot be anthing to do with the IPC interface or the Lua plug-in. Most of the time they are idle, from what you say.

Regards

Pete

[Luke Kolin]

FWIW I read around 50 offsets several times a second without any sort of performance issues from C#.

Cheers!

Luke

[Pete Dowson]

FWIW I read around 50 offsets several times a second without any sort of performance issues from C#.

Yes, and I have a full suite of Project Magenta and other programs reading many variables many times a second too with no measurable performance effect. I'm sure FranklinJS's problems lie elsewhere, maybe with all this file handling he's talking about.

Regards

Pete

[FranklinJS]

OK, I'll do the tests, I'll probably have to change my approach in the system for better performance. I think the heavier the tracking log that sends every second horizontal and the vertical position of the aircraft.

[Pete Dowson]

OK, I'll do the tests, I'll probably have to change my approach in the system for better performance. I think the heavier the tracking log that sends every second horizontal and the vertical position of the aircraft.

Check the Lua example provided ("record to csv" -- see your FSUIPC Documents subfolder), which makes a csv file recording such things. It sends all this data to a file 20 times per second:

hour, min, sec, hourZ, minZ, gs, tas, ias, lat, lon, alt, pitch, bank, hdgT, mach, vs

That doesn't seem to have any great impact on performance!

Regards

Pete