An Alternate to the FCC Maps

I’ve written a lot of blogs about FCC broadband mapping. It’s been easy to criticize the maps since they are still full of errors and fantasy. I don’t foresee the maps getting any better as long as ISPs can continue to decide what they want to report in terms of broadband coverage and speeds. Too many ISPs have reasons for reporting maps they know are inaccurate, and it’s hard to think that’s going to change.

Perhaps having accurate maps doesn’t matter all that much. If BEAD comes somewhat close to solving the rural broadband gap, the FCC maps will quickly lose relevance. The FCC is always going to need some version of the maps to report to Congress each year on the state of broadband. But when the maps stop being a tool for deciding who gets grant funding, most local and state governments will stop caring about the maps – and nobody is going to much care what ISPs report to the FCC. Truth or fantasy won’t really matter, just like nobody cared about the maps just five years ago.

But I still think the FCC owes it to the public to provide a way to judge and compare the local ISPs. I’ve thought of a simple FCC tool that can accomplish that.

I think the FCC should buy the entire Ookla speed test database every month and make it available to the public in a portal where folks can see the speed tests actually reported for the ISPs working in their neighborhood. If a speed test comparison portal is made easy to use, it would be one of the best gifts the FCC can give the public. The FCC spent a huge amount of money developing the new broadband mapping system, and after all of that money, the maps are largely useless for the general public.

I will be the first to say that speed tests aren’t perfect. There are slow speed tests recorded for every ISP for reasons out of the control of the ISP. The biggest reason is WiFi routers that don’t deliver the speed to a computer that is delivered to the home. But the generic flaws of speed tests apply across the board to every broadband technology, meaning that speed tests are a great tool for comparing specific ISPs or technology.

Consider the following chart that represents Ookla speed tests taken in a suburban county over the last year. These results reflect over a million speed tests. The speeds shown for each technology are the overall average of all speed tests for each technology.

Download

Upload

DSL

37

7

Fiber

357

357

Cable

264

24

FWA Wireless

99

16

Fixed Wireless

12

7

Satellite

69

8

These results are similar to what I see in a lot of counties. There are some counties where DSL isn’t as fast as in this county. There are counties where fixed wireless ISPs perform much better than in this particular county. This is the only county where I’ve seen fiber have an identical average upload and download speed. But the overall performance of the various technologies is pretty typical.

These speed test results tests tell a great story about the local differences between technologies. This is information that is not readily available to the public. The FCC has ordered ISPs to create broadband labels – but those labels allow ISPs to report marketing speeds and will be no more useful to the public than the broadband maps. An FCC-sponsored speed test portal would allow the public to see how various ISPs perform in and around their neighborhood.

Detailed speed test results also can tell us a lot about any given ISP. It’s interesting to look at the fastest speed tests delivered for a given ISP. When I look at fiber based ISPs there are invariably some speed tests that are near the gigabit speed claimed by the ISPs in the FCC map. But the same is not always true for cable companies. I find some cable companies that are also delivering the top speed claimed in the FCC mapping. But it’s not unusual to find markets where a cable company claims gigabit speeds but doesn’t have any speed tests faster than 600 – 700 Mbps. That is still blazingly fast, but that is not a gigabit network.

Making the Ookla data available to everybody would be a huge public service. Local politicians always tell me that they have no way to judge the ISPs in their community, and this would give them a tool to do so. When used on a smaller scale, speed tests can also be used to show that some neighborhoods get faster broadband than others from the same ISP. As I wrote in a recent blog, folks can use speed tests to see that broadband speed on FWA cellular broadband die quickly as the distance between a cell tower and customers increases. This information would let the public understand broadband in a way that has never been understood before. Speed test data, when used in mass, will expose ISPs that exaggerate their speeds – and highlight ISPs that are honest.

So, FCC keep your maps for reporting to Congress, but please give the public this readily available tool so that everybody can get usable facts about broadband. ISPs that exaggerate their speeds will hate this idea – but honest ISPs will welcome it.

4 thoughts on “An Alternate to the FCC Maps

    • I agree that the maps suck, but I don’t agree the customer wifi device speed tests are valid tests, they are traffic generators for sure, but too much in the way of being a valid ISP test. I’d be much more convinced if they were from wired devices that reported the CPU and system utilization in the test.

      I’ve pitched an alternative alternative for a while now. A standard reporting format that router vendors can add that tracks peak use and typical latency that speed test vendors can incorporate. These are things they can already do, they just need a small update to package that data into a standard format. Vendors could be enticed to add these features because if they aren’t there, the testing will show that they dont have a compatible router and/or they might not be eligible for ACP or if they have a complaint it’ll be reported with the flat ‘unsupported router’ or something. For things like ACP, anyone applying for ACP could be required to have an enhanced service reporting router.

      When a customer runs a speed test, the router can report the instantaneous peak it sees on it’s WAN side, WAN port speed, and include the tracked data so you can get an instantaneous and a 24 hour peaks in 1 hour increments or whatever to the speed test server as well as some basics about the router itself. Then the speed test has enough information to present to the user. By ‘report’ I mean extract the session ID and reply URL from a unencrypted packet sent in the speed test and when the test is done, send those stats up. As part of the test, you could additionally run a routerprovider test that is part of that ‘testing session’.

      Further, ANY device in the chain could do this. If an ISPs gear were updated, it could also grab that test session id and report up and/or could report to the ISP. GPON vendors might put the test in their ONU and report to their reporting server.

      Something like Ookla’s output, but broken down into instantaneous from the router, and from the device. That would allow the Speed test service itself to report that WiFi is or is not the problem where the test was taken, or that the router has other data flowing as well. You could potentially go so far as reporting wifi signal levels and modulation if you wanted. That old netgear could be identified and again, the speed test server could show that and say “other users with this router are reporting typical peak speeds of x”

      I think this model sort of fills all the use cases. It gives practical peaks with buffer bloat information for a period of time, the instantaneous performance while running the ‘speed test’ traffic generator from the WAN port mostly eliminating wifi as the limitation, could report drops on ports compared to received data, router limitations are addressed, reporting to the interactive test but potentially also to the ISP and to the FCC for ACP or similar program.

      It keeps everyone honest. The ISP who is the primary target of the tests. The home user that has bad WiFi is going to get shown that. The underpowered device or router is going to show.

      It’s also not describing the actual test, so not forcing all speed test vendors to be the same, just that the router can post results it is seeing to them. ANY test would be ‘compatible’ if they send that data for the router to intercept.

      and since the vast majority of consumer routers are based on openwrt or linux, this is almost trivial to implement.

      anyway, thoughts.

Leave a Reply