FSUIPC Data Stutter when Sim-A server starts

[chanakaf]

Hello All 

I am posting in this forum as well hoping to get some answers. My other post is at FDS:

https://www.flightdecksolutions.com/forum/viewtopic.php?t=6409&highlight=&sid=65df70190fc6673419c15180ca1cd06f

I have a pretty basic 2 PC setup. One running the FS and the other running Sim-A. Both PC's with high spec CPU and 32GB memory, 2X NVIDIA 1080 in each system. 

I have a LUA script running on the Sim-A PC that send 4 pieces of data to a serial port to run my TQ auto throttle. 

dev = com.open("COM4", 115200, 0) 

function TrefM(offset, value) 
   command = ",T1:" .. string.format("%02d", value) .. "," 
      com.write(dev, command) 
   ipc.sleep(50) 
end 

function Tpos1(offset, value) 
    command = ",T2:" .. string.format("%05d", value) .. "," 
    com.write(dev, command) 
    ipc.sleep(50) 
end 

function Tpos2(offset, value) 
    command = ",T3:" .. string.format("%05d", value) .. "," 
    com.write(dev, command) 
    ipc.sleep(50) 
end 

function TposA(offset, value) 
    command = ",T4:" .. string.format("%05d", value) .. "," 
    com.write(dev, command) 
    ipc.sleep(50) 
end 

function TposB(offset, value) 
    command = ",T5:" .. string.format("%05d", value) .. "," 
    com.write(dev, command) 
    ipc.sleep(50) 
end 

event.offset(0x53E4, "UB", "TrefM") --THRUST_REF_MODE 
event.offset(0x53E0, "UW", "Tpos1") --COMMANDED_THROTTLE_L_POSITION 
event.offset(0x53E2, "UW", "Tpos2") --COMMANDED_THROTTLE_R_POSITION 
event.offset(0x3330, "UW", "TposA") --THROTTLE_LEVER_L_POSITION 
event.offset(0x3332, "UW", "TposB") --THROTTLE_LEVER_R_POSITION 

The script works well and I get data for offset 53E4, 53E0, 53E2, 3330 and 3332. 

Here is the issue; 

When I have P3D running on the FS PC and wide client running on the Sim-A PC the data being written to the com port is very stable and consistent, its a steady stream of data. I only get data for 3330 and 3332 as Sim-A has not started yet. 

Now as soon as I start Sim-A server, the data stream stutters, with significant lags, sometimes 3/4 second delays, and the data stream is not consistent. I have tried to limit the data output to 3330 and 3332 as well in this scenario and sill the same stuttered data flow. 

Below is the log file from Sim-A server 

28/05/2018 17:26:24 : Server Version : 1.80 
28/05/2018 17:26:24 : Network Detected 
28/05/2018 17:26:25 : Initializing 
28/05/2018 17:26:29 : Ready 
28/05/2018 17:26:29 : Registered to: Anthony Fernando : D666-07345 
28/05/2018 17:26:29 : ( Types: B777  )  - SSTD PLUS MODE - PRIVATE LICENCE 
28/05/2018 17:26:29 : Magvar Original Date : 1993 
28/05/2018 17:26:29 : Magvar Date : 2017 
28/05/2018 17:26:29 : Webserver Started 
28/05/2018 17:26:29 : FSUIPC Inputs : ENABLED 
28/05/2018 17:26:29 : FSUIPC Outputs : ENABLED 
28/05/2018 17:26:29 : Flight Sim Detected 
28/05/2018 17:26:30 : FSUIPC Read/Write Check OK 
28/05/2018 17:26:30 : [FSUIPC_INPUTS] Items Read = 429 
28/05/2018 17:26:30 : [FSUIPC_INPUTS] Items Loaded = 6 
28/05/2018 17:26:30 : [FSUIPC_OUTPUTS] Items Read = 771 
28/05/2018 17:26:30 : [FSUIPC_OUTPUTS] Items Loaded = 3 
28/05/2018 17:26:30 : FSX/P3D Mode 
28/05/2018 17:26:31 : Flt Data Loop = 50 ms  Data Send Rate = 0  A/P Rate = 1 
28/05/2018 17:26:32 : Processing Started 
28/05/2018 17:26:32 : FSUIPC I/O Inhibit 
28/05/2018 17:26:35 : FSUIPC I/O Activated 
28/05/2018 17:26:35 : Initializing 
28/05/2018 17:26:39 : Ready 
28/05/2018 17:26:39 : Flt Data Loop = 50 ms  Data Send Rate = 2  A/P Rate = 1 
28/05/2018 17:26:44 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 10 
28/05/2018 17:26:49 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 11 
28/05/2018 17:26:54 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 10 
28/05/2018 17:26:59 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 11 
28/05/2018 17:27:04 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 10 
28/05/2018 17:27:09 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 10 
28/05/2018 17:27:14 : Flt Data Loop = 50 ms  Data Send Rate = 15  A/P Rate = 11 
28/05/2018 17:27:19 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 10 
28/05/2018 17:27:24 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 11 
28/05/2018 17:27:29 : T/O CONFIG : Flaps 
28/05/2018 17:27:29 : T/O CONFIG : ParkingBrake 
28/05/2018 17:27:29 : T/O CONFIG : Doors 
28/05/2018 17:27:29 : Flt Data Loop = 50 ms  Data Send Rate = 8  A/P Rate = 5 
28/05/2018 17:27:34 : Flt Data Loop = 50 ms  Data Send Rate = 5  A/P Rate = 4 
28/05/2018 17:27:39 : Flt Data Loop = 50 ms  Data Send Rate = 15  A/P Rate = 10 
28/05/2018 17:27:44 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 11 
28/05/2018 17:27:52 : Flt Data Loop = 50 ms  Data Send Rate = 3  A/P Rate = 3 
28/05/2018 17:27:57 : Flt Data Loop = 50 ms  Data Send Rate = 15  A/P Rate = 11 
28/05/2018 17:28:00 : T/O CONFIG : Flaps 
28/05/2018 17:28:00 : T/O CONFIG : ParkingBrake 
28/05/2018 17:28:00 : T/O CONFIG : Doors 
28/05/2018 17:28:04 : Flt Data Loop = 50 ms  Data Send Rate = 4  A/P Rate = 3 
28/05/2018 17:28:09 : Flt Data Loop = 50 ms  Data Send Rate = 3  A/P Rate = 2 
28/05/2018 17:28:09 : T/O CONFIG : Flaps 
28/05/2018 17:28:09 : T/O CONFIG : ParkingBrake 
28/05/2018 17:28:09 : T/O CONFIG : Doors 
28/05/2018 17:28:14 : Flt Data Loop = 50 ms  Data Send Rate = 15  A/P Rate = 10 
28/05/2018 17:28:19 : Flt Data Loop = 50 ms  Data Send Rate = 10  A/P Rate = 7 
28/05/2018 17:28:24 : Flt Data Loop = 50 ms  Data Send Rate = 10  A/P Rate = 7 
28/05/2018 17:28:29 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 10 
28/05/2018 17:28:35 : Flt Data Loop = 50 ms  Data Send Rate = 11  A/P Rate = 8 
28/05/2018 17:28:37 : T/O CONFIG : Flaps 
28/05/2018 17:28:37 : T/O CONFIG : ParkingBrake 
28/05/2018 17:28:37 : T/O CONFIG : Doors 
28/05/2018 17:28:41 : Flt Data Loop = 50 ms  Data Send Rate = 3  A/P Rate = 2 
28/05/2018 17:28:46 : Flt Data Loop = 50 ms  Data Send Rate = 9  A/P Rate = 6 
28/05/2018 17:28:51 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 10 
28/05/2018 17:28:59 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 10 
28/05/2018 17:29:04 : Flt Data Loop = 50 ms  Data Send Rate = 8  A/P Rate = 5 
28/05/2018 17:29:09 : Flt Data Loop = 50 ms  Data Send Rate = 15  A/P Rate = 11 
28/05/2018 17:29:14 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 11 
28/05/2018 17:29:19 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 11 
28/05/2018 17:29:24 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 11 
28/05/2018 17:29:29 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 11 
28/05/2018 17:29:37 : T/O CONFIG : Flaps 
28/05/2018 17:29:37 : T/O CONFIG : ParkingBrake 
28/05/2018 17:29:37 : T/O CONFIG : Doors 
28/05/2018 17:29:37 : Flt Data Loop = 50 ms  Data Send Rate = 8  A/P Rate = 6 
28/05/2018 17:29:42 : Flt Data Loop = 50 ms  Data Send Rate = 15  A/P Rate = 10 
28/05/2018 17:29:50 : Flt Data Loop = 50 ms  Data Send Rate = 3  A/P Rate = 2 
28/05/2018 17:29:56 : T/O CONFIG : Flaps 
28/05/2018 17:29:56 : T/O CONFIG : ParkingBrake 
28/05/2018 17:29:56 : T/O CONFIG : Doors 
28/05/2018 17:29:56 : Flt Data Loop = 50 ms  Data Send Rate = 10  A/P Rate = 8 
28/05/2018 17:30:01 : Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 10 
28/05/2018 17:30:05 : >>> State Backup To File <<< 
28/05/2018 17:30:05 : Webserver Stopped 

Here is the WideFS log file; 

********* WideClient Log [version 7.146] Class=FS98MAIN ********* 
Date (dmy): 28/05/18, Time 17:25:26.123: Client name is DESKTOP-G2JJHBR 
       94 LUA: "C:\Sim-Avionics\WideFS\Initial.LUA": not found 
      109 Attempting to connect now 
      109 Trying to locate server: Need details from Server Broadcast 
      109 Failed to connect: waiting to try again 
     1109 Attempting to connect now 
     2109 Server = TOPGUN 
     2109 Trying TCP/IP host "TOPGUN" port 8002 ... 
     2109 ... Okay, IP Address = 10.0.1.10 
     2125 Connection made okay! 
     2891 FS closing down (param=ABCD), disconnecting 

     2891 ********* Interim performance summary ********* 
     2891 Total time connected so far = 0 seconds 
     2891 Reception maximum so far:  0 frames/sec, 0 bytes/sec 
     2891 Reception average whilst connected so far:  22 frames/sec, 2581 bytes/sec 
     2891 Transmission maximum so far:  0 frames/sec, 0 bytes/sec 
     2891 Transmission average whilst connected so far:  3 frames/sec, 1306 bytes/sec 
     2891 Max receive buffer = 670, Max send depth = 1, Send frames lost = 0 
     2891 *********************************************** 
     2891 Received shutdown offset code = ABCD 
    12453 Connection closed by server! 

Not sure why the initial connection takes a few attempts to connect as I have provided the IP address in the WideFS.ini file. Is there something more I should be doing between UDP and TCP? 

Any ideas on what might be going on? 

Is there a timing issue? 
should I do some sort of CPU affinity to run the LUA script separate from Sim-A? 

Thank you! 
Anthony

[Pete Dowson]

9 hours ago, chanakaf said:

The script works well and I get data for offset 53E4, 53E0, 53E2, 3330 and 3332

...

Now as soon as I start Sim-A server, the data stream stutters, with significant lags, sometimes 3/4 second delays, and the data stream is not consistent. I have tried to limit the data output to 3330 and 3332 as well in this scenario and sill the same stuttered data flow. 

Why the 50 mS delays? What if one of the other events occurs? It could cause them to pile up. And shouldn't yu be checking that the vaue being sent has changed sufficiently to bother with? You could probably save a lot of queued COM port traffic be filtering the data.

9 hours ago, chanakaf said:

Not sure why the initial connection takes a few attempts to connect as I have provided the IP address in the WideFS.ini file

According to the log, good connection was established in 2 seconds of starting WideClient. Not sure how much better you'd expect ?  I think there are timings you can adjust if you really want, but they were optimised long ago. WideServer won't be able to secure 100% of the Sim processing time.

Than you closed down 870 mSecs later!!!

9 hours ago, chanakaf said:

2125 Connection made okay! 
2891 FS closing down (param=ABCD), disconnecting

For COM port problems i'd check using a COM port monitor program. 

Oddly you didn't supply the WideServer.log, which would seem more significant?

Pete

 

[chanakaf]

Thanks Pete.

I have tried with the 50ms delay and also taking it out. The problem persists either way.

The Event function only triggers if the value has changed, so I don't check for that within my code. 

I am fine with the time it takes for the wide client to connect, I brought this up since I saw it was trying and tried an alternate, just wanted to explore if there were any hints for the overall serial data delay. not an issue with the connection time at all.

I am using a COM port monitoring tool and my observations are based on that.

I will send you new log files for WideServer.log and the full Wideclient.log later today when I get back home.

 

 

[Pete Dowson]

1 hour ago, chanakaf said:

The Event function only triggers if the value has changed, so I don't check for that within my code. 

No, but many very small changes aren't needed. I'm talking about a check that the value has changed enough to be worth bothering with. FSUIPC does this, for instance, with all assigned axes -- the "DELTA" value, which can be changed, determines the smallest change that will be handled. The values you are looking at for throyttle can be anthing from 0 to 16383 (or negative for reverse), but I'm sure you don't need 16,384 different positions for the feedback. Typically this is reduced by a factor of 256 even before it is noticed, and that's still 64 positions.

However, the 3330 and 3332 values are "post calibration", so IF you are assigning in FSUIPC, the DELTA should have already been applied. Yet you say:

13 hours ago, chanakaf said:

I have tried to limit the data output to 3330 and 3332 as well in this scenario and sill the same stuttered data flow. 

By which I assume you meant that you remove the other events for a test. Is that so? If not that remains rather a puzzle.

1 hour ago, chanakaf said:

I am using a COM port monitoring tool and my observations are based on that.

You mean not on what is happening regarding your device, but just on a monitoring reslut?

And what does the Monitor show? Is the reception piling up, or the tranmission spasmodic? I don't understand the Sim-A log -- it has lots of lines like

Flt Data Loop = 50 ms  Data Send Rate = 16  A/P Rate = 10 

but nothing about Reception? If that rate is related to reception, then a value ranging to to 16 seems reasonable since it cannot achieve more than 20 for all values put together, because of the 50 mS delays.

What frame rate is WideClient getting, and what is the average on the Sim?

I'm beginning to think i don't understand your problem at all. What are you thinking is wrong. what actually goes wrong from a user perspective?

Pete

 

 

[chanakaf]

Hi Pete,

I have attached the full log files from a short test I just did. I ran the system for about 1 minute without the Sim-A serve running and then started the Sim-A server and ran the system for another minute or two. Same issue as before, as soon as I start the Sim-A server. This test was run without the 50ms delay in the LUA code.

To answer your questions;

I have all the axis assigned via FSUIPC in P3D. Yes you are correct as a test I removed all the other variables and just tested with 3330 and 3332 so that I can make sure that the problem was not caused by the data coming via Sim-A.

My COM port monitoring tool is showing that the data coming into the buffer is erratic, whatever comes in goes out smoothly and no data is piling up. I will try to do more analysis on this with another more sophisticated tool as the one I have not has limitations to be able to get exact time-stamped data. 

the average framerate on the FS was around 30.

The problem is that the data flow into the COM port is not smooth as soon as I start SIM-A. weather its is the full range of 16383 or just a simple switch toggle.

It seems that as soon as SIm-A starts there is some sort of internal conflict that is fighting for priority.

Thank you for looking into this further.

Anthony

 

Comtest.log

FSUIPC5.log

Server.log

WideClient.log

WideServer.log

Edited May 30, 2018 by chanakaf

[Pete Dowson]

You haven't yet really described what is wrong from a user perspective -- i.e. what are the symptoms you actually experience as a result of the COM queing?

I think that if things aren't actually going wrong, but something is a bit stuttery, then it must be a performance problem. Things are clashing somewhere, and as far as I can see from all this data, it is probably in the Windows subsystems for comms and networking, both maybe running in the one processor core.

The Wideclient log shows a very high demand rate imposed by "Server":

   279000 ****** End of session performance summary ******
   279000 Total time connected = 261 seconds
   279000 Reception maximum:  31 frames/sec, 5868 bytes/sec
   279000 Reception average whilst connected:  27 frames/sec, 2971 bytes/sec
   279000 Transmission maximum:  59 frames/sec, 3853 bytes/sec
   279000 Transmission average whilst connected:  16 frames/sec, 1144 bytes/sec
   279000 Max receive buffer = 1004, Max send depth = 30, Send frames lost = 0

   279000 **************** Individual client application activity ****************
   279000 Client 9008 requests: 7049 (Ave 27/sec), Data: 4385539 bytes (16802/sec), Average 622 bytes/Process

What is it sending so frequently? The Send Depth should never build up so much. Normally it would be 1 or 2. It implied WideClient is not getting enough time -- "Server" is monopolising things. Can that be tamed somewhat?

I have 8 WideClient connections in my cockpit system, and FSUIPC/WideServer can cope well with a heavy demand whilst also running about 9 Lua plug-ins. There are some COM port involvements too.

However: I see you are using TCP. Why? Is the order of packets important? Is it important not to miss any? Are you likely to get bad reliability on your Network?  The only things I use TCP for are my CDUs (to ensure requests/settings are in order and never lost). For everything else UDP is fine. You don't normally want all the red-tape stuff, the checking and enveloping that TCP does, especially for things which are changing all the time in any case -- i.e. if one of the 29 packets per second is lost, it doesn't matter because abother one follows in 1/29th of a second.

I think with UDP the load on WideServer will be a lot less and more processing core time will be available for the COMs stuff (both the Network and the COMs are being handled by Windows functions, not directly in any FSUIPC code). Also make sure your Lua plug-in is using an affinity mask to take it off the cores most in use by the Sim (LuaAffinityMask parameter in FSUIPC INI's  [General] section). 

WideServer and the COMs functions in FUIPC are also using separate threads for reads and writes, and you can separate those using the ThreadAffinityMask parameter.

Check core loading using Windows Task Manager. See which cores are most used. Do NOT use an affinity mask in P3D, judst check which cores are most heavily used and avoid them for other things.

Pete

[chanakaf]

Thanks Pete.

I will change wide client setting to UDP and try this evening, I don't have special requirements to run TCP as you suggested.

I believe you are correct that this might be a windows subsystem issue and I am happy to make changes and try this.

Could you please give me some guidance on setting Affinity? I know what it is but have no prior knowledge doing this.

The FS system has an i7-5820K 6-core, HT enabled, OC'd to 4.5 (P3D and FSUIPC running on this system)

The Sim-A system has an i7-4790K 4-core, HT enabled, no OC (Sim-A, Wide Client, LUA Script, running on this system)

P3D, Sim-A all running default settings and I have not set Affinity on any platform.

Thank You!

Anthony

[Pete Dowson]

1 hour ago, chanakaf said:

Could you please give me some guidance on setting Affinity? I know what it is but have no prior knowledge doing this.

The FS system has an i7-5820K 6-core, HT enabled, OC'd to 4.5 (P3D and FSUIPC running on this system)

The Sim-A system has an i7-4790K 4-core, HT enabled, no OC (Sim-A, Wide Client, LUA Script, running on this system)

P3D, Sim-A all running default settings and I have not set Affinity on any platform.

There are threads on other forums (eg AVSIM) which explain all this better than I could (I am no teacher!).But here goes.

6-core with HT means Affinity Masks (AM) have 12 bits, one for each core, so:

1 1 1 1 1 1 1 1 1 1 1 1

That's P3D's default AM -- all cores enabled. And that's fine. FSUIPC cannot assign codes not already assigned to the process (P3D). The top bit (first 1 there) will be core 11 and the last bit core 0.

Note that with HT enabled (which I don't), every other bit represents a pseuo-core, not a real one.  I don't know how much the competition between the two 'cores' in a pair causes degraded performance, but possibly Intel have got that sorted. I don't take the chance -- and with HT off, the system doesn't get so hot and can be overclocked more with the same cooler.

P3D4 will probably be using Core 0 at near 100% ( it seems locked at 100% here!). It will be using others as well, but you'll need to use Task Manager's Performance display to see which. The display can be set to stay "on top" so you can use it with P3D Full Screen.

Let's assume it uses Codes 0, 6 and 8 most (all real cores). Removing those bits from the 12 shows us which are available for us to use for other things: Thus:

1 1 1 0 1 0 1 1 1 1 1 0

So just choose a selection of these bits, and prefereable a different selection, for each AM you need to assign. I'd tend to avoid the pseudo cores too, leaving just:

0 1 0 0 0 0 0 1 0 1 0 0

i.e 3 real cores to play with. But that might not be enough so by all means use the pseudo ones too if you like.

To convert those bit lists to values to be used in a parameter, divide them into 4's:

e.g. 1 1 1 0   1 0 1 1   1 1 1 0

Then convert each group of 4 into its hexadecimal value.

1110 = 14 decimal = E in hex, and 1011= 11 decimal, or B in hex. So an AM assignment for that value in FSUIPC would be xEBE.  (See the thread entitled "About bits, numbers and hexadecimal" in the FAQ subforum).

For AM's in other program's setting you would probably need the decimal, which isn't so easy. xEBE in decimal is

( 14 x 256) + (11 x 16) + 14, or 3774.

Pete

 

 

[chanakaf]

Thanks Pete. I will give this a try this evening and report back.

[chanakaf]

Hi Pete,

Did quite a bit of testing/investigation but still no improvement.

to answer your question

19 hours ago, Pete Dowson said:

You haven't yet really described what is wrong from a user perspective

I looking to get a steady stream of data from the LUA script so that I can drive my motorized TQ smoothly. I am unable to do this when I have Sim-A running. The TQ works great when I run P3D + PMDG aircraft.

this is what I did to further trouble shoot.

1. I changed to UDP, I added ProtocolPreferred=UDP in the FSUIPC.ini file, no improvement after this change.

2. I disabled HT on both systems

3. Then I changed the AM on the FS system in FSUIPC.ini ThreadAffinityMask=x6 and LuaAffinityMask=x1, still didn't see an improvement. P3D used 100% of core-0 and 50%+ of Core-1 and 2.

4. I ran the following tests and attached the WideClient log files for each scenario:

- Only WideClient connect in ide state (Max Send Depth = 1)

- WideClient connect with the LUA code running and Serial data flowing activating my TQ  (Max Send Depth = 2)

- WideClient connected, No LUA, thus no Serial Data, and Sim-A server running  (Max Send Depth = 7)

- WideServer connected. LUA code running with serial data flow and Sim-A server running  (Max Send Depth = 22)

There seem to be some sort of conflict between my LUA script and Sim-A

 

I am not sure what else I can do to investigate this issue.

 

WideClient - ide state.log

WideClient - with LUA code running and serial data flow.log

WideClient - Sim-A running NO LUA code running.log

WideClient - with lua code + Sim-A server running.log

WideServer.log

[Pete Dowson]

3 hours ago, chanakaf said:

1. I changed to UDP, I added ProtocolPreferred=UDP in the FSUIPC.ini file

That won't override a Protocol=TCP specification in the WideClient.INI file,, but it looks like you didn't add the Server details and Protocol at the Client, so that's okay for automatic connection.

3 hours ago, chanakaf said:

Then I changed the AM on the FS system in FSUIPC.ini ThreadAffinityMask=x6 and LuaAffinityMask=x1, still didn't see an improvement. P3D used 100% of core-0 and 50%+ of Core-1 and 2.

LuaAffinityMask=x1 doesn't affect your Lua does it, as you are running that on the Client, aren't you? And why choose Core 0 which is your 100% P3D core?

If P3D is using 50% or cores 1 and 2, why have you set ThreadAffinityMask=x6, which is choosing codes 1 and 2 also? Don't you have 6 cores? What is wrong with using Cores 3, 4, and 5 for the FSUIPC-set affinities?

Did you not understand and of my explanation of Afflnity Masks above?

Early on you asked "should I do some sort of CPU affinity to run the LUA script separate from Sim-A? ". On the Client PC you can only do that by setting the affinity for Sim-A and for WideClient, either using Winddows facilities or one of the programs available to run things with different AMs.  Sorry, I don't remember their names. But a simple google search reveals stuff like that shown below.

 

3 hours ago, chanakaf said:

There seem to be some sort of conflict between my LUA script and Sim-A

Since they are both on the same PC, I can only think that your Sim-A program is preventing the Lua plug-in running smoothly. Did you try giving it less COM work to do by filtering the values being sent to the COM port to only those which make any difference? I did suggest that way back.

Otherwise I think it is time to investigate that Sim-A program, whatever it is. Or write a program running in its own right to do the job you are expecting a lowly script running inside WideClient to perform?

Pete

 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

How To: Launch Program with Affinity Automatically Set - YouTube

▶ 3:19

https://www.youtube.com/watch?v=ht4bV8IuWcM

1.  

26 Feb 2011 - Uploaded by Jimma Wetcha

A new and more comprehensive video is being planned which shall include better support for CPUs with more ...

 

How To Set Processor Affinity in Microsoft Windows 10 Tutorial ...

▶ 3:26

https://www.youtube.com/watch?v=37flYSGOlaA

1.  

24 Aug 2015 - Uploaded by The Teacher

Processor Affinity was first introduced in Windows 7. The modern multi-core processors are designed to ...

 

Set core affinity permanently - Overclock.net - An Overclocking ...

www.overclock.net/forum/132-windows/1019630-set-core-affinity-permanently.html

1.  

18 May 2011 - 9 posts - ‎6 authors

As the title says, I would like to set the core affinity of a game (GTA San ... C:\Windows\System32\cmd.exe /C START /affinity 1 "C:\Program Files ...

 

Pro Tip: Assign specific processor cores for certain apps in Windows ...

https://www.windowscentral.com/assign-specific-processor-cores-apps-windows-10

1.  

12 Aug 2015 - Set your processor cores for specific apps to make things more efficient! ... application, such as some graphics-rendering software." ... Do you have specific instances where setting coreaffinity for specific apps is beneficial?

 

 

 

 

 

[Pete Dowson]

One thing I realise I don't understand. This "Sim-A" and Throttle Quadrant -- the the one the driver for the other? How are the throttle quadrant values getting to the Simulator? 

Have you tried enabling Axis Logging in FSUIPC to see how frequently throttle values are arriving? Why not connect the Quadrant to the Sim PC?

Pete

 

[chanakaf]

Thanks Pete,

11 hours ago, Pete Dowson said:

LuaAffinityMask=x1 doesn't affect your Lua does it, as you are running that on the Client, aren't you? And why choose Core 0 which is your 100% P3D core?

If P3D is using 50% or cores 1 and 2, why have you set ThreadAffinityMask=x6, which is choosing codes 1 and 2 also? Don't you have 6 cores? What is wrong with using Cores 3, 4, and 5 for the FSUIPC-set affinities?

Did you not understand and of my explanation of Afflnity Masks above?

2

I obviously I didn't fully understand, I think i didn't reverse the order of the binary. So to use Core 3 and 4  I will set AM to ThreadAffinityMask=x18 (011000) correct? or to use cores 3, 4 and 5 AM should be ThreadAffinityMask=x38 (111000). did I get this right?

 

11 hours ago, Pete Dowson said:

Since they are both on the same PC, I can only think that your Sim-A program is preventing the Lua plug-in running smoothly. Did you try giving it less COM work to do by filtering the values being sent to the COM port to only those which make any difference? I did suggest that way back.

I did try with a very simple LUA program that had a button function on it, there was still significant lag, so it has to be the overall program. So I will have to now figure out how to set AM for the WideClient and Sim-A via Windows. Thanks for the links. 

[chanakaf]

10 hours ago, Pete Dowson said:

One thing I realise I don't understand. This "Sim-A" and Throttle Quadrant -- the the one the driver for the other? How are the throttle quadrant values getting to the Simulator? 

Have you tried enabling Axis Logging in FSUIPC to see how frequently throttle values are arriving? Why not connect the Quadrant to the Sim PC?

Sim-A is Sim Avionics. The TQ is a home built system. I have 2 Potentiometers connected to the Throttle axis. the first set of Potentiometers are connected to a BU836 game controller and this is connected via USB to the FS PC. The 2 axis, throttle1 and 2 are configured via FSUIPC.

See attached diagram.

I have not tried Axis Logging and will try that as well. 

[Pete Dowson]

3 hours ago, chanakaf said:

I obviously I didn't fully understand, I think i didn't reverse the order of the binary

Well, it isn't really a reversal, isi t? In a decimal number like 98765, that '9' is obviously "worth" a lot more than the 5. so it is the higher number. In decimal same as in hexadecimal same as in binary, the "yop" part" (first part written) is worth more, has the higher number.

I think I did refer you to a thread in FAQ subforum for more explanation.

3 hours ago, chanakaf said:

So to use Core 3 and 4  I will set AM to ThreadAffinityMask=x18 (011000) correct? or to use cores 3, 4 and 5 AM should be ThreadAffinityMask=x38 (111000). did I get this right?

Yes

3 hours ago, chanakaf said:

I did try with a very simple LUA program that had a button function on it, there was still significant lag

Sorry, lag in what? was it still doing COMs?

2 hours ago, chanakaf said:

Sim-A is Sim Avionics. The TQ is a home built system. I have 2 Potentiometers connected to the Throttle axis. the first set of Potentiometers are connected to a BU836 game controller and this is connected via USB to the FS PC. The 2 axis, throttle1 and 2 are configured via FSUIPC.

See attached diagram.

So why isn't the Arduino on the same FS PC? Have you tried that? Seems odd splitting the connections to the one TQ between two PCs.

So Sim-Avionics plays no part in this?.  And things run okay when Sim-Avionics isn't running? If so, doesn't that suggest that Sim-Avionics is monopolising that PC too much?

Pete

 

[Pete Dowson]

Please note I will be off-line till monday (no, not on holiday. Just a weekend with my brother!).

Pete

 

[chanakaf]

Thanks enjoy your weekend! 

[chanakaf]

Hi Pete,

Wanted to share an update with you. I have not been able to find the root cause and have moved to an alternative solution that you suggest. I have moved the LUA script to the FS PC and everything works well.

So I will settle for this and move forward. Appreciate very much all your help.

Anthony

[Pete Dowson]

5 hours ago, chanakaf said:

So I will settle for this and move forward.

Okay. Thanks for letting me know.

Pete