WideFS CPU load and RAM problem

[Alexey]

Hi! 

I'm using WideFS with P3D 4.4: the client is installed on a second machine, and there are three programs that using it: force feedback yoke, motorised trim wheel, and a shaker controller (all from bffsimulation.com). Also yoke joystick buttons are connected via WideFS.

When WideFS client connects to the server, its cpu usage is ~3-5% (from 4 cores) and it takes ~10Mb RAM.

Then it starts to increase slowly, but noticeably. After about 15 mins,  CPU load rises to 25% (full single core) and RAM is ~60Mb. I can see yoke movements becoming "coarse" and laggy (they are written to FSUIPC offsets via WideFS). Same for joystick buttons - when I start simulation, P3D reacts almost instant, but after time, it takes couple of seconds to react. Most probably it's the result of 100% CPU core loading on the second machine.

I set WideFS to auto reconnect each minute, and it helps. After reconnection CPU load and RAM back to normal and start increasing again. But there is annoying side effect - after reconnect joystick buttons stops transmitting to server. I don't see reaction to pressing those buttons in FSUIPC settings. This looks like another issue (shutdown and restart of WideFS fixes this till next reconnect). And reconnection unfortunately introduces visible momentary jump in yoke movement, that's not great on final approach, etc. 

Does it look look like anything known?

Tech specs and notes:

• FSUIPC 5.150b and WideFS 7.151 (latest to date), P3D 4.4, Windows 10 x64, Core i5 6600k 16Gb RAM (second PC with WideFS). Local gigabit ethernet. 
• Tried various  WideFS client and server settings, no positive effect to this issue (TCP and UDP, different ApplicationDelay, run as admin, etc.).
• Logs don't show any errors and look generally normal. Adding Log=Yes shows tons of offsets being written and that's all.
• Interesting that WideFS usually stay in processes when I close all clients and close it's window. Takes zero CPU, but memory still allocated. Has to kill it manually.
• My case maybe a little bit specific because WideFS client constantly writes FSUIPC offsets multiple times per second. 
• Behaviour is the same if I only leave a single client application (any).
• Process Explorer shows several threads inside WideFS process and only one thread takes all the core. Others are less that 1%.
• With increase of ApplicationDelay parameter RAM and CPU load increases slowly.
• P3D frames locked at 30 FPS all the time.

Attached config and some short last session logs (with reconnect enabled, so actually not showing the problem). I'll post logs with disabled reconnect within 1-2 days.

FSUIPC5.ini

WideClient.ini

WideClient0.log

WideServer0.log

[Pete Dowson]

1 hour ago, Alexey said:

I'm using WideFS with P3D 4.4: the client is installed on a second machine, and there are three programs that using it: force feedback yoke, motorised trim wheel, and a shaker controller (all from bffsimulation.com). Also yoke joystick buttons are connected via WideFS.

It is really a very bad idea to have flight controls such as yoke connected to your flight simulator via a Network. You need to connect all axes direct to the main PC. This is why WideClient only provides support for buttons and switches.

I've no idea what is causing your need to have WideClient reconnect. Each time it does so there's a big setup delay in any case whilst it re-requests all of the variables it was monitoring for you. And the excessive loading by WideClient on your PC will be caused by Client program request process, nothing else.

The need to forcibly close WideClient at the end indicates some sort of Network software problem.

Pete

 

 

 

[Alexey]

Hi Pete! Thanks for quick response!

Quote

 

It is really a very bad idea to have flight controls such as yoke connected to your flight simulator via a Network. You need to connect all axes direct to the main PC. This is why WideClient only provides support for buttons and switches.

 

Good or bad, this is typical setup for control loading applications. They itself load 1-2 cores for calculations and communications, so I don't want to stress main rendering PC even more.

The lag is under 5-10ms (with UDP), which 100% enough for yoke movements. What is bad here?

Quote

 

I've no idea what is causing your need to have WideClient reconnect. 

 

Obviously it's because something wrong with WideClient... It should not increase its memory footprint continuously, because the number of variables is constant (I think under 10-15 offsets, or event less if I setup only yoke app).

Also, why it stops sending joystick buttons after reconnect? Again doesn't sound like correct behaviour.

Quote

 And the excessive loading by WideClient on your PC will be caused by Client program request process, nothing else.

It's not excessive, it works very good until WideClient reach 100% load of its core.

I believe that under any constant loading and working network stack WideClient should not uncontrollably grow its memory footprint and CPU load.

Do you agree with this statement?

 

[Pete Dowson]

2 hours ago, Alexey said:

The lag is under 5-10ms (with UDP), which 100% enough for yoke movements. What is bad here?

The queuing of the requests. Unless you limit the number of values from the axes to the sim (by imposing a sufficient delta (minimum change), then the messages pile up in WideFS's memory and in the Windows message queue at the server end. I think that's the reason for the symptoms you observe.

2 hours ago, Alexey said:

It should not increase its memory footprint continuously, because the number of variables is constant

That's okay for variables you are reading. For writing each write is a record in memory. The allocation is dynamically increased to match needs,

2 hours ago, Alexey said:

I believe that under any constant loading and working network stack WideClient should not uncontrollably grow its memory footprint and CPU load.

I think it isn't suitable for the purpose you are putting it to. It was not designed for such use. The design and protocol was fixed in FS98 days and was specifically to enable cockpits to be built with indicators and switches located in the cockpit using lesser and smaller computers to reduce the connections to the server. Very early on it was discovered that this did not suit analog inputs used for real time control of flight. 

Since SimConnect was introduced in FSX, back in 2006, there has been no point in changing WideFS's main protocvols and ways of working because SimConnect offers a more direct route into the Sim and with Networking facilities built in. Compared to that, WideFS's route is very cumbersome. FSUIPC uses SimConnect for almost all of its actions.

Pete