The REAL Reason Airplane Wifi is Slow
by Christine Cignoli on

Depending on your travel agenda, a cross-country flight can be an opportunity to work offline without the usual real-time distractions or catch up on the latest episode of Silicon Valley. With in-flight wireless like Gogo becoming widely available, you may be tempted to keep in touch with colleagues from 35,000 feet, or post to facebook because you can.

While connectivity is better than no connectivity, using inflight WiFi can be a productivity killer. When you connect to Gogo’s in-flight wireless service, you’ll be sharing a low-bandwidth pipe with dozens of other travellers. While you can sign up for a day or month unlimited pass, you’ll probably try to take the least expensive option and get a couple of hours. At $20+ for a short bandwidth drink you’ll have the urge to squeeze every last minute of IP connectivity to get your money’s worth.

During a recent BOS-SFO flight on Virgin America, I took advantage of Gogo’s service and used PathView’s OSX client to non-invasively analyze the performance between my laptop and a fixed AppNeta monitoring target. PathView isn’t limited by TCP considerations like latency and loss, so the location of our aircraft relative to the target doesn’t impact capacity measurements. PathView tracks bandwidth, latency, loss, jitter, and other KPIs at per-minute intervals, so we get insight into the variable nature of any link. Here’s what PathView tells us about Gogo’s performance:


It’s a small pipe.

You’ll be sharing 1.5Mbps of download capacity and 300kbps of upload capacity with your soaring peers and all of their bandwidth-hungry apps.

It’s a leaky pipe.

Packet loss is significant, approaching 40% in several instances. That means 4 in 10 packets transmitted never reaches its destination. On the bright side if you’re apps use TCP like most non-realtime apps do, your lost packets will be retransmitted. The app should still work, but the effect on user experience is horrible. Even simple page loads will seem sluggish, and congestion on the network due to retransmitted data will further decrease performance for all. Not good.

It’s a long pipe.

While some packets (see one way latency) could reach our Rochester, NY test target in 100 milliseconds, the average round trip approached 1.5 seconds numerous times in our 90 minute sample, and average RTT hovered around a second. If you’re using a browser-based application, you’ll experience multiple delays while page assets are transmitted to your system and the acknowledgements return to the sending server.

Don’t try any online gaming, as 100ms is often a ‘worst-case’ RTT value with many other gamers enjoying 20-30ms. Expect lots of gibs (yours).

Conclusion & How to Survive

Either packet loss at 40% or RTT over a second will seriously degrade the user experience of any connected application. Experience both and you better get used to seeing a ‘loading..please wait’ message in your browser.

I found it helped to open multiple browser tabs and load pages in parallel. Better yet, stay offline and catch up on reading or your favorite show. Just don’t try streaming it if we’re on the same flight.

Filed Under: Networking Technology, Performance Monitoring

Tags: features , network speed , NPM , packets , PathView