This Auto Disconnect has got to go

[Thomas Parker]

To whomever develops xPilot,

 

While I very much appreciate the problem you're trying to solve, the algorithm that determines when to disconnect is quite wrong. Please find a better solution. Getting repeatedly disconnected when I'm over 30 FPS is quite annoying.

 

Thank you,

Tom

[Matthew Bartels]

Perhaps instead of just complaining about it, you can provide the logs of what‘s going on so the developers can figure out what your particular problem might be and use that to refine the logic.

[Thomas Parker]

You are correct. I had a weak moment. I haven't posted in years to avoid flame wars. I succeeded very nicely until tonight. Oh well.

 

I think there are additional factors that need to be included in the decision to disconnect besides just framerate. xPilot has got to be aware if there is other traffic around me. It has the data. It has also got to be aware if I'm flying within actively controlled airspace. It has that data too.

 

99% of my flying is during off hours with just a couple of my buddies and me. We are getting disconnected when a) our frame rates are quite obviously above the 20 required and b) we're not within 500 miles of anyone who might even possibly care. Maybe besides just collecting frame rate data from a bunch of people who are saying their frames are good, the team could also consider other factors that don't warrant disconnecting. Perhaps surveying users to understand the scenarios where they're getting disconnected and it doesn't matter.

 

Sorry for the tone of my initial post.

 

Tom

[Justin Shannon]

As Matthew said, complaining about something doesn't solve anything. If you think you're being unfairly disconnected, then I need a complete frame rate data log. If you're unfamiliar with how to do this, follow these steps:

 

• Load a flight
  
• Go to the X-Plane settings and find the "Data Output" tab
  
• Check the "Disk (data.txt File)" option for Frame rate
  
• Perform a flight and take note of the number of times that you received a warning and was forcibly disconnected
  
• Upload the full data.txt log file here

[Ross Carlson]

I think there are additional factors that need to be included in the decision to disconnect besides just framerate. xPilot has got to be aware if there is other traffic around me. It has the data. It has also got to be aware if I'm flying within actively controlled airspace. It has that data too.

 

Something to consider here is that yes, the pilot client knows if there is other traffic nearby. What it doesn't know is whether or not there will be other traffic nearby in the future. In my opinion, it is better to find out as soon as possible that your frame rate is dropping below the minimum, before it becomes a problem.

[Thomas Parker]

This is a tough problem for sure. And the true solution is to have X-Plane keep real-time progress even with slow frames. I'll try to capture some logs to see what's happening on my side.

 

I have a question, perhaps a request. Would it be possible for you to actively display what xPilot considers to be the framerate in relation to it's threshold? Even better would it be possible to have a ticker-tape display of its running average over time, also in relation to its threshold? (Think a debugger mode.)

 

For me to help optimize my settings, it would go far to understand what scenarios are getting me booted. (It's not always the obvious culprit of heavy clouds.) My goal is to have the highest display settings possible while still staying connected.

 

Thanks,

Tom

[Robert Shearman Jr]

the true solution is to have X-Plane keep real-time progress even with slow frames.

And that's never going to happen, because it would mean completely rewriting every inch of their flight model computation code.

 

Before I comment further on that, I'm prefacing my response with this: the current detection mechanism for whether VATSIM pilots are below 100% sim rate seems awfully flawed at the moment, based on the number of people saying they're well above the 20fps threshold and still getting dropped. If it worked as intended, I would fully support it.

 

But, back to X-Plane: they intentionally do not allow their software to calculate any greater interval in Flight Dynamics than 1/20th of a second. This is true no matter how long that frame actually takes to render. So, the effect is that at any less than 20 frames per second, time is p[Mod - Happy Thoughts]ing more slowly within your sim than anyone else's.

 

When you ask the developers at Laminar why this is, their resoonse is akin to what everyone here has been saying, which is that their product was simply not designed to run on computers that can't keep up with the math. In fact, the tone of their blog on the subject seems aghast that anyone would even consider running their software at any less than 60 frames per second.

 

https://developer.x-plane.com/2017/10/x-plane-11-10-beta-5-ding-dong-the-fps-nag-is-gone-mostly/

 

So no matter what any of us think, it's out of the hands of anyone at VATSIM to fix. FSX and P3D (a) were not designed that way so sim rate remains constant regardless, and (b) are much easier on the CPU than X-Plane to begin with. NEITHER product was specifically designed with realistic multiplayer-based air traffic simulation in mind, so we're left to deal with both products as they are.

[Tobias Dammers]

The odd thing about this is that other sims can do it just fine.

 

FlightGear, for example, will always keep the FDM running at 120 FPS, even if rendering slow down to a completely unflyable slideshow. It doesn't alter the time slice, it just allocates more CPU to the FDM and less to the rendering in order to keep up. I haven't read any XPlane source code, but if I had to guess, I would wager that the logic goes something like this in FG:

 

1. Render a frame.

2. How much time has p[Mod - Happy Thoughts]ed since the last logic update? Multiply that number (in seconds) by 120, and perform this many FDM updates, each with a time delta of 1/120 s.

3. Repeat.

 

Whereas XPlane seems to be doing this:

 

1. Render a frame.

2. How much time has p[Mod - Happy Thoughts]ed since the last logic update? If that number is larger than 1/20 s, perform one FDM update with a time delta of 1/20 s, otherwise, perform one FDM update with a time delta equal to that number.

3. Repeat

 

While this suggests that XPlane's FDM uses a variable delta, that doesn't mean fixing it would require a complete rewrite of the FDM. You can still cap it at 1/20 s, you just have to run it multiple times if a frame took longer than 1/20 s to render. Just keep doing updates at 1/20 s until the remainder is less than 1/20 s, then one more update to get it to 0. You don't have to touch the FDM code itself at all, just call it more often.

 

Of course that still doesn't mean the XPlane folks will fix it - not unless there is a financial incentive for them, that is.

[Robert Shearman Jr]

Read the blog post I linked as to why they do it that way. They actually explain it in great detail. Besides, it's their choice to make, not ours nor anyone at VATSIM's. And it's not going to change anytime soon no matter how much we kvetch about it, so we just have to come up with coping strategies.

[Gunnar Lindahl]

Thomas

 

Can you please post the log as requested above, so that the Devs can look into why you are having an issue? It is literally impossible to diagnose without this information. Help them help you.

[Tobias Dammers]

Read the blog post I linked as to why they do it that way. They actually explain it in great detail. Besides, it's their choice to make, not ours nor anyone at VATSIM's. And it's not going to change anytime soon no matter how much we kvetch about it, so we just have to come up with coping strategies.

 

Yes. Their blog pretty much says exactly what I described. They're not giving any convincing reasons though, other than "significant engineering effort", which, frankly, I'm not buying. Frame skipping isn't rocket science, and it doesn't require "independent" execution of rendering and logic, only changing the lock-step such that the "render" part may be skipped if the whole thing can't keep up.

 

Sure, it would eat into rendering performance, yes, THAT IS THE POINT. You want to sacrifice rendering performance (which is at least 50% cosmetic) before correctness (which is 100% essential). The XPlane devs don't seem to agree with this though, and they don't seem to understand why it is what many users want.

 

My personal [Mod - Happy Thoughts]essment would be that this means that XPlane is simply not suitable for use on an online multiplayer platform like VATSIM.

[Ross Carlson]

My personal [Mod - Happy Thoughts]essment would be that this means that XPlane is simply not suitable for use on an online multiplayer platform like VATSIM.

 

You're not even going to qualify that [Mod - Happy Thoughts]ertion by adding something like "unless you have the hardware to maintain the minimum sim rate" ?

[Thomas Parker]

My initial post doesn't really convey my underlying message. Unfortunately, I was aggravated at the time I posted.

 

I'll gather the log files and submit them.

 

Trust me, I get it. On a Friday night where a hundred planes are all piling into a single airport, to have an incompatible aircraft in the string of pearls going into LAX can wreak havoc. I get it. I also know the futility in trying to get XPlane to change. I said that only to define one end of the spectrum of solutions -- impractical as it may be.

 

I think my underlying thought in all this is that there must be a way to make smarter decisions about when to disconnect. To me, in my situation, it just seems silly to get disconnected on an early Saturday morning when there isn't a single controller on in the entire US, the closest plane is my buddy who's also using Xplane, and it's just the two of us for hundreds of miles. In that scenario, it's made a bit more irksome when I know I'm above the 20fps. (Yes, I'll provide the logs after my next flight.)

 

Anyway. I'm signing off. I know that my first post wasn't going to get me very far in this discussion. Now that I've cooled down, I'd like to continue participating in a more reasonable, level-headed discussion about this.

 

Thanks

Tom

[Ross Carlson]

I think my underlying thought in all this is that there must be a way to make smarter decisions about when to disconnect. To me, in my situation, it just seems silly to get disconnected on an early Saturday morning when there isn't a single controller on in the entire US, the closest plane is my buddy who's also using Xplane, and it's just the two of us for hundreds of miles.

 

I definitely sympathize with this point of view, and you're not the only one to suggest that the low sim rate detection code should be disabled when there aren't many other aircraft around. However, the way I see it, that would just be delaying the notification of the problem until the point where it has now become a problem not just for you, but also for other pilots and controllers. Better to be notified of the situation when you're out in the middle of nowhere so you can deal with it before it becomes a problem for others.

[Tobias Dammers]

My personal [Mod - Happy Thoughts]essment would be that this means that XPlane is simply not suitable for use on an online multiplayer platform like VATSIM.

 

You're not even going to qualify that [Mod - Happy Thoughts]ertion by adding something like "unless you have the hardware to maintain the minimum sim rate" ?

 

Not really, no. You can get away with it, but the design is fundamentally flawed, and all it takes to derail the thing is a bit of unexpected background activity, or a more demanding aircraft model.

[Ross Carlson]

Not really, no. You can get away with it, but the design is fundamentally flawed, and all it takes to derail the thing is a bit of unexpected background activity, or a more demanding aircraft model.

 

What about all the people that have been flying with X-Plane on VATSIM for years with sim rates sufficient to not cause issues for others?

[Dhruv Kalra]

Not really, no. You can get away with it, but the design is fundamentally flawed, and all it takes to derail the thing is a bit of unexpected background activity, or a more demanding aircraft model.

 

What about all the people that have been flying with X-Plane on VATSIM for years with sim rates sufficient to not cause issues for others?

 

To be fair, even I eat an occasional disconnect on high end hardware due to load spikes when entering complex scenery, etc.

 

I think there are varying degrees of this issue. Even ESP based sims are subject to the occasional freeze of 30s or more when loading scenery. The problem now is that in order to whack the chronically “slow motion” X-Plane installs we’re also penalizing the ones that by and large stay at healthy frame rates but get the occasional bog down.

 

Hopefully 11.50 and Vulkan improve the underlying situation for the latter cl[Mod - Happy Thoughts] of users, because those are the ones that most vocally feel wronged by this change.

[Andreas Fuchs]

At VATSIM Germany a member has created a FlyWithLua script that compares the in-game travelled distance per time vs the expected distance travelled per system time. This way we can also see when XP is going slower than expected/required. And this way one could determine for how long this happened and how big the impact was. We continue testing it.

[Ross Carlson]

Not really, no. You can get away with it, but the design is fundamentally flawed, and all it takes to derail the thing is a bit of unexpected background activity, or a more demanding aircraft model.

 

What about all the people that have been flying with X-Plane on VATSIM for years with sim rates sufficient to not cause issues for others?

 

To be fair, even I eat an occasional disconnect on high end hardware due to load spikes when entering complex scenery, etc.

 

Here, I'm not making any commentary on VATSIM's current implementation of the FPS disconnect. I'm merely reacting to Tobias' [Mod - Happy Thoughts]ertion that X-Plane is not suitable for online flying. An [Mod - Happy Thoughts]ertion that he made on the basis of how he believes X-Plane works internally and his [Mod - Happy Thoughts]umption about Laminar's willingness to re-engineer the sim. It's a blanket statement that ignores all the people that fly X-Plane on VATSIM without causing issues, such as yourself.

[Simon Charman 1469612]

I am new to VATSIM, and use X-Plane, and to be honest I won't be logging in again any time soon. Personally my frames are fine but I hear this disconnect problem isn't programmed right and I hate reading all bad blood towards X-Plane users. I don't understand why a network would want to discourage numbers online. Just pleased I now have Traffic Global from Just Flight and my airports now look plausible.

[Tobias Dammers]

I'm merely reacting to Tobias' [Mod - Happy Thoughts]ertion that X-Plane is not suitable for online flying. An [Mod - Happy Thoughts]ertion that he made on the basis of how he believes X-Plane works internally and his [Mod - Happy Thoughts]umption about Laminar's willingness to re-engineer the sim. It's a blanket statement that ignores all the people that fly X-Plane on VATSIM without causing issues, such as yourself.

 

It's not just a wild guess; the blog post linked elsewhere explains quite a bit about how XPlane's timing works, and what the design considerations were. Anyone with a bit of experience in game dev or realtime simulation programming should be able to deduce from that more or less what I did.

 

As far as willingness to re-engineer goes, the blog post is quite vocal about this, and basically says it's not going to happen. The path forward they state is to improve overall performance, so that FPS drops don't occur anymore, rather than changing the timing logic so that the FDM stays in sync regardless of rendering frame rate. It's not an [Mod - Happy Thoughts]umption, I'm just paraphrasing Laminar's own statement.

 

When I said that X-Plane is unsuitable for online flying, I mainly meant that the timing model is fundamentally unsuitable.

 

The problem is that any frame beyond 50ms will cause the simulation to lag, and that lag is never caught up on, it just keeps accomeulating. So even a fairly undisruptive performance problem, like a background process stalling the machine for 100 ms every 2.5 seconds or so, will accomeulate to several minutes of drift after a few hours of flying (more than one minute per hour of flying). And the simulator makes absolutely no attempt to compensate. The time you lost on those frames is lost forever. Now imagine a 7-hour flight where, by the time you contact approach, your clock is out of sync by 8 full minutes. You're arriving 8 minutes later than scheduled, and any Zulu times you receive or report will be off by 8 minutes. Fortunately, things like ETAs and such are usually communicated in a relative fashion, and ATC normally doesn't care much about the arrival time scheduled by your flight plan, but it's still plain out wrong.

 

You can try to not have any of those stutters ever, but I don't know of a truly reliable method - other than using a simulator that makes an attempt to stay synched with the wall clock time (i.e., an actual realtime simulation).

[Alexander Cohrs]

Do you guys think we might see a similar behaviour of MSFS2020? My understanding is that they aim to maintain 60 FPS by all means. Does that mean they also have to go a similar way like X-Plane? And would that mean the same rule now enforced on X-Plane pilots will also be enforced on them - but with the difference that it's a forced disconnect <60 FPS for them?

[Ross Carlson]

Tobias, unless you're on the dev team, you're making [Mod - Happy Thoughts]umptions. They may be informed [Mod - Happy Thoughts]umptions, but still [Mod - Happy Thoughts]umptions at the end of the day. And I never said anything about a "wild guess".

 

Where I disagree with you is when you make the blanket statement that X-Plane is not suitable for online flying on networks like VATSIM. Years of successful flights are evidence to the contrary.

 

Do you guys think we might see a similar behaviour of MSFS2020? My understanding is that they aim to maintain 60 FPS by all means. Does that mean they also have to go a similar way like X-Plane? And would that mean the same rule now enforced on X-Plane pilots will also be enforced on them - but with the difference that it's a forced disconnect <60 FPS for them?

 

It is WAY too early to tell.

[Florian Grundl]

I there a way to check the fps only below a certain altitude? I'm always getting disconnected in cruise, where low fps should not really matter.

[Nestor Perez]

There is also sequencing that goes on en-route, so I doubt that will ever be a thing, unfortunately. Actually tbh I'd say that's where it causes the most issues, since a 5% difference in speed (5% per frame below 20) means a greater difference than at lower speeds.

Edited January 25, 2020 at 02:06 PM by Guest