TDS customers can trust that the network and services offered to them are being built by a team of incredibly talented folks. A group of those folks held their own alongside industry leaders during a recent internet speed test hackathon.
When CableLabs, the famous not-for-profit research and development group, invited members of the TDS IT team to join their hackathon, the team couldn’t refuse. Fortunately, there was a crack team already identified who could head to Princeton University for the event—the winners from TDS’s own recent hackathon.
Phil C., Zach L., Eric R. and Brian S. rolled up their shirt sleeves, grabbed their computers, and collaborated with leaders from both industry and academia for a day and a half.
The goal? To help develop an open source internet speed test.
“There’s a lot of concern in the industry—including Comcast, who started this project—about the costs and accuracy of speed test tools,” says Phil, a lead software engineer. “The idea is to create a tool to better measure speeds and make it the new industry standard.”
The trouble with speed tests is, the new 1Gig (and higher) internet speeds don’t test properly on any existing test tools. Speed tests also are highly impacted by which server is “pinged” (sometimes not the closest one). Finally, there’s the bufferbloat problem (see below).
Comcast’s idea, championed by CableLabs, is to develop an open-source speed test that would be both more accurate and available for all internet service providers (ISPs) to use—for free.
The team worked on one part of making a new speed test more accurate: identifying the closest/best server to run a speed test on based on the customer’s location.
Nate Dawson, director of IT Architecture & Planning at TDS, spearheaded sending the team to this hackathon. Nate emphasizes the importance of TDS contributing to the development of open source software.
Nate says, “The top tech teams in the industry contribute to open source software. This shows that TDS is in that league.” To illustrate that point, Nate said, “We were writing code along side of software luminaries from Comcast, MIT, and Princeton,” said Dawson, “and TDS held our own!”
“Speed tests are a real measure of our customer’s experience with our product, says Leslie Hearn, CIO and vice president of Information Technology at TDS. “I think this experience is a good demonstration of the strength of our software developers to solve important business problems with state-of-the-art approaches.
With the team’s proof of concept submitted after an intense event at Princeton, would the team do it again? The answer from all was a resounding, “Yes.”
WHAT IS BUFFERBLOAT?
If you’ve ever seen the “I Love Lucy” episode where Lucy and Ethel get jobs wrapping candies at a factory, you can probably understand bufferbloat.
Lucy and Ethel start out wrapping candies on the assembly line just fine, but quickly lose control and can’t keep up. They try to buy themselves some time by stashing some unwrapped candies in their hats and shirts, and wrapping others. This works for a while, but eventually they run out of places to put unwrapped candies. Had Lucy and Ethel kept going and filled buckets and buckets with unwrapped candies, those treats would have gone bad before they finally got wrapped and delivered.
This is what happens on the Internet. Buffers are designed to help store data that momentarily got away, but they’re storing so much, it’s just delaying data from getting to where it needs to go—sometimes arriving so late, no one wants it. This is bufferbloat.
The term bufferbloat was coined by Jim Gettys, an MIT-trained programmer, who works at Google and is a consultant (who was at the hackathon).