A320 FMGS beta 30

[Beret]

Hi,

@Beret: Can you check WideFMGS client is connected to the server? (to open it, you have to click the icon which is "hidden" in the tray bar, next to the clock in the task bar).

JL

Hi JH

I have checked WideFMGS on the client. I have some problems with port 1 (8003) and Port 4 (8006). These connect and disconnect often. In the firewall i have configured this ports on both systems.

Regards

[Beret]

Hi,

@Beret: Can you check WideFMGS client is connected to the server? (to open it, you have to click the icon which is "hidden" in the tray bar, next to the clock in the task bar).

JL

Hi JH

I have checked WideFMGS on the client. I have some problems with port 1 (8003) and Port 4 (8006). These connect and disconnect often. In the firewall i have configured this ports on both systems.

Regards

[Beret]

Hi JH

I have checked WideFMGS on the client. I have some problems with port 1 (8003) and Port 4 (8006). These connect and disconnect often. In the firewall i have configured this ports on both systems.

wideFMGS.jpg

Regards

[jeehell]

Hi,

Ok it's what I thought, I'm looking into the disconnection bugs.

JL

[jeehell]

Hi All

an automatic update is available, hopefully solving all those network comm issues.
I'm working on uploading a full install package as well.

http://www.jeehell.org/A320FMGS_B28.2.exe

Cheers,
JL

[AirFan]

Happy New Year to all of you!

Hi JL! I just tried your new b28.2. My first try with any of the b28 versions as I didnt have the time in the last days. I also have some connections problems now which I didnt have before.
Intresting is that I now have to start the client before the main server. Otherwise it does not get any connection and the widefmgs box on the client remains completly white. When connected it pops some fail numbers once in a while and disconnects and connects.
In b27 I was able to start in any order the server and client.
I addition I see some lags wrt throttle lever position. <1 sec. The hardware throttle is connected to main machine. The EWD is on the client.
Have not seen these lags in b27. And the ND on my client became very unstable. It crashes within less than every 5 mins.

And ... really weird... I somehow managed to see the two EPR gauges on the top of the EWD. How did I do that?? Second start of EWD and I see the "old" N1 gauges? Have you touched these? please enlighten me!

Happy new year, JL!!!

Thanks!
Rob

[buentead]

[...] Intresting is that I now have to start the client before the main server. [...]
[...] And the ND on my client became very unstable. It crashes within less than every 5 mins. [...]

Also Happy New Year to all!

I installed version 28.2 from scratch. As reported by AirFan, I also see the same things happening on my machine. In addition, if I stop the WideFMGS on the server, the client WideFMGS may crash (and vice versa) once they are connected.

In addition, my CPFlight FCU dosn't work (digits cannot be changed, but when making changes, I can see new entries in the log). The FCU is connected to the FSX server. I executed the programs as follows:
1. Starting FSX
2. Starting A320 FMGS Starter
-> In the hardware log I can see:

C:Created
C:Get Analog Proc
CPFlight:Port opened
CPFlight:Connected

3. Starting Overhead and MCDU on a client PC
4. Switch on 'Battery' in Overhead
-> Several data are sent to the FCU successfully. But then, I can see the following entries in the log:

[...]
CPFlight:SendOK:X1005
C:Created
C:Get Analog Proc
CPFlight:Unable to open com port
CPFlight:System Error. Code: 5.
Access is denied
CPFlight:CE_WriteFailed
CPFlight:SetupComm function failed
CPFlight:System Error. Code: 6.
The handle is invalid
[...]

The full log is attached.

I changed the port in the configuration file. The CPFlight FCU runs the lates firmware version 1.12. What am I doing wrong? Since it is the very first time I installed the JeeHell FMGS, I'm sure I'm doing something wrong ...

Thanks and Regards
Adrian

[Fritz]

Hello Adrian,

you did nothing wrong. I have the same problem with the CPFlight FCU.

[chris68]

Hello Jeehell,

When comes the functionality to save and restore a situation?
I am also interested to create some faults like rapid decompression. I guess the Ecam drawing are fixed and no needle are able to turn.

Chris

[buentead]

Hi JL
I did some investigation into the TCP/IP communication between WideFMGSServer and WideFMGS. It looks like the WideFMGSServer is not able to process the data received fast enough. Hence, the server sends "ZeroWindow" information. In that case, the client should stop sending any data. But I saw, that the client still sends data with a length of 1 byte. Following the trace out of Wireshark:

Time starts 19.392726
WideFMGSServer:8004 > WideFMGS:49409 ... Win=1536 Len=0
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=16
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=123
WideFMGSServer:8004 > WideFMGS:49409 ... Win=1280 Len=0
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=41
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=1239 -> now server buffer full
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=0 -> server confirms buffer full (Win=0)
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=1 -> client still sends 1 byte
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=0
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=1 -> client still sends 1 byte
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=0
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=41
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=1476
WideFMGSServer:8004 > WideFMGS:49409 ... Win=3584 Len=0 -> now server has 3584 bytes free in buffer
WideFMGSServer:8004 > WideFMGS:49409 ... Win=3584 Len=1476
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=0
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65684 Len=1460
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65684 Len=1460
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65684 Len=664 -> now server buffer will be full again (3584-1460-1460-664 = 0)
WideFMGSServer:8004 > WideFMGS:49409 ... Win=0 Len=943 -> server sends '0' buffer left
WideFMGSServer:8004 > WideFMGS:49409 ... Win=61952 Len=0 -> 0.001 seconds later, server has free buffer
WideFMGS:49409 >WideFMGSServer:8004 ... Win=65700 Len=0
WideFMGSServer:8004 > WideFMGS:49409 ... Win=61952 Len=1312
WideFMGSServer:8004 > WideFMGS:49409 ... Win=61952 Len=1476
WideFMGS:49409 >WideFMGSServer:8004 ... Win=64756 Len=1460 -> client received 2788bytes, but only 944bytes unprocessed in buffer
-> client processes data very fast
Time ends 21.733430, elabsed time 2.34 seconds

I think the server side applications don't process the received buffers fast enough. Furthermore, I think that the client application shouldn't send any data anymore, if server reports 'buffer full'. It may cause the application to crash as the buffer will have unpredictable content. If one is interested in the TCP buffer handling, here is a good link that explains it: TCP ZeroWindow - Wireshark Q&A

I also see that data length are up to 1476 bytes in general. Adding the IP header of 20 bytes, we end up with 1496. If one uses VLAN's, then we have to add additional 4 bytes. In total it is 1500 bytes, which is the maximum Ethernet frame size (unless jumbo frames are available). In Windows 7, the MTU size is set to 1500 bytes (see command netsh interface ipv4 show subinterface). Hence, everything should be fine. But as there are different hardware (Ethernet cards, switches, routers) out there, I usually don't go over 1400 bytes for data - just to be on the save side.

While I was minitoring the traffic for about 15 minutes, I also saw 2 packages with a data size of 5280 bytes and 2351 bytes. This would definitely be too much. In such a situation, the packet needs to be splitted into multiple TCP packets by the OS / hardware. I observed this situation in other set up when I went over the MTU size in my programs. The network performance becomes so bad, that it runs like in slow motion. Please avoid sending packets larger than 1476bytes (or better 1400 bytes).

I hope my thoughts may help to overcome the network performance problem.

Regards
Adrian