delays between aerosoft devices and magenta

[ulisses]

Hello,

here is the situation:

Server running FS2004, WideFS and FSUIPC only.

Client one running PM PFD/ND, PM MCP and Aerosoft MCP software.

The network runs TCP/IP, 100T, switcher/router, winXP in all machines.

Sometimes when I touch a button in aerosoft MCP, it has a huge delay to magenta receive it. Checking the aerosoft software there is no delay, so it is in the traffic between aerosoft software and magenta software.

I think when aerosoft software receives a command, it sends via WideFS to the server and back to the same client for magenta MCP/ND.

After about 15 seconds without getting the aerosoft commands, all commands I changed are updated immediatlly in magenta, like if all commands were stopped at server and sent all at once, after that it works fine for some minutes, then the delay again.

I checked the wideclient.log and no problems. The other client works fine, PM PFD/ND work fine, my only problem is aerosoft to magenta communication.

Any idea ? Any setting in wideclient.ini or wideserver.ini ?

Thanks,

[Pete Dowson]

Sounds very strange, almost impossible in fact. 15 seconds is a VERY long time! Where can the details of all those changes be stored, waiting so long?

Additionally, virtually all the PM-control areas are above offset 4000. For those, WideClient updates its local memory at the same time as sending it off to the Server. It doesn't do this with the lower areas, because reading and writing many FS and FSUIPC values are noy the same.

There is a long-standing lower PM area, 04E0-0536, and certainly, as it currently stands, writes to those do go to the Server first. Maybe this is a problem for the sorts of things these two programs are doing.

Can you just try a test -- move the MCP to another Client, if you have one, if not, then to the Server? If this fixes it, then it is either a problem with the 04E0-0536 locations, or it is some sort of process problem on that client. Let me know. I can then send you a version of WideClient which treats 04E0-0536 like the upper areas.

If moving MCP doesn't fix it, then we'll need to investigate further -- possibly invoke some of the extensive diagnostic logging in WideFS.

I must admit to never having run the Aerosoft program on the same PC as any PM module.

Regards,

Pete

[ulisses]

Hi Pete,

I posted in another delay thread, but I'd like to inform no more delays in aerosoft->magenta communication, your test wideclient.exe looks good in my case, very smooth now....still testing, I keep you informed.

Thanks,

[Pete Dowson]

I posted in another delay thread, but I'd like to inform no more delays in aerosoft->magenta communication, your test wideclient.exe looks good in my case, very smooth now....still testing, I keep you informed.

Okay, thanks. It was a lucky guess, I think. Odd, though, that this potential problem has been there for years with no one complaining. Never mind. I could see what might happen, but I couldn't see it happening at all here. Must be very timing dependent.

I'll probably release an update to WideFS in due course, but I am away for a week soon so I might do it when I get back.

Regards,

Pete

[ulisses]

Pete,

The aerosoft delay is gone, magenta always respond as I touch the buttons, but....(there is always a but):

I'm getting some stutters in PFD, I'm pretty sure it is not related to the change you made, the change helped a lot in communication.

Everytime I start a new flight everything work fine, after sometime flying I start to get stutters (fast pauses) in magenta PFD, if I pause FS, wait some seconds and release it comes back to normal. Sometimes it comes back to normal by itself (after some minutes)

I'll try to move only the aerosoft software to a new client with your new wideclient.ini, but if you have any suggestion please tell me.

Thanks !

[Pete Dowson]

I'm getting some stutters in PFD

I run PFD on a PC with three screens connected to a Parhelia. I have three copies of PFD running in that one PC - PFD/ND1, EICAS, and PFD/ND2. Up until recently it was 'only' an Athlon 700.

With the PFD parameter "UseTimer=Off", as I always ran PFD before, this was a complete flop. Very very slow and jerky. I don't know what they were doing, but they certainly were not co-operating with each other.

When I set "UseTimer=On" in each of the three PFD.INIs, they worked fine, but there were still occasions when one or the other would stutter or even stick for a second or two.

I think that this was due to simple competition for the attention of WideClient. The 4 processes just refused to run smoothly. WideClient was happy enough, but the PFDs battled each other.

When I upgraded my FS PC I had a "spare" P4 motherboard and 2.4GHz P4, so I put those into this PFD machine. This helps enormously and I now see barely a whisper of a stutter. I still have to run with "UseTimer=On" in the two PFD/ND copies, but I've reset the EICAS one to "Off". Don't ask me why these things make a difference.

I'm telling you all this because I think experimentation to find a happy setup is important.

BTW, I've been pressing Enrico to make me a version of PFD which will support all the instruments -- PFD/ND1, EICAS1 or 2 (switchable), and PFD/ND2, all in one window, or maybe separate windows but one process. Since they really all use the same data from WideClient, having a single process and not all that competition should make it perfectly smooth! :wink:

I'll try to move only the aerosoft software to a new client with your new wideclient.ini, but if you have any suggestion please tell me.

I've a feeling that the Aerosoft control program is not such a good program for cooperating with others, or maybe it is vice versa. I actually run it on a PC on its own (well, I also run FliteMap on that, as a moving map connected to the FS PC using GPSout, so it isn't using the Network). Theoretically, the Aerosoft program should run best on the FS PC, but I had no COM ports left on that and the USB-COM port program wouldn't run on Windows XP.

Now that my main FS PC is a P4 3.2GHz, one of those with two virtual processors ("hyper threading") I moved the PM MCP program to that PC, and it runs fine there. I always preferred to have the MCP right in the FS PC because it gets the best response there (naturally) -- the PM MCP acts as the 'clearing house' for many of the PM messages -- but I was never happy with the results on a lesser PC.

Hope this gives you some ideas.

Regards,

Pete

[ulisses]

Great Pete,

Nice experience on your side...I'll try the usertimer again.

And check the MCP in FS computer...

A question, some weeks ago I think I had a good experience adding WaitForNewData=1000 in wideclient.ini, can you tell me how it can help ? Anyway it is off now...

Thanks !

[Pete Dowson]

A question, some weeks ago I think I had a good experience adding WaitForNewData=1000 in wideclient.ini, can you tell me how it can help ?

All that does is tell WideClient not to simply return to the application with whatever data it has in memory (zero) if the offsets are ones which have not yet been read from the Server. It actually makes WideClient loop, not returning for that amount of time (1000 = 1 second, the default is 500 I think) unless the data arrives.

It really only affects the application initially -- with something like PM, all the components are asking for the same things over and over. Once the Server has provided them to the Client once the WaitForNewData won't apply any more -- unless you close and restart the WideClient, or unless you are getting the links reset (which would be logged at both ends as a new connection).

So I really don't think you'd notice any differences unless you were having lots of resets, which is bad bad bad anyway,

Regards,

Pete