Planning ahead for retiring VRC

[Harry Sugden]

7 minutes ago, Ross Carlson said:

Big questions there, Harry. Would take an essay to answer. 😀

I suppose I’m jealous, and worried that we will get left behind... 😛 

An element of EuroScope that really works is that plug-ins and the various settings do allow us in to modify it sufficiently so that it ‘looks like’ the real national system. The TopSky plugin is so advanced compared to base ES that we have a setup for it in the UK, even if it isn’t what they use in the UK in real.

But I’m far more interested in all the stuff you’re talking about … more seamless handovers, ‘server side’ flexible sectorisation, more advanced data tags, code allocation plans etc. … than I am in fussing over the scope looking wholly realistic!! 

[Matisse VanWezer]

Super exiting!

Little sad we *cough* Europe *cough* won't be able to see this any time soon with ES lagging waaay behind.

Keep rocking Ross! Thank you for making me excited about the future for VATSIM controllers!

[Alistair Thomson]

On 4/29/2022 at 11:39 AM, Ross Carlson said:

build my own server that the clients would connect to, instead of connecting directly to the VATSIM FSD network

Ross, we're all very excited by your approach. I was wondering about how it is affected by the Kubernetes paradigm which I believe the tech department have moved to, and whether or not your external server would be covered by the redundancy and robustness features of K8?

[Ross Carlson]

1 minute ago, Alistair Thomson said:

Ross, we're all very excited by your approach. I was wondering about how it is affected by the Kubernetes paradigm which I believe the tech department have moved to, and whether or not your external server would be covered by the redundancy and robustness features of K8?

I've been talking with the VATUSA tech team and it should be simple to host the server on the VATUSA infrastructure.

[Alistair Thomson]

Excellent.

[Bernardo Reis]

Ross, correct me if I'm wrong but this server side approach will also enable the use of KUSA CPDLC-DCL, correct?

[Thimo Koolen]

Ross, this update makes me both excited for the future of VATSIM, but also jealous as an European controller still stuck with EuroScope.

 

The new architecture idea would be very cool and definitely allow for innovative new features. However, I do wonder if that won't incur a huge cost on hosting? I don't really think there will be very few calls to that new server.

[Ross Carlson]

10 hours ago, Bernardo Reis said:

Ross, correct me if I'm wrong but this server side approach will also enable the use of KUSA CPDLC-DCL, correct?

I wouldn't say it enables it ... I mean that can be done without the Virtual NAS server. Similar to everything else, it just makes it easier to simulate because the simulation platform more closely matches the real world platform.

[Ross Carlson]

8 hours ago, Thimo Koolen said:

The new architecture idea would be very cool and definitely allow for innovative new features. However, I do wonder if that won't incur a huge cost on hosting? I don't really think there will be very few calls to that new server.

There actually are relatively few calls. If you think about how infrequently a controller actually sends a command (handoff, pointout, flight plan amendment, temporary altitude assignment, etc.) to the server for processing, it's relatively rare. Even if we had 200 controllers online in the US, I doubt the server would be processing more than a few dozen messages per second. The server won't even notice the load from that.

The vast majority of the server resource consumption will be for processing aircraft position reports and determining which VATUSA facilities can "see" each one, so that targets and tracks can be updated on any connected clients. I was surprised at how low the resource requirements are for this. I did some load testing by injecting 2,500 aircraft into the server, each sending a position update 5 times per second. I then ran range calculations against 1,000 radar sites every second. (That's the max update rate of the radar display in STARS or ASDEX mode.) So that's 2.5 million range calculations per second. If I use the haversine formula to do a great circle distance calculation, it takes about 300 milliseconds to do all 2.5M calcs. If I use basic Euclidian distance, it takes about 10 milliseconds. This is all on a single core virtual machine with 1 GB of RAM that costs $6/month at Digital Ocean. Pretty amazing.

And I'm actually planning on simplifying the radar coverage calcs dramatically, by essentially simulating nation-wide coverage through ADS-B, which means each aircraft will just need to be checked to see if it is within a polygon defined for each facility, and no great circle range calcs will be needed. I may still do a more advanced radar coverage simulation in a future version, which would simulate terrain blocking, but that will be done with a geohash grid, which will optimize things even further.

We will likely host the server on VATUSA's existing infrastructure, and I doubt it'll raise costs at all.

[Bernardo Reis]

The more I read about this, the more excited I get 😄

VATUSA is going to get an influx of visiting controllers when this gets finished 😛

[Warren Madden]

On 4/29/2022 at 11:39 AM, Ross Carlson said:

Multiple users can be signed into the same position. - This is to facilitate shift change, observing, and student/instructor scenarios. When one user makes a change such as initiating/accepting a handoff, that will be reflected on any other scope for the same position. Even small changes like the position of a data block will be mirrored across all scopes for the same position. Just like how the real systems work.

How will observing work within this structure? Clearly it wouldn't be desirable that an observer could make changes to their scope that would be reflected on the scope of the person actually controlling.

[Ross Carlson]

Observing will work as it does now, you won't be able to take any actions, just observe. The difference will be that you are observing a specific position, so you'll see all their data blocks just as they do. (Where as currently, you are observing the whole area, not a specific position.)

[Warren Madden]

Interesting. While this does solve the potential problem of the active controller having their scope "messed with", this seems to raise the opposite issue: is an observer locked into a completely passive role, with no way to experiment with their client while observing to become familiar with it, develop work flows, etc.?

For example, when I came back to VATSIM after a 14 year hiatus, I was starting from scratch with VRC. So I've spent a lot of time observing BOS_GND, selecting aircraft, examining their flight plans, learning what setup on the strip bay works best for me, moving data blocks around, learning commands, etc. This "interactive observing" has greatly helped me get up to speed with the client.

Will the setup you envision allow an observer to do such things (on a non-interference basis, of course), or will observing be akin to watching a stream of someone controlling?

Thanks as always for the massive amount of work you've put in over the years.

[Matisse VanWezer]

I'd like to hear from Ross himself as well but it's a good check to see if I understand the vision correctly.

My assumption is you can just do everything a normal controller does, except the modifications (alt/hdg/dct/...) don't get send to the server and by consequence aren't registered.

You have full control of where you place your windows, how your tags are set up, you can pan around, zoom, open flightplans but simply not edit them.

I'm not sure about probing tools however, as they require some logic. Will you see other people using separation tools?

Edited May 9, 2022 at 10:13 AM by Matisse VanWezer

[Alistair Thomson]

Whatever Ross is getting paid for all his work, it ain't.enough! (Yes, I know, his pay has several zeros in it. With no other digits...)

Thank you, Ross. 🙂

[Ross Carlson]

7 hours ago, Warren Madden said:

Interesting. While this does solve the potential problem of the active controller having their scope "messed with", this seems to raise the opposite issue: is an observer locked into a completely passive role, with no way to experiment with their client while observing to become familiar with it, develop work flows, etc.?

It will depend on the type of display. There are four types: ERAM, STARS, ASDE-X, and TowerCab. In ERAM and STARS modes, data block positions are synced across all users that are signed into the same position, including observers. In ASDE-X and TowerCab modes, they are not.

So if you sign into an ERAM or STARS position as an observer, you will not be able to move data blocks. This is actually beneficial for learning, since the data block position is often used as more than just a way to keep data blocks from overlapping. It is used to actually mean something, like a memory aid, or even a form of coordination.

I would argue that not being able to move data blocks has no impact on the value of using observer mode as a learning tool. As long as you can pan/zoom the scope, turn maps on/off, view flight plans, and listen to the frequencies, you will get just as much benefit from observing as you did with VRC.

[Heath Abelson]

I'm curious if you've given any thought to how\if you would handle a single controller on multiple positions? This comes up for combined TRACON's or other situations where a single controller can combine positions together.

Currently, using N90 as an example, pseudo-callsigns have to be defined in order to show that a controller is combining sectors. We use NY_APP as a catchall (to differentiate from EWR_APP, LGA_APP, etc), even though that could actually be any number of permutations of different sector combinations. This results in confused or frustrated pilots who call up and are surprised to hear the airport they are at is not covered (because who reads controller info these days?). 

I was just wondering if this NAS server concept might allow a way to make this more straightforward, like where a controller can choose all of the positions they are covering and cross-couple the frequencies and the positions all show up as covered from the Pilot's POV. Or if this will still require a definition of pseudo-positions for combining.

Thoughts?

[Ross Carlson]

2 hours ago, Heath Abelson said:

I was just wondering if this NAS server concept might allow a way to make this more straightforward, like where a controller can choose all of the positions they are covering and cross-couple the frequencies and the positions all show up as covered from the Pilot's POV. Or if this will still require a definition of pseudo-positions for combining.

The NAS server concept would allow for that, but actually implementing that would require approval from the BoG. And there are very mixed opinions on whether or not that should even be done, because of the implications for controller workload, if you were to have to tell pilots to switch frequencies when they go from e.g. ground to local to departure to center.

[Alistair Thomson]

21 hours ago, Ross Carlson said:

implications for controller workload, if you were to have to tell pilots to switch frequencies when they go from e.g. ground to local

Is that not RW standard practice?

[Ross Carlson]

3 hours ago, Alistair Thomson said:

Is that not RW standard practice?

Yeah, in some real world cases a controller will be working two frequencies and they'll switch pilots from one to the other. However, the scope and scale on VATSIM is often quite different, in that you'll have a single controller covering all of what would be covered by numerous controllers in the real world.

[Heath Abelson]

On 5/10/2022 at 4:14 PM, Ross Carlson said:

The NAS server concept would allow for that, but actually implementing that would require approval from the BoG. And there are very mixed opinions on whether or not that should even be done, because of the implications for controller workload, if you were to have to tell pilots to switch frequencies when they go from e.g. ground to local to departure to center.

I am personally less concerned with the frequencies (I didn't really intend to imply that i would hand off pilots between my own frequencies), than I am making it more transparent\obvious to pilots what services are available. For instance, is NY_APP covering LGA right now? Is PCT_APP covering IAD? This is usually freeform info that controllers have to put in their controller info, that consequently pilots never seem to check any. During busy times it can really congest a frequency with pilots calling for clearance from an airport no one is covering. I was just wondering if there was any thought given to somehow using this new architecture to present that information to the pilot more succinctly.

[Ross Carlson]

46 minutes ago, Heath Abelson said:

I was just wondering if there was any thought given to somehow using this new architecture to present that information to the pilot more succinctly.

In order to show a list of airports that a given controller is covering, we'd need to make modifications to ATC clients and pilot clients. Implementing those modifications wouldn't be made any easier or harder by this new server architecture.

[Matisse VanWezer]

13 hours ago, Ross Carlson said:

In order to show a list of airports that a given controller is covering, we'd need to make modifications to ATC clients and pilot clients. Implementing those modifications wouldn't be made any easier or harder by this new server architecture.

What about a pilot's next (few) frequency(/ies)? I assume the server calculates them so it might be able to pass them along to the pilots as well? 

This doesn't show a list of airports the controller is covering but it does show the path of frequencies (including unicom) the aircraft will be passing through, which would also ease the problem Heath brought up. 

Edited May 13, 2022 at 07:13 AM by Matisse VanWezer
unicom

[Ross Carlson]

7 hours ago, Matisse VanWezer said:

I assume the server calculates them

It actually doesn't.

If we had a global database that included the 3D airspace volumes that each controller is covering, then pilot clients or tools like VAT-Spy could be enhanced to show the controller that you should call when you are predicted to enter their airspace. If you are already in controlled airspace, then it's up to the controller to tell you which frequency is next, of course.

Unfortunately, we don't have such a database, and creating one would be a very complicated job. The way airspace volumes are activated/deactivated when different controllers log on/off, plus the way some airspace volumes change shape depending on which runways are active at one or more airports, makes this a logistical mess.

This is done in the real world, but even there, at least in the US alone, it's messy and error-prone. The system often gets it wrong, requiring controller intervention.

We may get there some day, but I'm not holding my breath. This is something we've wanted for as long as I can remember, and it hasn't happened yet.

[Benjamin Koula]

Roos, Question here, since it is server side wouldn't that put a larger strain on users routers/internet usage. What would be the recommended networking setup because I myself don't have high speed internet only a modem with ~20 mbps. Also would it require AFV?