xPilot Frame Rate Logic

[Justin Shannon]

I am aware of a potential issue with the current frame rate check logic. I am investigating and will work on having a fix out within the next few days. Please be patient with me!

[Tom Knudsen]

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.

 

[peter mason 812903]

Can I add my confirmation of an issue here and the thought that I see large dropouts of nearly zero frame rates for several seconds that may well be my installation but this is the real world as I say in my other thread and as I also say this is a nice piece of software.

[peter mason 812903]

The update has arrived and the other issues have been addressed. Many thanks. I will try it with traffic latter.

[Daniel Dezulier]

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

[Daniel Dezulier]

I let the script running while writing previous post and on the last 15 minutes there are only 3 drops for 50000 measures ...

I ll provide the code for people who want to test their configuration.

[Daniel Dezulier]

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

 

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.

[Matthew Bartels]

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.

[Justin Shannon]

I appreciate your effort on this, Daniel. However, I will not be making any further tweaks to the frame rate detection. xPilot now uses the same algorithm used within XSB to keep things consistent.

[Daniel Dezulier]

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.

[Matthew Bartels]

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.

[Nestor Perez]

@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.

[Daniel Dezulier]

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 ...

[Matthew Bartels]

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.

[Daniel Dezulier]

Planes don't appear in X-Plane like vessels in StarWars ... When being at more than 5 NM it does not matter for me that a 777 can be stuck in the air like a balloon. I find it a little bit too rude.

Edited January 9, 2020 at 05:57 AM by Guest

[Andreas Fuchs]

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.

[John Da Costa]

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.

[Ross Carlson]

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.)

[Liesel Downes]

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.

[John Da Costa]

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

[Daniel Dezulier]

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.

[Liesel Downes]

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.

[Andreas Fuchs]

Somebody will come up with a scrip to automatically re-connect

[Daniel Dezulier]

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 January 9, 2020 at 01:20 PM by Guest

[Nestor Perez]

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