Re: And now for the rest of us who use AT&T... TWC comes within a mile of my road, but, they won't service my road because the telephone poles don't follow the road. And, they're notorious in our area - they skip homes because they're too far away (anything over 100' and they immediately say $12,000-17,000 to bring service to the house!). So, in my mind, this is probably why AT&T doesn't give a crap about upgrading service for people in my area - because they know there's no real competition.
That leaves me confused about your area. Comcast, from what I've seen, has been offering amazing speeds (50mb+), so I'd expect AT&T would want to invest in U-Verse or bonded DSL. Competition is a good thing, IMO.
The flip side to this... ... is an ISP can under promise and over deliver. e.g. ViaSat
As with all rankings.... your milage may vary
In our testing, we found that during peak periods 90 percent of ViaSat consumers received 140 percent or better of the advertised speed of 12 Mbps.
"Too often we... enjoy the comfort of opinion without the discomfort of thought." - John F. Kennedy
"Insults are the arguments employed by those who are in the wrong." - Jean-Jacques Rousseau
What should the "advertised throughput" be? AT&T and other telcos are technically correct when they're advertising DSL circuits for a certain speed. They provision that circuit for that speed (if you can't train at that speed, that's a separate issue to sort out). The circuit is capable of transferring that many bits per second.
Speed tests, at least the ones I've seen, are only measuring goodput - that is, the number of bytes received at the application layer. But overhead is present. On a per-packet level (ignoring anything lower than L3):
- Ethernet frame header is 14 bytes. (This overhead _is_ present on PTM-based circuits, i.e. VDSL/VDSL2. Actually, ATM is an option even on VDSL but I've never heard of any provider using it over PTM. On older ATM-based circuits, there's even more overhead from ATM & AAL5 headers and cell padding on the last cell.)
- PPPoE header is 8 bytes. (No idea if AT&T still uses it but many other DSL providers do. It needs to go; these VDSL DSLAMs are all Ethernet backhauled so they should just configure each logical port to its own VLAN and use DHCP for IP assignment.)
- IPv4 header is 20 bytes. (This isn't completely accurate as it's possible to specify options in the header, but that isn't the typical case, and IIRC isn't even reliable over the Internet as many routers will just drop packets containing them.)
- TCP header is 20 bytes. (We're talking about speed tests here, which are all going to be done over TCP, so we'll ignore any other L4 protocols.)
- Application layer may have its own overhead. For file downloads over HTTP it's minimal (only if you want to count the HTTP headers, which are per-request and not per-packet).
- Should probably note that there's overhead from lower layers too, but that's minimal and also variable. G.998 bonding adds another 2 bytes for each data fragment as well.
The point I'm trying to make, is that the overhead will is variable, not just based on packet size (smaller packets = higher percentage of overhead), and they really aren't falsely advertising anything.
Perhaps a case can be made that you should be capable of achieving at least the advertised throughput in "normal conditions," which could be considered a single TCP flow sending/receiving maximum-size packets (generally 1500b MTU over the Internet, or 1492b if they're using PPPoE and not supporting RFC4638)? I'm not going to argue for or against that, but to call it false advertising is a stretch.