Jump to content

xPilot Frame Rate Logic


Recommended Posts

Thank you sir. There is truly an issue with the logic.

 

As you can see in this image, top left is the FPS number in X-Plane, while the logic of X-Pilots several times said I was below the limit, ending in disconnect after the fourth time.

 

2020-01-05-174257.jpg

Controller 1 - VATSIM Scandinavia 

Asus ROG Maximus XI Formula - Intel i9-9900K - Asus ROG STRIX RTX 2080TI - G-Skill 64GB DDR4 3600Mhz - 1x 1TBSSD, 2x 1TM2, 12TBSATA

Link to post
Share on other sites

Flying with 3JFP activated and tweaks to have 35-55 FPS : got MSG

Coding a sensor in lua to get short drops of FPS.

It shows signals that short drops can occurs, but less than 1/16s (invisible by human eyes on a FPS rate displayed by X-Plane on the screen).

During one minute the sensor captured 3 occurrences of FPS < 20 FPS and 3597 occurrences of FPS > 20

th0 ~3600 measures for 60 second means there is an average of 60 tick per second and that one ticks lasts less that 1/60 second.

Each ticks is equal in the Windows kernel usage of the lua script, as it is another thread than those dedicated for simulator and especially for drawing plane and computing flying model.

 

So this small code (to be cleaned, of course as it is written in rush) is simple

It proves at least to things :

- there are FPS drops under 20

- they are very short and last an average of 1/60 s

 

I ll test the script against a heavy scenery

Link to post
Share on other sites

So I wrote a lua script as light as possible not to perturb the FPS check

It catches FPS given by X-plane at each frame

It draws FPS distribution in 0 - 10 - 15 -20 -25 - 30 - > 30 and aggregate the sum for < 20 FPS and the sum > 20FPS

Screenshot-2.png

 

The low FPS occurs from time to time and lasts 0.03 s as written on top left.

 

So xPilot detects that sometimes (~1 time on 1000 in average), FPS dropped on my computer.

It effectively happens.

If it occurs a lot it is visible, loss in fluidity , slideshow effect, and for sure network impact.

If it is rare (my case 1/1000 of time) it is more difficult to detect, but, by the way, it is not an issue for simulator nor the network transmission.

 

The point is to tweak at which value it is necessary to warn users, and at each other value it is mandatory to disconnect.

Using a dot of color

Intense green/light green/yellow/orange/red situated on the xPilot windows might visual warn user without the annoyance of popup.

An additional menu in plugin/xPilot/checkFPS could give more information

While green - not message - if yellow light periodicity msg - if orange high periodicity msg - if red disconnection.

 

For changing color, it would be measured by VATSIM specific rule, or just given by the ratio of BAD/GOOD, and predefine threshold for each change of color.

 

Hope it'll help.

Link to post
Share on other sites
  • Board of Governors
snip

 

I like your ideas a lot. The only catch is we have to start the disconnect clock at FPS < 20 and have the improvement happen before the time expires. We can't have users hanging out below 20FPS for extended periods of time because that's the threshold for slowdown starting. I have no technical knowledge of how it all works, I just know that's when it starts. a couple of frames here or there aren't the problem, it's when we enter slow simulation rate for 30 seconds or more that we really can start seeing issues, or if the user is in and out of slow / normal / slow / normal.

Matt Bartels
VP: Marketing & Communication
## vpmkt (at) vatsim.net
Facebook Twitter Instagram
VATSIM Logo

Unless otherwise stated, opinions are my own and not representative of the official opinion of the VATSIM Board of Governors

 

 

 

Link to post
Share on other sites

Hello Matthews, Justin,

I agree with the fact that a zombie or sleeping computer, annoying all other simmers (pilots and controller) under control in the same area has to be disconnected.

For my own experience, I was in an uncontrolled area, without ATC and no other simmers around.

So I hope version 1.1.9.0 is tweaked to disconnect only when close to a controlled area or when other buddies are there.

To be disconnect in a desert area does not help really.

 

The script I wrote showed my computer had an average of 1/1000 FPS drop under 20FPS. and 95% above 35 FPS

By the way, I would have been under control, at 50% drop under FPS I probably advised controller that I couldn't handle the plane and disconnected by myself. Even at 30% ...

 

If xPilot 1.1.9.0 observe the evolution on FPS on a period (probably the XSB algorithm), and if the trigger is well tuned it'll be better.

 

I added a test in my code to check if X-Plane 11.41 protects itself for low FPS by reducing visibility to save FPS. It is one of the dataref I look at.

 

I ll check tomorrow with more demanding aircraft on more demanding scenery, but without control not to annoy anyone with my test.

Link to post
Share on other sites
  • Board of Governors
Hello Matthews, Justin,

I agree with the fact that a zombie or sleeping computer, annoying all other simmers (pilots and controller) under control in the same area has to be disconnected.

For my own experience, I was in an uncontrolled area, without ATC and no other simmers around.

So I hope version 1.1.9.0 is tweaked to disconnect only when close to a controlled area or when other buddies are there.

To be disconnect in a desert area does not help really.

 

The script I wrote showed my computer had an average of 1/1000 FPS drop under 20FPS. and 95% above 35 FPS

By the way, I would have been under control, at 50% drop under FPS I probably advised controller that I couldn't handle the plane and disconnected by myself. Even at 30% ...

 

If xPilot 1.1.9.0 observe the evolution on FPS on a period (probably the XSB algorithm), and if the trigger is well tuned it'll be better.

 

I added a test in my code to check if X-Plane 11.41 protects itself for low FPS by reducing visibility to save FPS. It is one of the dataref I look at.

 

I ll check tomorrow with more demanding aircraft on more demanding scenery, but without control not to annoy anyone with my test.

 

The disconnect will happen regardless of air traffic control being online or offline. Slow FPS xplane users still cause conflicts with other pilots even when there is no atc around.

Matt Bartels
VP: Marketing & Communication
## vpmkt (at) vatsim.net
Facebook Twitter Instagram
VATSIM Logo

Unless otherwise stated, opinions are my own and not representative of the official opinion of the VATSIM Board of Governors

 

 

 

Link to post
Share on other sites

@Daniel, from the XSquawkBox (not xPilot) developer, in the VATSIM Dev Discord server (quoting with his consent):

XSB has a few tweaks to the way we deal with framerate, and we don't deal with averages because averages cause problems - it's all instantaneous based, with grace periods. We always use instantaneous rates because XPlane has a bad habit of dropping one frame randomly and recovering almost immediately - if you count all of those all the time, it'll pull the mean down, maybe unfairly. Median is probably a better measure.

 

We also completely ignore small interval drops. If X-Plane only drops its framerate for 1-2 frames in 60, who cares? The margin is small enough that nobody will notice. [Right now] We start caring if in an interval of 10 frames or less, 5 of those are slow. That's a persistent problem. To actually trigger the XSB feature requires gross failure.

Néstor Pérez
A Random Platypus
## [email protected]
Facebook Twitter Instagram
VATSIM Logo
Link to post
Share on other sites

Yes, my little piece of code points out the phenomenon : random drops.

I count those <10FP ; 1530FPS

For hours of running, 1/1000 to 2/1000 under 20FPS, 0 below 15FPS, 0 below10FPS, on my standard configuration.

 

By the way a FPS drop, isolated, may be hidden in network retries fluctuations. I totally agree with this point of view (I was accused to yelled so )

When the drop repeat during a gap, it might be an issue and then disconnecting may be one of the solution.

I told about 50% and the quote from XSB says the same thing.

On addition for Matthew and Justin : when being alone in an area, flying half the speed because of 50% FPS drop under 20 is not an issue. Don't be rough that much as people need room to test their tweaks, step by step, and online.

I can give a clue : the "who is online?" option might helps to detect if there is somebody else in the area ...

Link to post
Share on other sites
  • Board of Governors
Yes, my little piece of code points out the phenomenon : random drops.

I count those <10FP ; 1530FPS

For hours of running, 1/1000 to 2/1000 under 20FPS, 0 below 15FPS, 0 below10FPS, on my standard configuration.

 

By the way a FPS drop, isolated, may be hidden in network retries fluctuations. I totally agree with this point of view (I was accused to yelled so )

When the drop repeat during a gap, it might be an issue and then disconnecting may be one of the solution.

I told about 50% and the quote from XSB says the same thing.

On addition for Matthew and Justin : when being alone in an area, flying half the speed because of 50% FPS drop under 20 is not an issue. Don't be rough that much as people need room to test their tweaks, step by step, and online.

I can give a clue : the "who is online?" option might helps to detect if there is somebody else in the area ...

 

Time to be blunt. It's simply not going to happen. Just because this moment you are not interfering even if you checked who's online that doesn't mean that in the next moment you won't be.

Matt Bartels
VP: Marketing & Communication
## vpmkt (at) vatsim.net
Facebook Twitter Instagram
VATSIM Logo

Unless otherwise stated, opinions are my own and not representative of the official opinion of the VATSIM Board of Governors

 

 

 

Link to post
Share on other sites

Hi Daniel,

when being alone in an area, flying half the speed because of 50% FPS drop under 20 is not an issue. Don't be rough that much as people need room to test their tweaks, step by step, and online.

I can give a clue : the "who is online?" option might helps to detect if there is somebody else in the area ...

you do not need to be online to test your tweaks. I measured the frame rate drop caused by a VATSIM connection last week. On my system (I am using swift as pilot client, but that should be identical to xPilot in terms of performance) I had a drop of 1fps when displaying in excess of 50 aircraft at the same time. That's nothing!

 

So, if your setup gets you to operate near the 20fps-mark then please try to ease the settings of X-Plane to increase your FPS, you can test it offline. On the other hand, pilot clients should not drop your connection if your FPS drop below 20 for a couple of seconds while loading scenery/weather/aircraft/whatever.

Link to post
Share on other sites
You should probably not disconnect people if AGL is below 500ft and Landing gear is under pressure. I was disconnected on very short final after having an uneventful flight. And reconnecting while trying to fly the aircraft is super dangerous.

 

If it's dangerous to reconnect while trying to fly the aircraft, then don't reconnect while trying to fly the aircraft.

 

Also, how is it dangerous? It's a simulation.

 

Please note the emoticons ... I'm (mostly) kidding.

 

In all seriousness, disabling the low FPS disconnect while near or on the ground is an interesting idea, but all it would do is temporarily hide the problem. I think it's better to know that you have a frame rate issue as soon as possible so that you take steps to correct it before you cause issues for others. (Preventing adverse affects on others is, after all, the whole point of this change.)

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy

Senior Controller, Boston Virtual ARTCC

Link to post
Share on other sites

I figured that final approach was one of the worst times for this simulation rate issue to occur regardless, it wouldn't really make sense to mask it then rather than say during cruise.

 

Also yeah, as Ross said, it's not really "dangerous". Just reconnect on the ground as you should do if you encounter issues on approach.

Link to post
Share on other sites

You know people are going to reconnect anyways right away right? i was getting 50 fps when it disconnected me it dropped momentarily while going through clouds. btw but thats not the point. i actually only have had 2 disconnects since the changes. this needs to be resolved via education and not technical blocks. imho

Link to post
Share on other sites
Hi Daniel,
when being alone in an area, flying half the speed because of 50% FPS drop under 20 is not an issue. Don't be rough that much as people need room to test their tweaks, step by step, and online.

I can give a clue : the "who is online?" option might helps to detect if there is somebody else in the area ...

you do not need to be online to test your tweaks. I measured the frame rate drop caused by a VATSIM connection last week. On my system (I am using swift as pilot client, but that should be identical to xPilot in terms of performance) I had a drop of 1fps when displaying in excess of 50 aircraft at the same time. That's nothing!

 

So, if your setup gets you to operate near the 20fps-mark then please try to ease the settings of X-Plane to increase your FPS, you can test it offline. On the other hand, pilot clients should not drop your connection if your FPS drop below 20 for a couple of seconds while loading scenery/weather/aircraft/whatever.

Hi Andreas, by the way, using my script, I get 95 % of my frame > 35FPS, 1/1000 <20FPS and the complement is distributed between 20 and 35. FPS rise up to 50. Yesterday, while loading tiles I was disconnected twice, for several minutes each times and obliged to reconnect manually.

For testing I prefer to be connected to check how xpilot reacts to current tweak.

Link to post
Share on other sites
You know people are going to reconnect anyways right away right? i was getting 50 fps when it disconnected me it dropped momentarily while going through clouds. btw but thats not the point. i actually only have had 2 disconnects since the changes. this needs to be resolved via education and not technical blocks. imho

 

People will of course reconnect anyway, and it's more than reasonable in the situation you just described while the logic is still being fixed. I'd normally agree that this should be an education issue but warnings had been issued for a while prior to this change - let's wait for the fixes, and see what happens next I think.

Link to post
Share on other sites
Somebody will come up with a scrip to automatically re-connect

You are right, someone will do, not me I guess I am not good enough.

 

By the way, I ll fly elsewhere until xpilot just kick off only when it is mandatory to do that.

I'll check from time to time.

I was kicked with FPS average over 45; M Knudsen with a more than 120 FPS average was kicked off also.

So there are probably some tweaks to do.

 

So I admit that if there are problems in controlled area, anywhere I am not convinced. And the response is probably to strong and too wide.

 

I stop annoying the channel.

 

Thank to the staff doing their best to makes things going better for ATC as there is too few ATC, and for all having better flying experience.

 

Hope Laminar will fix what causes this mess.

 

Some people wrote here and there that they also don't understand the non proportional response of the tool in front of the disturbance caused by mis configured computers.

 

Hope it'll doesn't impact image of community.

 

Best regards to all

Daniel

Edited by Guest
Link to post
Share on other sites
Hope Laminar will fix what causes this mess.
It's not Laminar's "fault" (or anybody else's); it's just the way the product was designed and all we can do is adapt to it. As a network we do so by requiring our users to "move" at a minimum simulation rate (which is what low FPSs change), while as users we do so by adjusting our simulator settings correctly, according to the capabilities of our machines. With some very edge cases the only possibility will be -unfortunately- to upgrade our hardware.

 

Some people wrote here and there that they also don't understand the non proportional response of the tool in front of the disturbance caused by mis configured computers.
Correct, and we have acknowledged it. The code wasn't exhaustively tested before release and it happened to have some bugs. There is fixes and patches being worked on as we speak (type?), but it may take a few days until they are released. We make mistakes -just like anybody else- and we will (hopefully) learn from them so we can do stuff better in the future
Néstor Pérez
A Random Platypus
## [email protected]
Facebook Twitter Instagram
VATSIM Logo
Link to post
Share on other sites
Guest
This topic is now closed to further replies.
×
×
  • Create New...