Cablevision Fares Much Better in Latest FCC Data
Company Took FCC Report to Heart
Roughly four months ago the FCC issued the results
of a significant study that involved using customer firmware-embedded routers in users homes to measure ISP broadband service quality. While several companies (Comcast, Verizon FiOS) delivered more than what they advertised, a number of companies were singled out at being particularly bad at delivering peak broadband speeds. Windstream, Mediacom, AT&T. Qwest (now CenturyLink) were notablle poor performers but Cablevision was cited as particularly bad -- offering advertised speeds just 50% of the time during peak usage hours.
After taking a bit of a press beating for the results, we noticed that Cablevision very quickly started making some quiet network enhancements
. While not officially announced, those enhancements involved quietly nudging tiers like their 15 Mbps offering to 20 Mbps. Not too surprisingly, four months later and a newer FCC study now shows that Cablevision is delivering 90% of the speeds advertised during peak hours. A post over at the FCC blog points out the improvements
We are pleased to note that the performance of one company—Cablevision—markedly improved from earlier this year. As we noted in our report, during March 2011, subscribers to Cablevision’s 15 Mbps service were receiving average download speeds during peak hours of only about 50% of the advertised speed. By comparison, average users across all companies other than Cablevision were receiving download speeds during peak hours of 89% of the advertised speeds. During October 2011, the most recent month for which data is available, subscribers to Cablevision’s 15 Mbps service were receiving average download speeds during peaks hours at over 90% of the advertised speed.
Cablevision likely found the FCC's report particularly disadvantageous in their NY metro area marketing fight against Verizon FiOS, which has long over-delivered advertised speeds in order to re-enforce the perception of a high-end product. The FCC isn't yet releasing the full report, so it's not clear if other sub-par performers have also made some changes. Frontier Communications was another particularly poor performer in the FCC's last study, delivering advertised speeds just 67% of the time during peak usage hours.
Re: I'll never switch back
said by Zores:How is $69 for tripple play not affordable? They have been offering people $69 and $79 tripple play deals.
Still not better than the 35/35 which is actually 43/35 i get from fios. I used to be a OOL customer for a long time but they've done nothing to make their speeds 100%+ like I get from fios. So if they can't do that just slash prices to make it affordable, what? they can't oh well then.
Re: I'll never switch back
said by MxxCon:$0 here (because Fios is not available)
vz's promos end too. how much does fios tripleplay cost w/o any discounts?
Re: Not much increase here... The measurements may or may not refer to the same thing. There are 8-bits to a byte and on the surface, simple math converts between two expressions. (A KB is 1,024 8-bit bytes per second. A MB is 1,048,576 8-bit bytes per second.)
However, you can only convert between the two with confidence if you understand what's being measured. Browsers and P2P programs are likely reporting "user data" transferred, not raw data transferred. Depending on the application protocol, there may be application-level overhead that reduces the quantity of "user data" transferred because a portion of the data is used by the application to control the transfer. I'm calling it "user data" because application protocols may encode source data in such a manner as to inflate its size. For instance, e-mail attachments and XML documents often use Base64 or MIME encoding to represent binary data. This can add up to 30% to the size of the data that needs to be transferred. If you have a 10Mbps connection that sends MIME data at full speed, 30% of the transfer speed could be used by the application's encoding. This reduces the effective transfer rate. That is, 10Mbps of data is being transferred but if 30% of it is used by the application to recreate the source data, the "user data transfer speed" (i.e. KB/sec or MB/sec) is significantly less than the raw transfer speed.
If you want to read why MIME/Base64 encoding is used, see this Wikipedia primer:
If you've wrapped your head around that, it's gets even muddier but the concepts are the same. Below the top-level application protocol is the network protocol. Commonly, TCP/IP is used which divides the data into packets and each packet contains a header. The header contains source and destination IP addresses, source and destination ports, packet sequence number, checksum and other "control data". This is underneath or below the MIME application encoding above and it also reduces the size of the "user data" that can be transferred.
Re: Not much increase here...
said by rradina:I understand what you're saying, but in most cases, the speed reported by my client software is higher, often significantly, than the speed reported by speed tests. The Speakeasy test is still showing me 15-20mbps, even though I just got done downloading a file that peaked at 4.2MB/s and was around 3MB/s for much of the transfer.
Browsers and P2P programs are likely reporting "user data" transferred, not raw data transferred. Depending on the application protocol, there may be application-level overhead that reduces the quantity of "user data" transferred because a portion of the data is used by the application to control the transfer.
Personally, I'd rather have the ISP tell me that I can expect speeds of 2-4MB/s rather than saying I'll be getting 20-30mbps.
Re: Not much increase here...
said by rradina:Typically, the further away the test site is, the worse the speed.
The difference you see could be related to the SpeedTest site vs. the download site. Your ISP could have a better route to the download site vs. the SpeedTest site. Try using a different SpeedTest site -- even if it's a bit further away -- to see if the results are more consistent.
Re: Not much increase here... True but as always, it depends. Even large markets with multiple premier backbone providers can have interesting routes. If two backbone providers don't share traffic until they get to a major hub (i.e. Chicago, NYC, WDC, etc.), a speedtest site in your hometown may require packets to leave town, go hundreds of miles away, cross over and return hundreds of miles. When this happens, it's far better to choose the speed test site at the major hub than the site next door.
As an example, the speed test site in St. Louis (where I am) stinks. It's better for me to use sites in Chicago, Dallas or Kansas City because Charter has direct routes to those cities. However, the local speed test site has traffic going to Chicago and back. (Download something like Ping Plotter and watch where the packets travel.)
Speed test sites are also not created equal. I've tried to use the speed test site in St. Louis from a lot of provider networks in town and I've never had great results.