Statement about X-Plane Simulation Rate Enforcement

[Christopher Collins]

Because there's a lot of noise going on about this, I've written an informative article about the decisions and design intent of this feature.

 

Constructive and clarification related discussion only in this thread please.

[Andreas Fuchs]

Hi Chris,

 

thanks for the in-depth explanation. The bottom line is that almost all XP-pilots agree that the FPS problem must be addressed, but as we can see there may be some cases where users are flying with much higher FPS than required and still get warned or even disconnected for short drop of frame rates. Whether this is all legit, I cannot judge.

 

Maybe something interesting to all readers here, one of our ATCOs in Berlin Tegel EDDT has made a video that clearly illustrates the effect of an XP-pilot with low FPS:

[Robert Shearman Jr]

I do think there are some flaws in the implementation. I'm posting some screenshots from xpilot, but I'm told by Justin that his code was copied line for line from yours, so I presume the implementation should be the same.

 

Your blog post mentions that after 1 minute of acceptable frame rates, the warning countdown timer should be reset. In the attached image, however, I got the warning countdown, followed by the "your frames are healthy" message. Then 4 and 1/2 minutes later there was another FPS dip and I was disconnected immediately. It doesn't seem to me like the clock resets as you claim. Later, again, there is a period of a minute and a half between warning countdown messages. Based on your blog post that last warning countdown should have started fresh.

 

EDIT to add the relevant p[Mod - Happy Thoughts]age:

To make sure this remains fair, if the frame-rate is consistently good for a certain period (presently 60 seconds), we can treat any other failures previously in the session as transient, and we reset the slow-time pool back to 0.

 

https://i.imgur.com/y2DBJtO.jpg

Edited January 14, 2020 at 04:03 PM by Guest

[Petter Storvik]

i have the same problem!!

[Christopher Collins]

I do think there are some flaws in the implementation. I'm posting some screenshots from xpilot, but I'm told by Justin that his code was copied line for line from yours, so I presume the implementation should be the same.

 

Your blog post mentions that after 1 minute of acceptable frame rates, the warning countdown timer should be reset. In the attached image, however, I got the warning countdown, followed by the "your frames are healthy" message. Then 4 and 1/2 minutes later there was another FPS dip and I was disconnected immediately. It doesn't seem to me like the clock resets as you claim. Later, again, there is a period of a minute and a half between warning countdown messages. Based on your blog post that last warning countdown should have started fresh.

 

EDIT to add the relevant p[Mod - Happy Thoughts]age:

To make sure this remains fair, if the frame-rate is consistently good for a certain period (presently 60 seconds), we can treat any other failures previously in the session as transient, and we reset the slow-time pool back to 0.

 

https://i.imgur.com/y2DBJtO.jpg

 

I did a review yesterday and confirmed the behaviour of the timers were correct, there's a bug in the warning code where it doesn't display a warning after a reset until you've burnt off more "slow" time than you have previously. Justin has the fix for that already, and it'll be in the next XSB build/release.

[Robert Shearman Jr]

To make sure this remains fair, if the frame-rate is consistently good for a certain period (presently 60 seconds), we can treat any other failures previously in the session as transient, and we reset the slow-time pool back to 0.

In the attached image, however, I got the warning countdown, followed by the "your frames are healthy" message. Then 4 and 1/2 minutes later there was another FPS dip and I was disconnected immediately. It doesn't seem to me like the clock resets as you claim.

there's a bug in the warning code where it doesn't display a warning after a reset until you've burnt off more "slow" time than you have previously. Justin has the fix for that already, and it'll be in the next XSB build/release.

AHA. Right -- I can see where that would still fit the behavior I was seeing; the clock was indeed resetting but the warning messages were stifled by the logic. Good deal; thanks for looking into it.

[Tobias Dammers]

As an experienced programmer (30+ years), my gut feeling is that sampling the frame rate is the wrong way to go about this.

 

We don't actually care all that much about the client's frame rate - I can fly at 8 fps with flightgear, and the ATCO won't even notice a difference, it just makes the aircraft more difficult to handle for me as a pilot. That's because flightgear took a different approach to dealing with insufficient system resources: instead of slowing everything down, it keeps the FDM running at full speed and only slows down rendering. So when I'm running at 8 fps, the FDM still gets 120 updates per second, there's just going to be 15 of them per rendered frame.

 

What we do care about is that when the simulator says your speed is 120 kts, then you should be covering 2 miles per minute according to the VATSIM network. Since position data is uncontroversial, the difference is due to in-sim clock vs. VATSIM clock (which in turn should be identical to real-world clock). So a better approach would be to either detect in-sim clock drift (comparing RTC elapsed time since startup against in-sim time since startup), or to detect deviations in ground speed as reported in-sim vs. as seen on the network.

 

This approach has several advantages:

 

1. It measures what we actually care about.

2. It doesn't require frequent sampling: just getting the current position and ground speed once every 5 seconds or so, figuring out the ground track distance, and checking whether the effective speed is within limits of the reported speed. No averaging of frame rates is needed, just a bit of an error margin (e.g., at 120 kts groundspeed, you'd expect 2 miles in 1 minute, but 1.98 miles is probably still OK, while 0.95 miles is definitely not).

3. It's future proof and relatively sim-agnostic - a client like Swift could easily implement this for all supported simulators. This would detect not just automatic time scaling like XPlane does, but also deliberate or accidental meddling with the time factor, pausing, and other anomalities. And if XPlane decides to make the time scaling thing optional via a configuration switch or something, then users solving the problem this way will not be punished for a crime they didn't commit.

[Christopher Collins]

What we do care about is that when the simulator says your speed is 120 kts, then you should be covering 2 miles per minute according to the VATSIM network.

 

Be careful of how you redefine the problem. That's not what we actually care about.

 

What we care about is that, barring explicit user action, ....

 

Please read CoC B9 which is the main counterforce against doing nothing.

 

We do not accept that misconfiguration is explicit user action, nor that a user can seek permission for a symptom that they do not know is happening.

 

All of your fixes break explicit user action.

 

We are not about to implement ways for time dilation to occur "with permission" because the feature will just be abused so it can be ignored, just as people dismiss the XP11 warning without consideration. I'm not about to go out of my way to break other legitimate actions though.

[Tobias Dammers]

I think you misunderstood. I'm not saying time dilation should be allowed on the network. Not at all. If a client turns out to dilate time, then disconnecting them is the right thing to do. A client that does this is broken, and it is the user's responsibility to fix it.

 

All I'm saying is that "FPS" is a bad metric for this, and we should be measuring actual time dilation instead.

[Christopher Collins]

All I'm saying is that "FPS" is a bad metric for this, and we should be measuring actual time dilation instead.

 

No, you're suggesting metrics enforcement that cannot differentiate explicit action from time dilation. That simply isn't going to work.

[Stefan Loos]

What if a bad pool reset never happens because I run in 60seconds allways in one (only one!) slowdown for short time but exceeding the threshold (object reload, clouds...)?

[Robert Shearman Jr]

What if a bad pool reset never happens because I run in 60seconds allways in one (only one!) slowdown for short time but exceeding the threshold (object reload, clouds...)?

Stefan -- I wouldn't expect an answer if you are truly asking "what if," as in, asking about a hypothetical situation. If you're saying that you ARE getting disconnected unfairly because of this, I recommend you take some screenshots and/or videos illustrating it clearly.

[Stefan Loos]

HI Robert.

I tested it a bit. I forced my fps to be at 25fps approx, standing at a gate. With this allready critical fps, but totally ok for the network, every switch to desktop (pdf chart scolling..) and back, or view change (shift+5 very evil) will lead to a collected bad timing, and when I do this within 60sec (e.g. every 50seconds only), I never got a pool reset !!! So the algo collects bad timing and never resets. A disco is only a question of time.

Note: tested XPilot! But he claims to use same algo.

btw: does the logic makes sense to throw out people standing on ground (vgnd < X knots?) who prepare their flight working heavily with 3rd party tools and in a fps intense environment?

I´d propose: for every X seconds "clean" fps (e.g. 10sec), reduce bad pool by 1second

Best regards

[Christopher Collins]

HI Robert.

I tested it a bit. I forced my fps to be at 25fps approx, standing at a gate. With this allready critical fps, but totally ok for the network, every switch to desktop (pdf chart scolling..) and back, or view change (shift+5 very evil) will lead to a collected bad timing, and when I do this within 60sec (e.g. every 50seconds only), I never got a pool reset !!! So the algo collects bad timing and never resets. A disco is only a question of time.

 

Yes, because your simulator is demonstrating that it cannot consistently keep above the hard 20fps floor. 20fps is not a target average, it's an absolute minimum.

 

The recovery interval is explained in the statement, complete with its current threshold, which you clearly haven't read, otherwise you'd realise that all you've done is prove that it is working precisely as designed.

 

Before you waste everybody's time trying to argue from ignorance, I strongly suggest you carefully read the statement (linked at the start of this thread) and understand precisely what the goals are and what it's doing.

 

If you want to claim that a behaviour is occuring in error, then you need data to show that it's being applied incorrectly. If you're an XSB user, you can refer to my instructions on the known issues page of the website of what you need to report and how to report it.

 

If you want to claim that the methodology is wrong, you need to make sure that your suggestions:

1. are aligned to the goals and not your personal desires
   
2. are achievable without an unreasonable burden on the developers and/or network and it's staff
   
3. can be done solely within the client, that is, without changing the protocol or servers or X-Plane itself
   
4. are not so slow in responding to legitimate problems that they go undetected until after the user has already created a significant problem.
   
5. do not interfere in authorised or permitted use on the network

 

You will also find that my statement covers approaches I considered and dismissed as not reasonable or not achieving our goals. If you want to argue any of those points, please make sure you're approaching it from a legitimately unconsidered aspect, and not just clutching at straws.

[Stefan Loos]

xpilot changed algo.

bye

[Steve Biddle]

Hello,

Question. I am still using version 1.3.3 with no problems. Is it recommended to update to the latest client? I like the idea that if it's not broke, don't fix it. Thank you.

 

Best regards,

Steve B.

[Christopher Collins]

Hello,

Question. I am still using version 1.3.3 with no problems. Is it recommended to update to the latest client? I like the idea that if it's not broke, don't fix it. Thank you.

 

Yes. 1.3.3 lacks ACCONFIG support (which provides ground-level correction & aircraft configuration sharing) & lacks native AFV support. The entire XSB 1.x series will stop working on the network once 2.0 is stable. Given that a lot of the issues have been dealt with (although it looks like another macOS build issue has crept in), and the next release after beta5 will be stable, now is a good time to switch.

[Steve Biddle]

Yes. 1.3.3 lacks ACCONFIG support (which provides ground-level correction & aircraft configuration sharing) & lacks native AFV support. The entire XSB 1.x series will stop working on the network once 2.0 is stable. Given that a lot of the issues have been dealt with (although it looks like another macOS build issue has crept in), and the next release after beta5 will be stable, now is a good time to switch.

 

 

 

Thanks for the heads up Mr. Collins. Appreciate all the time and effort that you have invested to make this happen!

 

Regards,

Steve B.