Thank you for listing some of your observations. Last night's event was a bit of an experiment from the controllers' perspective. For the past 2-3 events, we've had a lower turnout than usual (around 20 pilots), and I assumed with the KBOS-KBTV run last night, we'd have the same scenario. As a result, we had a lot of newer controllers online. Boston Clearance and Ground were working together for the first time, BTV_G was a brand new controller, and BTV_A was controlling his first Regional Circuit as Approach (I think). Our very capable ZBW_C had only controlled that position once before (but Center is an event is drastically different than on a regular night, because normally there won't be any aircraft flying to non-staffed fields during events). Even though each of our students was being listened to by a mentor, the pilots came out in full force and may have overwhelmed some of us. My normal rule is that we do not train during events. I thought I could break it, and we weren't going to be too busy. I was wrong.
The pilots came out in full force last night, and you guys may have even scared off a few of our controllers (technical issues with a microphone may have contributed to that a little bit as well). That being said, let me answer a few of your specific points, because I believe they are not systemic errors (i.e. problems with the way we train or the procedures we follow) but rather specific examples of deviation from the norm.
This is the real-world procedure for KBOS. Because most gates at the airport require aircraft to either pushback onto Taxiway "A" or into a small ramp area, the FAA allows Boston Ground controllers to act as a pseudo-ramp control and actually authorize almost all pushbacks (with the exception of the Delta company ramp, as well as the Signature/North GA/Cargo ramps, which have their own controllers). In order to avoid overwhelming the one Boston Ground controller, the real-world procedure at KBOS is for Clearance Delivery to tell aircraft to "monitor ground .9" when the are ready to pushback. If you listen to LiveATC, you'll hear it| you'll also hear Boston Ground issuing pushback instructions without having been called by the pilot. You can review the KBOS SOP on our Air Traffic Control page if you want to see BVA's official policy.
Our controllers are trained to the real-world standard, and that's what SHOULD have happened. You probably fell through the cracks... someone forgot to edit the "Remarks" section of your flight progress strip and ground never got the message to instruct you to push. Actually, when I heard you call ground and ask him why you weren't contacted, I believe I spoke with both Ground and Clearance Delivery to try to figure out what happened.
Despite being a "Pilot Tip of the Month" in a recent Logan Informer, several pilots still contact when they should monitor (last night on BTV_T, a few people called me when they should have just been monitoring... that contributed to the chaos that ensured when I had to quickly step up to BTV_A). That's probably why everyone else was calling instead of waiting for Ground to call them for push. As it turns out, they should not have done so. In other words, in this scenario, the correct, real-world procedure was delivered incorrectly by the controllers online last night.
By the way, the correct procedure to follow (or at least, what I've heard real pilots do when it's busy) if you are instructed to monitor a frequency but receive no response is to go back to the previous frequency (on COM2 so you can hear if the controller you are monitoring does call you) to check with that previous controller. For example, in your case last night, you would have gone back to BOS_Cl, asked whether Ground knew you were ready to push, and the controllers would have sorted you out. What you did was totally fine as well because, at the time, BOS_G's frequency wasn't too congested.
I WISH, I WISH, I WISH we knew what caused the glitching and what we could do to fix it. But I haven't found a solution just yet. It doesn't seem to happen more or less when it's busy, seems to affect some people but not others (and yet not be related to internet), can sometimes be corrected by temporarily pausing a session, but is (almost) always solved when another member leaves the session. In my opinion, what happens in a 'glitch' scenario is that the server stops sending out updates to the glitched aircraft's movement (either because of a bug on the server, or because for some reason the glitched client has stopped sending out this information... my money is on the server, explanation coming below). Thus, the glitched aircraft continues to do exactly what it was doing when these updates stopped. For example, if you are flying on heading 350 and climbing at 2,000' per minute when a glitch starts, you won't turn or change your rate of climb. I've seen people well over 1 million feet. Strangely, it seems some glitches only affect controllers -- other pilots see the aircraft fine while controllers do not -- and sometimes a plane will be glitched for everyone.
When the glitch is resolved -- again, normally when a player leaves the session, but sometimes if the glitched player pauses -- the server starts once again sending out updates to the client. They jump back into position on our radar screen and continue as normal after. During a glitch scenario, however, the server never loses the aircraft. Check BVATC Live! -- that map is fed directly from the server, as are FlightDesk's tracking updates if FSX is closed. The tracking updates and live map show the aircraft correctly, but other FSX clients do not. That's why I think it's a server bug that causes the server to stop sending out the glitched pilot's updates, and not an issue on the client side. In other words, the data are getting through to the server, but aren't coming out the other end. Again, if we knew why, we might have a solution.
That explains what a glitch IS. Since we can't say what causes it, it's difficult to place the blame on FlightDesk, easy or helpful as that may be. Furthermore, I understand that Bill has carefully designed and re-designed FlightDesk so as to take up very little bandwidth and CPU usage. He describes himself as a performance freak, and every letter of code he writes is influenced by keeping performance impacts minimal. I've seen glitches happen for AGES, starting before BVA even used FlightDesk. If it's any consolation, they seem to happen to a small group of people consistently but then stop and never come back. A few months ago, controllers would tell me that I'm glitched almost every session. I haven't heard it for a little while now.
I wish I could tell you what to do when it happens, or how to avoid it. While restarting your router, re-installing FSX (and in fact the entire OS) from time-to-time, and making sure to run FSX in multiplayer mode such that it's not maxing out your CPU are going to help things anyway, there's no evidence to support the theory that you can resolve or stop glitches from happening by doing any of those things. One thing I have noticed is a considerably better connection to the server -- better voice, smaller chance of getting disconnected randomly -- when settings are not maxed out. There are some members that control for long periods of time but are disconnected after only short flights. I wonder if their settings and CPU usage is dramatically different when they are controlling vs. flying. I know I always tune down my visual settings when I'm doing ATC and the scenery/frames don't matter. I also lock my frames at the lowest possible level when controlling.
So what is this glitch crap? I wish we knew, and I wish we had a solution. Since we don't, our controllers try to handle it as best we can, but it can be difficult and frustrating to deal with sometimes.
Actually, we do have an informal procedure that controllers should use. In my case, I'll look at the BVATC Live! map right away. Since glitches never manifest themselves there, you can get basic information about the pilot's heading and altitude. Of course, it's impossible to vector someone for an approach using the map, but it's very possible to keep that aircraft separated from others using it. Normally, glitches resolve themselves before I need to start vectoring for an approach, but when they don't, I'll use the live map to maintain separation while I vector someone for delay, or even put them into a holding pattern (like I did to UAL340 last night, the only glitch I saw during the entire Rc).
In the case of ZBW, perhaps he was looking at you on BVATC Live! or in FlightDesk, and thus didn't need the position reports. Perhaps BOS_A was not looking at those tools, or just preferred to have you report a waypoint because he was less busy.
In every case, controllers hate the fact that glitches happen. Imagine looking at a radar target thinking you have plenty of time to turn/descend someone and then the aircraft suddenly jumps 40 miles and 8000'. Or to issue someone a climb but see them descending 5,000' below the ground. It's difficult to handle. It's worse when you have a no-radar scenario with an aircraft you need to vector to final. Recognizing that glitches are as confusing and frustrating for pilots as controllers, we try to avoid mentioning them as much as possible, and do our best to work with the pilots and provide them the ATC services they need without interruption. Nobody wants to be stuck on the ground holding short of a runway in FS because controllers can't see where they are.
Sometimes, if you un-glitch right when you change to a new frequency (or if the previous controller is too busy to alert the next of a potential glitch), we won't remember or know to tell you that you are back on the screen. Normally I will "radar contact" someone a second time if they were previously glitched, but it's the last thing on our minds when it's busy. Normally, we're just thrilled we can see where you are again.
The controller on BTV_A last night was (I think) controlling Approach for (one of the) first times during an event. I was going to try to listen in and help, but, as I said, I wasn't expecting him to be as busy as he was. Between the terrain restrictions, a small sector, and the traffic, BTV_A was a difficult position for anyone (even me, as I quickly found out when I had to take over roughly halfway through the event). For some reason -- I'm assuming a technical problem -- our BTV_A was unable to respond to pilots, and I had to take over and clean up the resulting mess. I ask you to give Josh (BWIA) the benefit of the doubt that there was something he couldn't deal with, and support his attempts to continue to control in the future. I will be working with him at the next chance I get to figure out what went wrong, and how we can prevent it in the future.
I hope that helps, and thank you again for your comments. In most cases, I think we're dealing here with deviations from the standard rather than standardized deviations from what you might expect, perhaps excepting the glitch scenario, which isn't something you can deal with realistically at all. If you (or anyone else) has suggestions or comments as to how we can improve the standard procedures we follow, I would be glad to discuss them with you. Without the experience of actually controlling, and understanding how frustrating it is when glitch scenarios occur, it's difficult to understand the operational restrictions on some ideas... which is why discussing them with a base of controllers that experience that almost daily is an important step to finding a solution.
Thanks again for flying -- and discussing -- last night's event. We'll be going down to Florida for KMCO & KMIA on Tuesday. I'll do my best to staff it with a more experienced crew... you (pilots) see if you can overwhelm us again!
