FSUIPC performance

[WxRadar]

Hi Pete and all others!

What increases the performance of fsuipc acesses, in special the new weather interface.

I saw a drop in framerates when starting to acess to NWI form a gauge within FS.

Give me just a feel of what is better....

setting up more single processes, for e. reading numer of cloudslayer and the reading only lets say two new cloud structures

or reading nr of cld layers and 24 cloud structures as one ??

whats better ? less processes and higher number of read bytes or more single processes and lower data count?

kind regards

florian

[Pete Dowson]

What increases the performance of fsuipc acesses, in special the new weather interface. I saw a drop in framerates when starting to acess to NWI form a gauge within FS.

Just reading the weather, not setting it? There shouldn't be any noticeable frame rate drop -- you surely aren't reading all the weather every frame or whatever? It isn't going to change very fast. In fact for weather at the aircraft and global weather I think I only update it once a second or so. Reading weather at a Lat/Lon or ICAO is heavier as it makes special calls to FS's WEATHER.DLL each time you ask.

Two questions:

1) You are using the internal module user's access method for FSUIPC, aren't you? i.e. the one with FSUIPC_Open2? If not, change to that. The external application access method is grossly inefficient for gauges and modules and prone to problems.

2) If you are requesting weather at specific ICAO stations or Lat/Lon locations, you need to place the request then wait for the timestamp to change before reading the results. But you should certainly not wait inside your gauge. You need to exit so that FS can continue, then check on each subsequent entry.

whats better ? less processes and higher number of read bytes or more single processes and lower data count?

Less process calls and all the bytes you want. All that data count is doing is copying more bytes into your memory area. It's a very tight copy loop, probably all in the processor's pipeline at once in any case. Each process call is a Message sent through Windows to get into FS's Message queue, for FSUIPC to process, and THEN the copy of bytes into your area. So by splitting it up you are making everything worse.

The only limit on the data transferred is due to the way the count is used in FSUIPC's interface, and some of its buffers. You shouldn't transfer more than about 30000 bytes in one process. Keep it to 16k max in fact, to allow for all the red tape stuff.

Regards,

Pete

[WxRadar]

Hi Pete!

Thanks...

1. yes i only read weather, and i have to read up to 128 stations within 3 seconds

2. of course i use fsuipc_open2

3. my program flow looks like this

Request Station

back to FS

Read Staion and check if ICAO is updated, if not request same station

again

if updated then rewuest next station

back to fs

and so on until all stations of interest are read..

kind regards florian

[Pete Dowson]

1. yes i only read weather, and i have to read up to 128 stations within 3 seconds

Phew! That's a tall order. Since FSUIPC weather access operates at the FS frame rate, you'd need FS to run consistently at at least 43 fps to achieve that! When FSUIPC receives your request is schedules it to be done at the next frame cal from FS.

How often is your gauge being called by FS? Most are surely once per frame in any case, aren't they?

If I were you I'd try to spread it out over many more seconds. Once you have read your 128 stations or whatever, are you then not reading any more? I don't think you need to read the same station very frequently. Weather doesn't change (or shouldn't change) very fast. Once you have your initial batch, updates at just a few stations per second should surely be enough, perhaps so that you get round the whole lot at least once every minute, perhaps 30 seconds?

Regards,

Pete

[WxRadar]

Hi pete!

Okay your calculation is right

Problem is i have to read up 128 different stations...

first i do to reduce the max number of my stations... there is a great posibility here (but makes another part a little complex) I though fsuipc is faster than the more complex part, but surly not

second i do ist try to only read those stations that are new within a certain time period...

At all, where my confusion comes from, is that I thought fsuipc is working another way...but now i understand the problem...

thanks

florian

[Pete Dowson]

At all, where my confusion comes from, is that I thought fsuipc is working another way...but now i understand the problem...

OkayI hope you can work it out.

The problem for FSUIPC in the NWI is simply the sheer amount of data which it needs to be able to map into "offsets". Realistically getting more than one location (ICAO) mapped at one time was not reasonable.

Anyway, each such request needs a specific series of events -- request from application -- calls to WEATHER.DLL to get data -- update of relevant offsets. I had some trouble with the stability of FS if I tried to do the Weather calls "aynchronously" -- i.e. during the Process call rather than on a regular frame rate call from FS. Otherwise I could probably get the responses faster -- almost instantaneously for internal callers. But I would be worried about FS crashing, and I don't think it would help with FS performance -- probably the reverse, as you'd be making more requests in a shorter time.

Regards,

Pete