On the surface DSL seems like an awesome option. The advertised speeds for DSL of 1.5 to 6 mbps are much more impressive than the steady 1.54 mbps that T1 offers.

When looking at advertised speed, DSL seems like the obvious choice. However when we look a little deeper we can see that those speed numbers are a little misleading.

DSL circuits are oversubscribed, meaning DSL users share their connection with others around them. Imagine that you are given two different options for driving to work. The first option is a 4-lane highway, shared by all of the drivers in your community, with a maximum speed limit of 75 MPH. During peak traffic hours the 75 MPH highway has bumper-to-bumper traffic and numerous delays. Instead of traveling at 75 MPH the traffic moves along slowly at 10 to 15 MPH.

The second option is your own personal roadway with a speed limit of 55 MPH. This road is used by only one person, YOU. There is no traffic, there are no stop signs, and there are no traffic lights. It’s just you and the freedom to drive up to 55 MPH whenever you want. With your personal highway you no longer leave your house wondering how much traffic there will be and how much it will slow you down. Instead you can rest assured that anytime you drive you will always be able to drive 55 mph.

The 75 MPH highway is DSL. Though it is advertised as having fast speeds the occurrences where subscribers actually enjoy those advertised speeds are rare. Instead the speed is divided among all of the users in your neighborhood who share one DSL line.

T1 is the 55 MPH personal highway. The maximum speed potential is significantly lower than DSL but it is NOT shared. The 1.54 mbps of speed is ALL YOURS every time.

Every business is unique and the best broadband option for your business really depends on what you plan to use your broadband for. At broadband.com we offer both services and our product recommendations vary depending on the broadband needs of our customers. To get a better idea of which service is right for your business check out the DSL and T1 pages at broadband.com or try out our live chat option on the top of our homepage to get real-time assistance from one of our broadband experts.

First, let’s back up and take a tour of the map as it was. In a word: KML.

KML (Keyhole Markup Language) is XML with geolocation data elements added. If you’ve ever viewed points in Google Earth, you’ve probably seen KML at work. Google Maps natively supports loading KML and it turned out to be a pretty good option for mapping static points. Because Google is adding the markers to the map directly, a KML layer can have thousands of markers instead of hundreds.

To create the broadband map I wrote ruby scripts (rake tasks) that parsed our points data into five KML layers: central offices, lit buildings, EoC coverage, and two for DSL coverage. To handle DSL and EoC coverage — transparent circles centered on a central office — I generated KML files that specified circular polygons and styling. I parsed the central office data, checked to see if it was DSL or EoC, and then calculated 30 points in a circle around the central office to form the “circular” outline. KML allowed us to specify markers for the points and the coloring/alpha transparency for the polygons.

A typical central office point:

<Placemark>
  <name>Central Office</name>
  <description>1049 N 3RD ST</description>
  <styleUrl>#co</styleUrl>
  <Point>
    <coordinates>-99.73335,32.45157</coordinates>
  </Point>
</Placemark>

A typical DSL coverage area:

<Placemark>
  <styleUrl>#dsl</styleUrl>
  <Polygon>
    <outerBoundaryIs>
      <LinearRing>
        <coordinates>
-83.98093654387421,34.36732
-83.98223988881587,34.377583641421
-83.98610089352155,34.38739925343817
-83.99235158080776,34.39633761734606
-84.0007192406632,34.40400774531366
-84.01083826638533,34.41007402694737
-84.02226611564771,34.414270964430926
-84.0345027021283,34.416414840563384
-84.047012361531,34.41641179853356
-84.05924741293154,34.41426197152358
-84.07067225958019,34.41005947684825
-84.08078694721617,34.40398827489286
-84.08914912417283,34.39631407865723
-84.09539342448822,34.38737267628853
-84.09924741825832,34.377555188181574
-84.10054343536446,34.36729091466242
-84.0992257603099,34.35702853400504
-84.09535290688325,34.34721647931155
-84.08909490101796,34.338283354195156
-84.08072571817662,34.33061924065349
-84.07061122840484,34.324558709131544
-84.05919318972609,34.3203662631982
-84.04696999212386,34.31822484342311
-84.0344749848322,34.31822788188992
-84.02225331528727,34.32037524603256
-84.01083826639099,34.32457324438945
-84.00072809828428,34.33063869403101
-83.9923643811702,34.33830687658559
-83.98611274732286,34.347243043725804
-83.98224689468306,34.35705698027416
-83.98093654387421,34.36732
        </coordinates>
      </LinearRing>
    </outerBoundaryIs>
  </Polygon>
</Placemark>

KML worked out great, except for two things. First, it was slow. Turning on the DSL layer could take up to ten seconds to complete — an eternity in modern browsing! Second, our lit buildings’ data quickly ran up against Google’s size and complexity limits for KML data. We had to split our DSL coverage into two layers because of the size limits. To fully bring up all 300,000 lit buildings would’ve required over ten KML layers to be loaded in sequence. At that point we’d be talking over a minute to load the points.

Last week I was determined to get a solution. At first I thought that network linked KML files would be the key. After all, the Google Maps documentation said it was the way to go if you needed to render a large number of points. The idea here is to have a bunch of KML files split out by region and Google Maps will only load the files that are needed. Parsing our existing KML files into regions was a bit tricky and I never came up with a good solution. The files I generated would work just fine in Google Earth, but I never got them to load correctly in Google Maps. I suspect that I was running into the Google Maps limit of no more than ten network links per KML file.

My research led me back to Google Fusion Tables. Fusion Tables have always been labeled “experimental” in the maps documentation, but faced with slow load times, too many points, and recalcitrant XML I figured it was worth a shot. In a word: Wow! If you’ve seen the broadband map lately, then you can see the kind of speed this change has brought. Points now load so quickly that they seem as if they are native map features. We are completely pleased with their result.

Google Fusion Tables are essentially spreadsheets on the web, but spreadsheets that have a direct connection to Google Maps and that can natively import KML files — even KML files that define polygons. For our purposes they’re essentially fast hosting for our KML and that’s perfect! But it gets even better. With Fusion Tables we’re able to change the marker styling with the click of a mouse in the browser, change info window text directly, load different columns of data, completely control the coloring of the layer polygons, and get access to a bunch of really nifty map features that are simply unavailable to standard points. Most of that was possible before, but required recompiling the KML and uploading the file.

Michael Byrne, the Geographic Information Officer at the FCC pointed out how we are using the FCC API on the FCC’s blog. He was pretty excited to see how quickly we had utilized the data in our application.

Here is the FCC blog post link: http://reboot.fcc.gov/blog?entryId=1356068

• http://arstechnica.com/tech-policy/news/2011/03/cable-backed-anti-muni-broadband-bill-advances-in-north-carolina.ars
• http://www.geekosystem.com/broadband-h129/
• http://www.wgnc.net/index.php?option=com_content&view=article&id=9375

Bottom cities by Value

Let’s take a closer look at the data and how we calculate out that value.

Value is simply defined as cost / speed. The North Carolina cities that made the list have poor upload speed, paired with relatively high Internet prices. Upload and download speeds factor equally in our calculations.

Our lists at broadband.com are calculated using last months data (currently February 2011) from NetIndex by Ookla and aggregate Internet speedtest results.

We determine value as the cost of the Internet connection divided by its aggregate speed.

NetIndex gives us upload and download speeds per city per day as well as the number of speedtests.

Our Calculation

1. We multiply the number of tests times the value.
2. We sum that up for the month.
3. We divide that back out by the number of tests in the month. That gives us an average value for both upload and download speed per city for the month. To get a single average speed for a city we just average upload and download speed. (As noted, this is where NC cities start to look bad.)

http://gigaom.com/broadband/bandwidth-com-launches-a-better-broadband-map/

http://www.readwriteweb.com/biz/2011/03/building-a-better-broadband-ma.php

What is Broadband.com
Broadband.com is more than a website, it’s a platform to present ISP prices, Internet access options and availability based on address searches in an Expedia.com style. Additionally, broadband.com will display real-world ISP performance stats. Bringing together real-time ISP prices and real-world ISP performance metrics to a free public website is a first. It’s a big project and this is the first step.

With the launch of the site, Broadband.com is the new Internet Services brand of Bandwidth.com.

Broadband.com is a free resource
Broadband.com is a free resource to help bring transparency to Telecom. Are you paying too much for your Internet? Is your existing ISP the best option? Are you getting the speed and bandwidth you are paying for? These questions and many more we hope the Broadband.com platform can answer – and answer in real-time.

What is Next?
Over the coming weeks, we have a lot to do. We plan on adding 4G and wireless coverage, improve our DSL mapping, and roll out our pricing alert system.

We welcome your feedback and hope you find this tool helpful.