“Why monitor a path and not just the device?” It’s a great question that I routinely get asked when talking about our technology on demonstrations, and it just so happens that I had a good chance to conduct a little experiment outside of a normal work environment during my recent trip to our nation’s capital to attend Surge.
What does every business traveler do when they travel? Try and find the nearest Wi-Fi connection, whether it’s in the airport, on the plane, or at the hotel. I had a bunch of things to catch up on, so I installed one of our software sequencers on my laptop and set out for the road.
My departure point was Boston’s Logan airport (free Wi-Fi, BTW!) for my 5 PM flight. By the time I made it through security and opened my laptop I only had 15 minutes to capture network performance data before boarding. I pointed the sequencer to one of our hosted public targets in New York, and within a minute I was seeing the network’s bandwidth, data loss, latency, jitter and RTT. Data loss wasn’t terrible at 5%, but the round trip time was pretty high at 100ms. The bandwidth was a quite respectable 30mbps – but that was shared between myself and about 500 of my friends watching YouTube in the concourse. The real reason for my “slow” internet was the 29mbps of traffic saturating the wireless link.
What’s great about the sequencer technology is that the solution also presents the path my data takes, and all of its glorious details, regardless of who owns the infrastructure. It can provide that insight whether you use a public SaaS web application like Salesforce or a private network connecting remote users to a datacenter hosting your applications. If a bottleneck had prevented me from getting that last email out before I boarded, I’d know exactly which hop was to blame.
Soon it was time to board and see what happens at thirty thousand feet. Thanks to Go-Go Inflight Internet we can connect while up in the air, but can you get any work done over the connection? I found it to be adequate. Emails, chat and web applications were all working, albeit with some more delay than I was used to.
But what did the sequencer data say about why my applications “felt” slower? The in-flight wireless had much lower bandwidth at 1.5mbps, but the available capacity was actually pretty similar because utilization only ranged between .35mbps and 1.2mbps. Packet loss was higher than in the airport at around 10%, and the jitter peaked at 100ms, but those numbers aren’t awful either. The real culprit was the round trip time, which was anywhere from 500ms to a full second.
Only a couple of hops on this path, the first hop represent the gear on the aircraft. The second is the cell tower we happened to be closest to at the time I took this measurement, somewhere over Connecticut.
This was a quick flight, so I only captured about an hour of measurements between the time I powered my laptop back on and when I had to power off and stow it for landing. Still, I was able to capture a good sample size of the Go-Go Inflight service’s network data. All in all, it wasn’t too bad of an experience: I was able to catch up on my emails while generating a baseline understanding of what to expect from the service.
I finally landed, and it was off to the hotel. I was hoping for a better connection so I could catch up on Breaking Bad and Dexter (I mean, running reports and emailing). Unfortunately, it wasn’t quite what I was hoping for. There were a number of conventions at the hotel, most of them having something to do with technology, so I’m sure bandwidth was in high demand – but I never expected to see numbers like this. The data collected off of the wired connection in my room (and the wireless was far worse) showed just 1.7mbps of bandwidth with 1.3mbps of that utilized, as well as a full second of RTT.
Using our sequencer technology, I was able to run a diagnostic providing hop-by-hop statistics for loss, latency and jitter. Just as expected, the bottlenecks were caused by limited CPU response and high utilization at specific hops.
So, what’s the take away from my little experiment? A number of factors, like the number of connections or the type of data being streamed, can affect network experience. But while it’s “obvious” when a network feels slow, understanding the root cause is anything but without the right set of tools. Based on my experience taking a sequencer on the road, I can say that I would rather be stuck working on an airplane using Go-Go internet than at a hotel hosting a tech conference in Washington D.C. for the night! (Now if they would only let you stream videos over that connection…)