Constantine A. Murenin
Posts tagged ‘FTTH’
AT&T U-verse on BroadbandMap.Gov.

We’ve all heard that the fcc.gov et al has spent 350 million USD on the National Broadband Map. Has anyone actually bothered to visit it recently?

http://www.broadbandmap.gov/about-provider/at&t-inc./nationwide/ — T
http://www.broadbandmap.gov/about-provider/verizon-communications-inc./nationwide/ — VZ
http://www.broadbandmap.gov/about-provider/surewest-communications/nationwide/ — SureWest in Sacramento, CA
http://www.broadbandmap.gov/about-provider/cincinnati-bell-inc./nationwide/ — Cincinnati Bell in Ohio

I’ve looked at it repeatedly just now, and I have no idea what those numbers are, or how they could be useful to anyone who is interested in broadband. Keep in mind, I’m an engineer, fascinated with math and numbers. I have no idea what a regular person would be doing with any of those numbers. Numbers by each provider simply make no sense. SureWest has all zero-dot-something percentages, so does Cincinnati Bell. I found no option on the site to get the numbers to make any kind of sense. Was BroadbandMap.Gov simply designed to be the map of AT&T and Verizon coverage?

Yet, apparently, according to the map, even AT&T doesn’t offer FTTP to anyone! If you’ve heard people discussing their FTTP, they must simply be confused by the marketing, AT&T doesn’t actually offer, as BroadbandMap.gov unambiguously puts it, “Optical Carrier - Fiber to the End User”. Also, Sonic.net and Paxio.net are myths, they don’t exist, and don’t offer anything to anyone, let alone any Gigabit speeds for mere pennies on the Mbps! So is Webpass.net, they don’t offer 200/200 speeds for 45$/month in San Francisco Bay Area, either.

Also, apparently, AT&T doesn’t even use VDSL2. Note that VDSL2 is not “Asymmetric xDSL” technology; VDSL2 is symmetric and capable of 100/100 speeds at 0.5km loop lengths. Surprise, surprise!

Another note is that AT&T does offer 6Mbps upload speeds… Hmm… Note that there’s a single page for wired and wireless divisions… Yeap, you’ve guessed it — 6Mbps uploads is the artefact of the wireless networks. :-) No 6Mbps upload luck for any U-verse users!

Written for, and discussion at, http://www.dslreports.com/forum/r26762551-AT-T-U-verse-on-BroadbandMap.Gov.


Any consumer routers that can do routing? Or, the router that isn’t.

I’m looking for a robust consumer router that can do the simplest routing function of all — simply forward packets between the WAN and LAN interfaces. The option of NAT’ing the RFC 1918 addresses would be awesome, too.

Spoiler alert: after several very long conversations with ZyXEL NA tech support (including the managers; by the way, ZyXEL’s tech support is outsourced to Anaheim, CA), I was told that noone makes such devices for the consumer market at all. Is that really true?

I have a 99.124.xxx.xxx/27 Static IP address allocation from AT&T U-verse FTTP; however, the way it worked with 2Wire is that you still get a single regular “dynamic” IP address via DHCP from their common and shared 76.220.xx.xx/22 pool, through which all your traffic to your static IP addresses (in a totally different subnet, as you may have noticed) is then routed. The 2Wire 3800HGV-B then has a setting called “Public Networks” → “User Defined Supplemental Networks”, where the user has to manually specify the allocation they have received; subsequently, for each individual device on the LAN (as well as in the default options for the LAN DHCP server itself) you can either assign a public address from the public pool, or a private address from the private pool (with the option of specifying which public address the private address will be NAT’ed to). However, I’m getting rid of 2Wire PoS due to the unlimited number of bugs, stability issues, as well as unacceptable power consumption (2× to 3× higher than the devices below, without even supporting GigE or 802.11n).

Prior to buying the routers as below, I’ve tried connecting my OpenBSD netbook to the Ethernet port on the SBC ONT directly, to see if I can indeed ditch 2Wire 3800HGV-B PoS, and after some playing with `ifconfig` and `route`, indeed was I getting all the packets for the static block from the internet without any problems!

I’ve got a ZyXEL NBG4615 to replace 2Wire, then subsequently NETGEAR WNR3500L to replace ZyXEL. Both were (and still are) marketed as routers. When setting up each, I’ve changed the MAC-address to the one used by 2Wire, and set up my /27 subnet to be used for their LAN interfaces. Apparently, both ZyXEL and NETGEAR happily do NAT of publicly routable IP addresses instead of passing it straight, and neither one can do packet forwarding (also known as “routing”, surprise!) between the WAN and LAN interfaces without the NAT.

The ZyXEL does have an option of disabling NAT, so, according to their interface, it’s all supposed to work just dandy. However, apparently, in practice it doesn’t do any routing between the two interfaces once the NAT is disabled (I presume they erroneously also do something like `sysctl net.inet.ip.forwarding=0` or `sysctl net.ipv4.ip_forward=0` when you disable NAT), so my internet simply stops working immediately and as soon as I disable NAT within their interface. I’ve contacted the ZyXEL tech support, and they seem to misunderstand what routing is all about, they also claim that no consumer-oriented router can do routing without [also] doing NAT. Is that really true?

In any case, I tell them they have a clear bug with their user interface not functioning the way anyone would expect it to, yet they repeatedly conclude that they’ll only address the problem if other comparable products on the market also have the feature (“have implemented their own feature set correctly”, they mean?). Pardon me, but how are the obvious bugs in one’s interface are related to any other products by any other manufacturer? Especially if all that’s concerned is literally a one-byte change (0 to 1, that’s merely a bit even!); strike that, most likely is merely a matter of actually removing one or more lines of code that disables ip forwarding through sysctl when NAT is disabled through the interface. After all, this GigE router is based on Linux 2.6, from what I gather and based on nmap.

The NETGEAR doesn’t have any options to disable NAT in their default firmware. Although, to be fair, I would argue that having a default of doing NAT of non-RFC1918 addresses is a major bug in and of itself, and any NAT-disable options in any interface are only really meant to apply to the RFC1918 addresses in the first place.

So, just out of curiosity, any consumer routers that can actually do the simple routing, please?

Is AT&T’s setup of two different subnets (as explained above) really so uncommon in the ISP world to not get any attention of third-party consumer router manufacturers?

Am I actually doing something wrong, and is this whole thing supposed to be configured some other way? Or is this really too advanced and is not supposed to work with consumer off-the-shelf routers at all?

Any firmwares to recommend for WNR3500L that were actually thought out to be a great fit for packet forwarding and multiple routable IP addresses, over two subnets as above? I just want my subnet to work, nothing too fancy, really. That said, it would be disappointing to actually have fewer features than what was available back with 2Wire, e.g. it would be nice to continue having the ability to have two IP-address pools for my LAN, one public and one private. A SIP registration server, HE’s IPv6 TunnelBroker.net support and authoritative DNS would be a plus, too, though. SNMP won’t hurt, either. (-: Looking for something stable that I could install with uptime of months, and which would not break when I need to make simple changes of adding new LAN devices etc.

P.S. BTW, apparently, the ZyXEL tech support guys in Anaheim quite misunderstand what routing between two interfaces is all about. They claim that I want some kind of “advanced router”, whereas their product only offers NAT routing (what is “NAT routing” anyways? do they mean “routing + NAT”?), disregarding the fact that they explicitly have the option of disabling NAT in their interface, where the router is still advertised to be in the Router mode (they have a separate option to select the Mode between Router Mode, Access Point Mode etc). I assume that their NAT-disable option not only disables NAT, but also sets `sysctl net.ipv4.ip_forward` to 0. ZyXEL tech support suggested all sorts of things, from using the router in bridge mode, and configuring my host computers to be on my /27, yet somehow have me specify the AT&T gateway from the shared /22 (I’m, like, really?).

Written for, and discussion at, http://www.dslreports.com/forum/r26754312-Any-consumer-routers-that-can-do-routing-


HE.net / AT&T connectivity woes continue
As reported earlier, HE.net / AT&T connectivity woes continue.
# mtr --report{,-wide} 76-220-32-XX.lightspeed.sntcca.sbcglobal.net ; date
HOST: liXXX-XXX                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 184.105.143.85                                0.0%    10    0.6   0.6   0.4   1.2   0.2
  2. 10gigabitethernet2-3.core1.fmt1.he.net        0.0%    10    0.6   5.2   0.5  11.9   4.8
  3. 10gigabitethernet1-1.core1.pao1.he.net        0.0%    10   11.4   4.3   0.8  11.4   3.4
  4. sjo-bb1-link.telia.net                        0.0%    10    1.3   3.1   1.1  19.8   5.9
  5. las-bb1-link.telia.net                        0.0%    10   14.1  15.0  14.1  22.7   2.7
  6. att-ic-149001-las-bb1.c.telia.net            30.0%    10   23.6  32.0  23.6  38.5   5.0
  7. cr2.la2ca.ip.att.net                         50.0%    10   35.0  34.8  30.0  39.7   4.1
  8. cr2.sffca.ip.att.net                         30.0%    10   32.5  36.0  30.2  41.3   4.0
  9. 12.122.149.141                               50.0%    10   27.3  35.9  27.3  40.4   5.3
 10. ???                                          100.0    10    0.0   0.0   0.0   0.0   0.0
 11. ???                                          100.0    10    0.0   0.0   0.0   0.0   0.0
 12. ???                                          100.0    10    0.0   0.0   0.0   0.0   0.0
 13. 76-220-32-XX.lightspeed.sntcca.sbcglobal.net 80.0%    10   31.1  34.4  31.1  37.8   4.8
Wed Dec 28 21:17:53 EST 2011
  2.|-- 76-220-32-3.lightspeed.sntcca.sbcglobal.net             10.0%    10    2.2   2.6   2.2   3.6   0.4
  3.|-- ???                                                     100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- ???                                                     100.0    10    0.0   0.0   0.0   0.0   0.0
  5.|-- 12.83.39.137                                             0.0%    10    1.8   1.9   1.7   2.3   0.2
  6.|-- 12.122.200.9                                             0.0%    10   45.4  17.5   2.9 105.5  33.7
  7.|-- 208.51.134.1                                             0.0%    10    4.9  10.5   4.9  58.4  16.8
    |  `|-- 192.205.32.46
    |   |-- 192.205.32.50
    |   |-- 208.178.58.185
  8.|-- po1-20G.ar3.SJC2.gblx.net                                0.0%    10    5.3   5.1   5.0   5.3   0.1
  9.|-- Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net 10.0%    10   40.7  42.3  36.2  49.4   4.4
 10.|-- 10gigabitethernet1-1.core1.fmt1.he.net                  50.0%    10   40.3  47.4  40.3  51.9   4.3
 11.|-- linode-llc.10gigabitethernet2-3.core1.fmt1.he.net       60.0%    10   40.8  38.9  36.7  40.8   1.7
 12.|-- li163-159.members.linode.com                            20.0%    10   39.4  39.4  38.2  41.2   1.1
Wed 28 Dec 2011 18:18:22 PST
  2.|-- 76-220-32-3.lightspeed.sntcca.sbcglobal.net 10.0%    10    2.2   3.4   2.2  12.3   3.3
  3.|-- ???                                         100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- 71.145.0.80                                 90.0%    10    4.6   4.6   4.6   4.6   0.0
  5.|-- 12.83.39.137                                 0.0%    10    1.7   3.4   1.7  17.6   5.0
  6.|-- 12.122.137.125                               0.0%    10    2.8  19.8   2.8  47.5  16.0
  7.|-- att-gw.sanjoseequinix.savvis.net             0.0%    10    4.6  10.5   4.5  61.3  17.9
  8.|-- er1-te-3-1.SanJoseEquinix.savvis.net         0.0%    10    4.6  24.4   4.5 169.3  52.0
  9.|-- cr1-tenge-0-3-5-0.sanfrancisco.savvis.net    0.0%    10    7.0   6.6   6.3   7.0   0.2
 10.|-- cr1-tengig-0-0-2-0.losangeles.savvis.net     0.0%    10   16.4  16.4  15.7  17.1   0.4
 11.|-- ber1-tenge-2-1.losangeles.savvis.net         0.0%    10   15.7  16.6  15.6  23.4   2.4
 12.|-- 209.144.203.214                              0.0%    10   16.3  16.2  15.1  17.1   0.6
 13.|-- arpnetworks-lax2-gw.cust.trit.net            0.0%    10   33.8  18.9  16.7  33.8   5.3
 14.|-- arpnetworks.com                              0.0%    10   16.8  16.8  16.4  17.1   0.2
Wed 28 Dec 2011 18:20:24 PST
  2.|-- ???                                                     100.0    10    0.0   0.0   0.0   0.0   0.0
  3.|-- ???                                                     100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- ???                                                     100.0    10    0.0   0.0   0.0   0.0   0.0
  5.|-- 12.83.39.137                                             0.0%    10    1.7   1.9   1.6   2.3   0.2
  6.|-- 12.122.200.9                                             0.0%    10    2.9   8.1   2.9  41.8  12.5
  7.|-- 208.51.134.1                                             0.0%    10    5.0  62.9   5.0 199.6  69.7
    |  `|-- 192.205.32.46
    |   |-- 192.205.32.50
    |   |-- 208.178.58.185
  8.|-- po1-20G.ar3.SJC2.gblx.net                                0.0%    10    5.5  57.7   4.9 228.9  87.6
  9.|-- Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net 30.0%    10   38.0  39.1  33.9  47.7   4.5
 10.|-- 10gigabitethernet1-1.core1.fmt1.he.net                  30.0%    10   43.5  45.6  33.1  92.9  21.2
 11.|-- linode-llc.10gigabitethernet2-3.core1.fmt1.he.net       60.0%    10   34.2  37.7  34.2  40.3   2.6
 12.|-- li163-159.members.linode.com                            20.0%    10   38.1  36.7  32.7  40.1   2.6
Wed 28 Dec 2011 18:21:00 PST

Somehow no noticeable ssh packet loss whatsoever, though.


disappointed in Hurricane Electric latency

Meh. For a few hours now, seems like HE has a latency problem; about 17ms to Fremont from San Jose, instead of the usual ~5.5ms. Even some packet loss, meh.

% traceroute fremont1.linode.com ; date
traceroute to fremont1.linode.com (64.71.152.17), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.387 ms  1.964 ms  1.784 ms
 6  12.122.200.9 (12.122.200.9)  2.974 ms  3.031 ms  3.020 ms
 7  dcr2-so-3-0-0.washington.savvis.net (192.205.32.46)  5.060 ms 208.178.58.185 (208.178.58.185)  5.006 ms 192.205.32.50 (192.205.32.50)  4.965 ms
 8  po1-20G.ar3.SJC2.gblx.net (67.16.134.26)  5.210 ms  5.201 ms  5.012 ms
 9  Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net (64.214.174.246)  26.734 ms  25.329 ms  25.379 ms
10  10gigabitethernet1-1.core1.fmt1.he.net (72.52.92.109)  18.158 ms  17.942 ms  21.013 ms
11  linode-llc.10gigabitethernet2-3.core1.fmt1.he.net (64.62.250.6)  17.133 ms  17.523 ms  17.248 ms
12  fremont1.linode.com (64.71.152.17)  18.028 ms  17.511 ms  18.120 ms
Fri 23 Dec 2011 19:29:24 PST
% ping -c8 fremont1.linode.com; date
PING fremont1.linode.com (64.71.152.17): 56 data bytes
64 bytes from 64.71.152.17: icmp_seq=0 ttl=51 time=17.439 ms
64 bytes from 64.71.152.17: icmp_seq=1 ttl=51 time=17.319 ms
64 bytes from 64.71.152.17: icmp_seq=2 ttl=51 time=17.650 ms
64 bytes from 64.71.152.17: icmp_seq=3 ttl=51 time=19.009 ms
64 bytes from 64.71.152.17: icmp_seq=4 ttl=51 time=18.353 ms
64 bytes from 64.71.152.17: icmp_seq=5 ttl=51 time=19.261 ms
64 bytes from 64.71.152.17: icmp_seq=7 ttl=51 time=17.059 ms

--- fremont1.linode.com ping statistics ---
8 packets transmitted, 7 packets received, 12% packet loss
round-trip min/avg/max/stddev = 17.059/18.013/19.261/0.803 ms
Fri 23 Dec 2011 19:34:53 PST

To be fair, though, seems like HE is not the only one that has poor latency this time of the year — NAC in Newark, with nlayer.net, is also lagging noticeably:

% date ; echo {fremont,dallas,atlanta,newark,tokyo,london}1.linode.com | xargs -tn1 /usr/sbin/traceroute -M5 -w2 -m32 ; date
Fri 23 Dec 2011 19:44:03 PST
/usr/sbin/traceroute -M5 -w2 -m32 fremont1.linode.com
traceroute to fremont1.linode.com (64.71.152.17), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.455 ms  1.768 ms  1.801 ms
 6  12.122.200.9 (12.122.200.9)  159.361 ms  200.101 ms  14.856 ms
 7  192.205.32.50 (192.205.32.50)  47.598 ms 208.51.134.1 (208.51.134.1)  211.444 ms dcr2-so-3-0-0.washington.savvis.net (192.205.32.46)  5.488 ms
 8  po1-20G.ar3.SJC2.gblx.net (67.16.134.26)  4.962 ms  5.050 ms  5.161 ms
 9  Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net (64.214.174.246)  17.085 ms  19.466 ms  24.127 ms
10  10gigabitethernet1-1.core1.fmt1.he.net (72.52.92.109)  17.120 ms  18.184 ms  25.457 ms
11  linode-llc.10gigabitethernet2-3.core1.fmt1.he.net (64.62.250.6)  17.801 ms  17.672 ms  17.424 ms
12  fremont1.linode.com (64.71.152.17)  17.154 ms  17.945 ms  19.139 ms
/usr/sbin/traceroute -M5 -w2 -m32 dallas1.linode.com
traceroute to dallas1.linode.com (69.164.200.100), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.135 ms  1.828 ms  1.619 ms
 6  151.164.101.206 (151.164.101.206)  3.825 ms  3.844 ms  3.837 ms
 7  xe-0-2-0-5.r07.snjsca04.us.bb.gin.ntt.net (129.250.9.121)  5.160 ms ppp-151-164-46-66.eulstx.swbell.net (151.164.46.66)  5.176 ms xe-0-2-0-7.r07.snjsca04.us.bb.gin.ntt.net (129.250.9.141)  5.465 ms
 8  ae1.bbr02.eq01.sjc01.networklayer.com (128.241.219.234)  7.555 ms  5.222 ms  5.302 ms
 9  ae0.bbr02.cs01.lax01.networklayer.com (173.192.18.151)  15.055 ms  14.084 ms  13.686 ms
10  ae7.bbr01.cs01.lax01.networklayer.com (173.192.18.166)  13.854 ms  13.846 ms  13.502 ms
11  ae19.bbr01.eq01.dal03.networklayer.com (173.192.18.140)  46.931 ms  84.632 ms  46.854 ms
12  po31.dsr02.dllstx3.networklayer.com (173.192.18.227)  49.257 ms po31.dsr01.dllstx3.networklayer.com (173.192.18.225)  44.207 ms po31.dsr02.dllstx3.networklayer.com (173.192.18.227)  46.194 ms
13  * * *
14  po1.car01.dllstx2.networklayer.com (70.87.254.74)  46.798 ms po2.car01.dllstx2.networklayer.com (70.87.254.78)  46.925 ms po1.car01.dllstx2.networklayer.com (70.87.254.74)  46.261 ms
15  5a.7.1243.static.theplanet.com (67.18.7.90)  46.774 ms  43.758 ms  49.258 ms
16  dallas1.linode.com (69.164.200.100)  44.063 ms  44.278 ms  47.010 ms
/usr/sbin/traceroute -M5 -w2 -m32 atlanta1.linode.com
traceroute to atlanta1.linode.com (63.247.71.196), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.364 ms  1.770 ms  1.739 ms
 6  ppp-151-164-52-233.rcsntx.swbell.net (151.164.52.233)  3.896 ms  3.804 ms  3.910 ms
 7  asn4436-nlayer.pxpaca.sbcglobal.net (151.164.46.70)  6.494 ms  4.967 ms  5.768 ms
 8  ae0-80g.cr1.pao1.us.nlayer.net (69.22.153.18)  3.798 ms  3.730 ms  3.840 ms
 9  ae1-50g.cr1.sjc1.us.nlayer.net (69.22.143.165)  5.440 ms  5.269 ms  4.353 ms
10  xe-3-3-1.cr1.lax1.us.nlayer.net (69.22.142.8)  13.218 ms xe-5-1-0.cr1.lax1.us.nlayer.net (69.22.142.126)  13.739 ms xe-3-3-1.cr1.lax1.us.nlayer.net (69.22.142.8)  13.217 ms
11  xe-1-0-0.cr1.iah1.us.nlayer.net (69.22.142.121)  48.768 ms  48.500 ms  48.476 ms
12  xe-4-2-1.cr1.atl1.us.nlayer.net (69.22.142.118)  71.607 ms  71.570 ms  71.975 ms
13  ae1-40g.ar1.atl1.us.nlayer.net (69.31.135.130)  65.750 ms  67.621 ms  67.644 ms
14  as3595.xe-2-0-5-101.ar1.atl1.us.nlayer.net (69.31.135.42)  133.773 ms  98.646 ms  80.123 ms
15  64.22.106.10 (64.22.106.10)  63.216 ms  63.468 ms  66.714 ms
16  atlanta1.linode.com (63.247.71.196)  63.546 ms  63.098 ms  63.590 ms
/usr/sbin/traceroute -M5 -w2 -m32 newark1.linode.com
traceroute to newark1.linode.com (207.192.68.6), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.245 ms  1.696 ms  1.635 ms
 6  ex2-p10-0.pxpaca.sbcglobal.net (151.164.190.83)  3.612 ms  3.633 ms  3.529 ms
 7  asn4436-nlayer.pxpaca.sbcglobal.net (151.164.251.34)  4.849 ms  7.351 ms  4.755 ms
 8  ae0-80g.cr1.pao1.us.nlayer.net (69.22.153.18)  3.737 ms  10.857 ms  3.664 ms
 9  ae1-60g.cr1.sfo1.us.nlayer.net (69.22.143.169)  4.329 ms  4.346 ms  4.346 ms
10  xe-0-0-3.cr1.slc1.us.nlayer.net (69.22.142.96)  19.397 ms  19.331 ms  19.394 ms
11  xe-5-2-0.cr1.ord1.us.nlayer.net (69.22.142.101)  53.983 ms  53.913 ms  53.920 ms
12  xe-9-2-0.cr1.ewr1.us.nlayer.net (69.22.142.75)  118.761 ms  118.864 ms  120.644 ms
13  ae1-70g.ar2.ewr1.us.nlayer.net (69.31.94.118)  122.490 ms  105.794 ms  120.565 ms
14  as8001.xe-3-0-6.ar2.ewr1.us.nlayer.net (69.31.95.130)  104.817 ms  104.694 ms  104.436 ms
15  0.e1-2.tbr1.mmu.nac.net (209.123.10.118)  118.743 ms  119.052 ms  120.066 ms
16  vlan803.esd2.mmu.nac.net (209.123.10.30)  73.661 ms  73.959 ms  75.223 ms
17  207.99.53.46 (207.99.53.46)  106.657 ms  109.364 ms  104.719 ms
18  newark1.linode.com (207.192.68.6)  116.415 ms  116.762 ms  118.573 ms
/usr/sbin/traceroute -M5 -w2 -m32 tokyo1.linode.com
traceroute to tokyo1.linode.com (106.187.33.12), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.321 ms  1.849 ms  1.613 ms
 6  ggr7.sffca.ip.att.net (12.122.114.17)  2.985 ms  2.807 ms  2.836 ms
 7  192.205.36.2 (192.205.36.2)  4.349 ms  4.458 ms  4.498 ms
 8  pax-brdr-01.inet.qwest.net (205.171.234.2)  5.937 ms  5.873 ms  5.927 ms
 9  124.215.192.77 (124.215.192.77)  23.994 ms  17.741 ms  17.895 ms
10  pajbb002.kddnet.ad.jp (111.87.3.29)  120.640 ms pajbb002.kddnet.ad.jp (124.211.34.133)  16.082 ms pajbb001.kddnet.ad.jp (111.87.3.5)  84.107 ms
11  otejbb203.kddnet.ad.jp (203.181.100.5)  131.326 ms otejbb203.kddnet.ad.jp (203.181.100.209)  119.472 ms otejbb204.kddnet.ad.jp (203.181.100.201)  119.155 ms
12  cm-fcu203.kddnet.ad.jp (124.215.194.164)  121.772 ms  125.743 ms cm-fcu203.kddnet.ad.jp (124.215.194.180)  133.351 ms
13  124.215.199.122 (124.215.199.122)  113.014 ms  115.081 ms  123.389 ms
14  tokyo1.linode.com (106.187.33.12)  120.650 ms  112.850 ms  114.916 ms
/usr/sbin/traceroute -M5 -w2 -m32 london1.linode.com
traceroute to london1.linode.com (109.74.207.9), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.025 ms  13.973 ms  1.969 ms
 6  12.122.200.9 (12.122.200.9)  2.886 ms  2.792 ms  2.951 ms
 7  192.205.36.234 (192.205.36.234)  5.252 ms  4.845 ms  5.133 ms
 8  telecity.ge9-9.br02.ldn01.pccwbtn.net (63.218.13.222)  146.812 ms  146.863 ms  146.933 ms
 9  te4-1-dist65-01.lon10.telecity.net (217.20.44.218)  148.074 ms  148.169 ms  148.923 ms
10  212.111.33.234 (212.111.33.234)  148.846 ms  149.418 ms  148.772 ms
11  london1.linode.com (109.74.207.9)  149.089 ms  148.989 ms  149.142 ms
Fri 23 Dec 2011 19:44:19 PST

Just for the full picture:

% traceroute sonic.net ; date
traceroute to sonic.net (209.204.190.64), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.126 ms  1.751 ms  1.617 ms
 6  ppp-151-164-52-133.rcsntx.swbell.net (151.164.52.133)  3.852 ms  3.678 ms  3.867 ms
 7  asn4436-nlayer.pxpaca.sbcglobal.net (151.164.251.34)  10.775 ms  4.978 ms  7.045 ms
 8  as7065.xe-1-0-6.ar1.pao1.us.nlayer.net (69.22.130.86)  3.723 ms  3.815 ms  3.542 ms
 9  0.ge-0-1-0.gw.sr.sonic.net (64.142.0.197)  6.273 ms  6.259 ms  6.262 ms
10  gig0-1.dist2-1.sr.sonic.net (209.204.191.160)  6.222 ms gig0-2.dist2-1.sr.sonic.net (208.201.224.160)  6.430 ms  6.510 ms
11  fast1.lb2-1.slb.sr.sonic.net (64.142.0.58)  6.376 ms  6.432 ms  6.453 ms
12  fast1.lb2-1.slb.sr.sonic.net (64.142.0.58)  6.567 ms  6.467 ms  6.449 ms
Fri 23 Dec 2011 19:47:05 PST
% traceroute netflix.com ; date
traceroute to netflix.com (69.53.236.17), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.139 ms  1.724 ms  1.667 ms
 6  ggr7.sffca.ip.att.net (12.122.114.13)  3.611 ms  36.855 ms  47.582 ms
 7  xe-1-2-0.mpr4.sjc7.us.above.net (64.125.12.117)  4.671 ms  4.588 ms  4.594 ms
 8  xe-1-0-0.mpr3.sjc7.us.above.net (64.125.26.125)  4.890 ms  4.844 ms  4.910 ms
 9  xe-4-0-0.er1.sjc2.us.above.net (64.125.30.173)  4.864 ms  4.975 ms  4.877 ms
10  64.124.65.90.allocated.above.net (64.124.65.90)  5.121 ms  5.052 ms  4.925 ms
11  xe-2-3-0-945.jnrt-edge02.sv1.netflix.com (208.75.77.197)  6.108 ms  6.032 ms  5.972 ms
12  xe-2-2-0-955.jnrt-edge02.prod1.netflix.com (69.53.225.30)  7.189 ms  17.194 ms  7.141 ms
13  te1-8.csrt-agg02.prod1.netflix.com (69.53.225.10)  7.532 ms  7.335 ms  7.367 ms
14  netflixfreetrial.com (69.53.236.17)  7.237 ms  7.172 ms  7.199 ms
Fri 23 Dec 2011 19:47:31 PST
% traceroute facebook.com ; date
traceroute: Warning: facebook.com has multiple addresses; using 66.220.149.11
traceroute to facebook.com (66.220.149.11), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.108 ms  2.252 ms  1.844 ms
 6  151.164.101.206 (151.164.101.206)  3.981 ms  4.046 ms  3.954 ms
 7  xe-0-2-0-6.r07.snjsca04.us.bb.gin.ntt.net (129.250.8.93)  6.051 ms xe-0-2-0-7.r07.snjsca04.us.bb.gin.ntt.net (129.250.9.141)  5.274 ms ppp-151-164-46-66.eulstx.swbell.net (151.164.46.66)  5.495 ms
 8  ae-8.r21.snjsca04.us.bb.gin.ntt.net (129.250.5.56)  5.471 ms ae-7.r20.snjsca04.us.bb.gin.ntt.net (129.250.5.52)  5.731 ms ae-8.r21.snjsca04.us.bb.gin.ntt.net (129.250.5.56)  5.523 ms
 9  ae-4.r05.plalca01.us.bb.gin.ntt.net (129.250.5.32)  6.387 ms ae-4.r06.plalca01.us.bb.gin.ntt.net (129.250.4.118)  6.551 ms ae-4.r05.plalca01.us.bb.gin.ntt.net (129.250.5.32)  6.656 ms
10  ae-2.r05.plalca01.us.bb.gin.ntt.net (129.250.5.237)  6.367 ms 140.174.21.142 (140.174.21.142)  6.151 ms ae-2.r05.plalca01.us.bb.gin.ntt.net (129.250.5.237)  6.629 ms
11  ae1.bb01.pao1.tfbnw.net (74.119.76.134)  7.840 ms 140.174.21.142 (140.174.21.142)  6.885 ms ae1.bb01.pao1.tfbnw.net (74.119.76.134)  6.481 ms
12  ae1.bb01.pao1.tfbnw.net (74.119.76.134)  6.651 ms ae2.dr02.snc5.tfbnw.net (74.119.77.192)  6.813 ms ae1.bb01.pao1.tfbnw.net (74.119.76.134)  6.498 ms
13  po509.csw02b.snc5.tfbnw.net (74.119.78.28)  7.216 ms ae0.dr01.snc5.tfbnw.net (74.119.77.180)  7.469 ms po509.csw02a.snc5.tfbnw.net (74.119.78.24)  7.063 ms
14  po510.csw02b.snc5.tfbnw.net (74.119.78.26)  7.358 ms * po509.csw02a.snc5.tfbnw.net (74.119.78.24)  7.916 ms
15  * * *
16  *^C
% traceroute google.com ; date
traceroute: Warning: google.com has multiple addresses; using 74.125.224.147
traceroute to google.com (74.125.224.147), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.503 ms  1.851 ms  1.622 ms
 6  ppp-151-164-52-163.rcsntx.swbell.net (151.164.52.163)  4.657 ms  4.581 ms  4.528 ms
 7  gar7.sffca.ip.att.net (12.122.79.97)  4.569 ms  4.463 ms  4.628 ms
 8  cr83.sffca.ip.att.net (12.122.110.118)  7.015 ms  6.648 ms  6.170 ms
 9  cr1.sffca.ip.att.net (12.123.15.109)  7.134 ms  8.057 ms  7.767 ms
10  cr81.sj2ca.ip.att.net (12.122.1.118)  7.327 ms  7.347 ms  6.838 ms
11  12.122.114.21 (12.122.114.21)  5.999 ms  5.853 ms  5.662 ms
12  12.249.231.14 (12.249.231.14)  6.488 ms  6.477 ms  6.438 ms
13  209.85.249.3 (209.85.249.3)  7.001 ms  7.207 ms  6.940 ms
14  64.233.174.119 (64.233.174.119)  7.518 ms  7.382 ms  7.297 ms
15  nuq04s09-in-f19.1e100.net (74.125.224.147)  7.108 ms  6.924 ms  8.550 ms
Fri 23 Dec 2011 19:49:05 PST
% traceroute paxio.net ; date
traceroute to paxio.net (63.216.71.33), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.140 ms  1.777 ms  1.658 ms
 6  ggr6.wswdc.ip.att.net (12.122.86.89)  3.224 ms  15.199 ms  3.122 ms
 7  192.205.32.206 (192.205.32.206)  5.203 ms  5.082 ms  5.015 ms
 8  vlan80.csw3.SanJose1.Level3.net (4.69.152.190)  5.785 ms vlan90.csw4.SanJose1.Level3.net (4.69.152.254)  5.753 ms  5.649 ms
 9  ae-72-72.ebr2.SanJose1.Level3.net (4.69.153.21)  7.140 ms  7.352 ms ae-62-62.ebr2.SanJose1.Level3.net (4.69.153.17)  5.706 ms
10  ae-5-5.car1.Oakland1.Level3.net (4.69.134.37)  6.833 ms  6.644 ms  6.809 ms
11  ae-11-11.car2.Oakland1.Level3.net (4.69.134.42)  6.831 ms  6.705 ms  6.762 ms
12  PAXIO-INC.car2.Oakland1.Level3.net (4.71.202.38)  7.325 ms  7.359 ms  7.248 ms
13  173.241.16.50 (173.241.16.50)  7.468 ms  7.865 ms  7.492 ms
14  63-216-64-246.paxio.net (63.216.64.246)  7.281 ms  7.022 ms  7.169 ms
15  64-201-240-174.static.paxio.net (64.201.240.174)  7.190 ms  6.926 ms  7.955 ms
16  64-201-240-182.static.paxio.net (64.201.240.182)  8.424 ms  9.611 ms  8.657 ms
17  64-201-240-170.static.paxio.net (64.201.240.170)  8.724 ms  8.196 ms  8.426 ms
18  * * *
19  *^C

Somehow, Google and Facebook don’t seem to have any latency issues whatsoever, yet HE.net, whose sole purpose is IP transit, can’t get their latency within the Bay Area alone! WTF? NAC, a famous data centre in Newark, with its nlayer.net transit, also disappoints.

P.S. Hm, svcolo.com seems good, through nlayer.net, the latency may perhaps go as low as 3.5ms during non-peak hours, now about 4.0ms:

% traceroute svcolo.com ; date
traceroute to svcolo.com (64.13.135.35), 32 hops max, 40 byte packets
 5  12.83.39.137 (12.83.39.137)  2.181 ms  1.797 ms  1.746 ms
 6  151.164.54.183 (151.164.54.183)  3.800 ms  3.446 ms  3.567 ms
 7  asn4436-nlayer.pxpaca.sbcglobal.net (151.164.46.70)  8.373 ms  7.769 ms  5.264 ms
 8  ae0-80g.cr1.pao1.us.nlayer.net (69.22.153.18)  64.425 ms  3.518 ms  3.634 ms
 9  as8121.ae0-3001.cr1.pao1.us.nlayer.net (69.22.153.114)  3.907 ms  3.849 ms  3.850 ms
10  xe1-4.core1.svk.layer42.net (69.36.239.121)  4.316 ms  4.163 ms  4.125 ms
11  www.svcolo.com (64.13.135.35)  3.969 ms  4.054 ms  4.050 ms
Fri 23 Dec 2011 21:16:51 PST

P.P.S. Apparently, according to http://lg.he.net/, the issue is that the traffic back to my place, goes through telia in Los Angeles. WTF?

core1.fmt1.he.net> traceroute 76.220.??.?? source-ip 216.218.252.161 numeric
Target	76.220.32.89
Hop Start	1
Hop End	30
Hop	Packet 1	Packet 2	Packet 3	Hostname
1	14 ms	1 ms	<1 ms	10gigabitethernet1-1.core1.pao1.he.net (184.105.213.66)
2	1 ms	1 ms	1 ms	sjo-bb1-link.telia.net (213.248.86.53)
3	14 ms	24 ms	49 ms	las-bb1-link.telia.net (213.248.80.17)
4	25 ms	24 ms	24 ms	att-ic-149001-las-bb1.c.telia.net (213.248.88.30)
5	25 ms	25 ms	24 ms	cr2.la2ca.ip.att.net (12.123.30.150)
6	26 ms	24 ms	24 ms	cr2.sffca.ip.att.net (12.122.31.134)
7	24 ms	25 ms	26 ms	12.122.149.141
8	*	*	*	?
9	*	*	*	?
10	*	*	*	?
11	74 ms	18 ms	24 ms	76-220-??-??.lightspeed.sntcca.sbcglobal.net (76.220.??.??)

dslreports: How does CenturyLink offer 40/20, when AT&T max is 24/3?

Isn’t it surprisingly shocking that AT&T with all the same technologies as its competitors in other regions, delivers significantly lower speeds than the said competitors, roughly using about the exact same technologies as the competitors are using?

Right now:

BPON @ Verizon FiOS: 15/5, 25/25 and 50/20. (real speeds are actually higher than advertised)
BPON @ AT&T U-verse: …, 12/1.5 and 18/1.5. (yes, there’s no 24Mbps package on AT&T FTTH)

GPON @ Verizon FiOS: 150/35 in print, 150/75 in reality. :-)
GPON @ AT&T: trials? still 18/1.5?

VDSL2 @ CenturyLink: 40/20.
VDSL2 @ AT&T U-verse: 24/3 for single pair, or 18/1.5 for bonded pair (yes, in that order).

Threads about future plans:

CenturyLink:
http://www.dslreports.com/forum/r26533877-CenturyLink-offers-100mpbs-
http://www.dslreports.com/forum/r26643724-Qwest-Pictures-of-100MBps-and-PRICES-Look-Here
Summary: 100Mbps at rather affordable prices (competitive with FiOS), coming soon, official prices and materials leaked from multiple sources.

AT&T U-verse:
http://www.dslreports.com/forum/r26433752-45-MB-internet-service
Summary: 30/3 and 36/6 for FTTH customers only (http://www.dslreports.com/forum/r26644272-45-MB-internet-service). Still merely an unconfirmed rumour, replaced some other prior unconfirmed rumour about entirely different plans, no solid proof whatsoever for neither the old nor the new info.

Will AT&T ever catch up to its ILEC competitors? Why AT&T’s future plans are lower than the existing plans from its competition? Not even talking about Verizon FiOS 150/75, how could CenturyLink be delivering 40/20 over copper, whereas here in this forum it is claimed that AT&T would have problems with the 3.0 upstream on those bonded VDSL2 lines that are seemingly easily capable of much higher speeds than that?

For the record, although fibre is obviously the future, I think copper still has a lot of life in it left. Just one more proof that it’s not what you have, it’s how you use it, AT&T.

Written for, and discussion at, http://www.dslreports.com/forum/r26671109-How-does-CenturyLink-offer-40-20-when-AT-T-max-is-24-3-


dslreports: [FTTH] 4ms+ ping to anywhere outside of the AT&T border

Come to think about it, I’m confused why my ping times are so bad. I have a latency of noticeably well under 2ms to several first hops into the AT&T U-verse network (hops 2, 3*, 4* and 5), yet recently, anything anywhere other than the AT&T routers is always at least 4ms away.

What’s adding those extra 2 to 3 ms of delay between AT&T serving me pretty much in the middle of San Jose, and the other networks within the city limits of, well, you guessed it, still San Jose? If it matters, my ZIP code is 95126 (a 10-minute bike ride to downtown SJ), and, in case anyone missed the prior discussions, my U-verse is powered by Alcatel HONT-C (4 POTS, 1 Ethernet; “155.52 Mbps upstream and 622.08 Mbps downstream”, most certainly 1:32), with the 18Mbps (18/1.5) HSI package (highest available from AT&T over fibre right now, with 24/3 being limited to copper only).

From prior discussion and recollection (http://www.dslreports.com/forum/r26124366-What-has-better-latency-from-a-residential-area-), the best latency I ever got was this summer, at 2.1ms to a USPS site through akamai.net (see a link to my tumblr from the above thread, http://tu.cnst.su/post/8423170265/ping-to-usps-in-under-3ms-from-u-verse-ftth), so I know it should be entirely possible, but no longer happens in practice.

% traceroute -I www.sanjoseca.gov ; date
traceroute to www.sanjoseca.gov (156.39.1.45), 32 hops max, 60 byte packets
 2  76-220-32-3.lightspeed.sntcca.sbcglobal.net (76.220.32.3)  2.985 ms  1.667 ms  1.624 ms
 3  71.145.0.104 (71.145.0.104)  5.641 ms  1.659 ms  1.673 ms
 4  * * *
 5  12.83.39.137 (12.83.39.137)  1.685 ms  1.630 ms  1.588 ms
 6  12.122.200.9 (12.122.200.9)  2.916 ms  2.764 ms  2.830 ms
 7  208.178.58.185 (208.178.58.185)  115.682 ms 192.205.32.50 (192.205.32.50)  199.823 ms dcr2-so-3-0-0.washington.savvis.net (192.205.32.46)  183.584 ms
 8  po1-20G.ar3.SJC2.gblx.net (67.16.134.26)  128.934 ms  394.740 ms  233.524 ms
 9  Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net (64.214.174.246)  4.886 ms  4.904 ms  4.882 ms
10  10gigabitethernet1-4.core1.sjc1.he.net (72.52.92.117)  5.184 ms  5.421 ms  5.008 ms
11  city-of-san-jose.gigabitethernet2-8.core1.sjc1.he.net (64.71.176.98)  6.897 ms  6.839 ms  6.595 ms
12  156.39.0.251 (156.39.0.251)  5.316 ms  5.283 ms  4.951 ms
13  * * *
14  156.39.1.45 (156.39.1.45)  5.929 ms  5.690 ms  5.459 ms
Sat 17 Dec 2011 19:26:20 PST

% traceroute -I www.netflix.com ; date
traceroute to www.netflix.com (69.53.236.17), 32 hops max, 60 byte packets
 2  76-220-32-3.lightspeed.sntcca.sbcglobal.net (76.220.32.3)  4.704 ms  1.657 ms  1.627 ms
 3  * * *
 4  * * *
 5  12.83.39.137 (12.83.39.137)  1.612 ms  1.590 ms  1.854 ms
 6  ggr7.sffca.ip.att.net (12.122.114.13)  2.721 ms  2.562 ms  2.617 ms
 7  xe-1-2-0.mpr4.sjc7.us.above.net (64.125.12.117)  4.580 ms  4.315 ms  4.527 ms
 8  xe-3-1-0.er2.sjc2.us.above.net (64.125.27.94)  5.290 ms  5.437 ms  6.319 ms
 9  64.125.28.13.available.above.net (64.125.28.13)  5.183 ms  4.965 ms  5.081 ms
10  64.124.65.90.allocated.above.net (64.124.65.90)  5.305 ms  5.285 ms  5.162 ms
11  xe-2-3-0-945.jnrt-edge02.sv1.netflix.com (208.75.77.197)  6.222 ms  6.232 ms  6.252 ms
12  xe-2-2-0-955.jnrt-edge02.prod1.netflix.com (69.53.225.30)  7.432 ms  7.377 ms  7.253 ms
13  te1-8.csrt-agg02.prod1.netflix.com (69.53.225.10)  12.506 ms  7.671 ms  7.645 ms
14  netflix.co.uk (69.53.236.17)  7.220 ms  7.242 ms  10.942 ms
Sat 17 Dec 2011 19:27:47 PST

% traceroute -I www.facebook.com ; date
traceroute to www.facebook.com (69.171.228.13), 32 hops max, 60 byte packets
 2  76-220-32-3.lightspeed.sntcca.sbcglobal.net (76.220.32.3)  2.506 ms  10.590 ms  1.785 ms
 3  * * *
 4  * * *
 5  12.83.39.137 (12.83.39.137)  2.205 ms  1.656 ms  1.584 ms
 6  151.164.101.206 (151.164.101.206)  3.870 ms  3.810 ms  3.724 ms
 7  xe-0-2-0-5.r07.snjsca04.us.bb.gin.ntt.net (129.250.9.121)  5.644 ms xe-0-2-0-6.r07.snjsca04.us.bb.gin.ntt.net (129.250.8.93)  5.565 ms xe-0-2-0-7.r07.snjsca04.us.bb.gin.ntt.net (129.250.9.141)  5.723 ms
 8  ae-7.r20.snjsca04.us.bb.gin.ntt.net (129.250.5.52)  5.359 ms  5.358 ms  5.213 ms
 9  ae-4.r05.plalca01.us.bb.gin.ntt.net (129.250.5.32)  6.740 ms  6.442 ms  6.229 ms
10  140.174.21.142 (140.174.21.142)  6.838 ms  6.068 ms  6.574 ms
11  ae1.bb01.pao1.tfbnw.net (74.119.76.134)  6.689 ms  6.445 ms  6.464 ms
12  ae9.bb01.prn1.tfbnw.net (204.15.20.51)  32.184 ms  31.861 ms  31.486 ms
13  ae0.dr04.prn1.tfbnw.net (204.15.23.87)  30.840 ms  31.005 ms  30.862 ms
14  po1022.csw05a.prn1.tfbnw.net (74.119.76.243)  31.777 ms  31.721 ms  31.610 ms
15  www-12-05-prn1.facebook.com (69.171.228.13)  29.830 ms  29.854 ms  30.804 ms
Sat 17 Dec 2011 19:29:29 PST
And just for completeness, the test below is back to that IP address to which I was getting 2.1ms in the summer; now merely 4.0ms. The only difference now on my part is that I’ve ditched 2Wire and I’m also not currently using the /27 IP-addresses (but that shouldn’t matter, unless the routing tables are misconfigured on AT&T’s side).
% traceroute -I 69.22.162.122; date
traceroute to 69.22.162.122 (69.22.162.122), 32 hops max, 60 byte packets
 2  76-220-32-3.lightspeed.sntcca.sbcglobal.net (76.220.32.3)  2.984 ms  1.835 ms  2.272 ms
 3  * * *
 4  71.145.0.80 (71.145.0.80)  4.298 ms * *
 5  12.83.39.137 (12.83.39.137)  1.867 ms  1.653 ms  1.550 ms
 6  ppp-151-164-52-233.rcsntx.swbell.net (151.164.52.233)  4.542 ms  3.660 ms  3.726 ms
 7  asn4436-nlayer.pxpaca.sbcglobal.net (151.164.46.70)  4.776 ms  4.858 ms  4.704 ms
 8  69.22.162.122 (69.22.162.122)  4.007 ms  4.041 ms  4.131 ms
Sat 17 Dec 2011 20:02:59 PST

% traceroute -I trkcnfrm1.smi.usps.com; date
traceroute: Warning: trkcnfrm1.smi.usps.com has multiple addresses; using 63.235.28.96
traceroute to a1834.b.akamai.net (63.235.28.96), 32 hops max, 60 byte packets
 2  76-220-32-3.lightspeed.sntcca.sbcglobal.net (76.220.32.3)  2.254 ms  1.912 ms  1.689 ms
 3  * * *
 4  * * *
 5  12.83.39.137 (12.83.39.137)  1.810 ms  1.505 ms  1.665 ms
 6  ggr7.sffca.ip.att.net (12.122.114.17)  2.846 ms  2.796 ms  2.620 ms
 7  192.205.36.2 (192.205.36.2)  4.413 ms  4.382 ms  4.236 ms
 8  * * *
 9  63-235-28-96.dia.static.qwest.net (63.235.28.96)  5.082 ms  6.201 ms  4.846 ms
Sat 17 Dec 2011 20:03:38 PST

Basically, from the original USPS example, it would seem like nlayer.net had the best latency, and turns out, it is indeed true to this day, too:

% traceroute -I nlayer.net ; date
traceroute to nlayer.net (204.93.207.190), 32 hops max, 60 byte packets
 2  76-220-32-3.lightspeed.sntcca.sbcglobal.net (76.220.32.3)  22.426 ms  3.748 ms  2.055 ms
 3  * * 71.145.0.104 (71.145.0.104)  2.677 ms
 4  * * *
 5  12.83.39.137 (12.83.39.137)  1.768 ms  1.620 ms  1.509 ms
 6  ppp-151-164-52-133.rcsntx.swbell.net (151.164.52.133)  3.638 ms  3.564 ms  3.340 ms
 7  asn4436-nlayer.pxpaca.sbcglobal.net (151.164.251.34)  4.897 ms  4.993 ms  14.479 ms
 8  ae0-80g.cr1.pao1.us.nlayer.net (69.22.153.18)  3.806 ms  3.766 ms  4.081 ms
 9  ae1-60g.cr1.sfo1.us.nlayer.net (69.22.143.169)  10.091 ms  9.223 ms  9.687 ms
10  xe-0-0-3.cr1.slc1.us.nlayer.net (69.22.142.96)  24.748 ms  24.892 ms  25.809 ms
11  xe-5-2-0.cr1.ord1.us.nlayer.net (69.22.142.101)  53.535 ms  53.569 ms  53.602 ms
12  po6.ar1.ord1.us.scnet.net (69.31.111.58)  54.156 ms  53.814 ms  53.741 ms
13  61.po1.ar1.ord6.us.scnet.net (75.102.3.226)  54.864 ms  54.891 ms  54.795 ms
14  ge0-1.aggrGA139-1.ord6.us.scnet.net (75.102.0.146)  55.514 ms  56.915 ms  60.966 ms
15  web1.ord.servercentral.net (204.93.207.190)  54.756 ms  54.974 ms  54.642 ms
Sat 17 Dec 2011 20:25:13 PST

Any ideas why the latency is so bad between the AT&T U-verse network and the internet? Why am I routinely getting 4ms+ instead of that 2.1ms that was once sustainably achieved? Basically, it seems like there is an extra 2.5ms to 3ms delay (translating to 4.0ms and 4.5ms overall delay from my ONT) between the AT&T U-verse routers (hop 5 @ 1.5ms overall) and the actual internet (hop 7 or later @ 4ms+ overall). Why? Where are they losing the 2.5ms? Why did those 2.5ms used to be merely 0.5ms, but no more?

Also, where is my BPON coming from? Is it not the AT&T building at 95 S Almaden Ave, San Jose, CA 95113? I always thought that was their CO, and that BPON users are served right from the CO.

Written for discussion at http://www.dslreports.com/forum/r26669632-FTTH-4ms-ping-to-anywhere-outside-of-the-AT-T-border


dslreports: AT&T U-verse FTTP: line bonding with fibre for 24/3 tier?

So… I was thinking about this whole AT&T U-verse profiles thing. People who live too far away from a VRAD can get pair bonding with an iNID such that they can still enjoy U-verse at full speed, right?

I can’t deny myself the pleasure to entertain the thought of AT&T doing line-bonding of fibre, since, apparently, their fibre-to-the-premises lines are limited to the 30/3.6 profile that doesn’t support their full 24/3.0 internet offering, whereas for copper customers such internet offering is readily available on a single xDSL line, isn’t it?

Please note that I think that the upload speed is important, and this line bonding would effectively double my speed (as any line bonding should), since I now only have 1.5Mbps, and I’d like to have the fastest-possible 3.0Mbps. I’m so happy AT&T offers 3.0 Mbps on U-verse, it’s my dream come true, I don’t even know what I’m going to do with so much bandwidth, LOL! Uploading a 7 megapixel picture from my Canon PowerShot ELPH 300 HS digital camera will only take like a blazing 5 seconds! It takes 10 seconds right now for each photo. Yeah, I know, 10 seconds is already so blazing fast (don’t even have the time to make the coffee while one picture is being uploaded), but I want the fastest possible of 5 seconds! AT&T is truly Rethink Possible if it can offer 3Mbps upload speeds to residential customers! It’s, like, higher speeds are simply not possible, are they? I mean, right?

For my part, I promise not to be a bandwidth hog; in fact, I hate those people who are hogging the internets! Pipes cannot sustain you guys, please stop and let other people enjoy the net, too! You’re not alone out here, lads and lasses, so please behave and don’t hog the pipes we all share!

As far as the incoming fibre is concerned, my apartment is pre-glassed as follows: the fibre cable comes very-very thick into my apartment, and then a fibre splitter is used to make the fibre cable very-very thin before the thin fibre cable reaches the ONT. So I think there should already be enough of the thick fibre reaching my place to support line splitting at the splitter and line bonding at the ONT, right?

Can I have the splitter split the thick fibre line into two thin ones, and then line bond the fibre at the ONT? (-: Does this make sense? (-: Would I have to have a new ONT that would support line bonding?

I trust this post is taken by AT&T with all seriousness that it deserves. AT&T customers entrust AT&T to deliver the top-notch competitive service at all levels and in all communities, and I hope this would be no exception. I live in San Jose, CA, 95126, and I trust that AT&T offers the fastest fibre internet that is theoretically possible for residential customers and with speed offerings on which anyone can always count. AT&T clearly defines the Rethink Possible motto, being such an innovator in the area, where people can finally have fibre reach out their homes ahead of the competition! I truly hope it’ll be possible to get the fastest 24/3 package with fibre line bonding!

Best regards and thanks in advance,
Constantine dba Vasily Pupkine.

http://www.dslreports.com/forum/r26298279-AT-T-U-verse-FTTP-line-bonding-with-fibre-for-24-3-tier-


A possible conversation in Sebastopol, CA in 2011
AT&T: Hello, welcome to AT&T, your incumbent duopoly telco provider. How can I help you?
Sebastopol resident: Is 18Mbps downstream and 1.5Mbps upstream the fastest you offer for FTTH U-verse customers?
AT&T: Yes, we also offer 24/3, but that is only available to customers that have copper, through VDSL, and not available via fibre to any FTTH customers. Anything else I can help you with?
Sebastopol resident: Yes, please cancel my uber slow 18/1.5. I'm switching to Sonic.net's 1Gbps/100Mbps fibre, you know, Sonic.net Fusion FTTH with 1Gbps for 69 dollars a month.
AT&T: :-o

AT&T U-verse HSI over fibre is slower than UMTS/HSUPA nationwide wireless!

As you may be aware, I have AT&T U-verse High Speed Internet, and because I live in a new development, my connection is actually provided over fibre, where AT&T terminates their fibre right in my bedroom’s closet. (I’ll post the pictures when I’ll get around to it.) This provides excellent connectivity: my ping times to akamai are always in the order of single ms digits, currently in the busy hour being around 5ms, but at other times even being under 3ms. I’m yet to see anything above 8ms to akamai!

That’s excellent latency! Remember, this is residential service, getting 2.5 ms to akamai — nothing short of phenomenal. But how’s the bandwidth of AT&T U-verse through Fibre? If you don’t have U-verse over fibre, you’re going to laugh: the highest they offer over fibre is 18 Mbps download with 1.5 Mbps upload.

1.5 Mbps is the highest upload speed they offer to fibre customers, ask around, it’s not even a secret (most of their customers are copper, so they won’t reveal this information unless specifically inquired).

Seriously, AT&T? My T-Mobile myTouch 4G, an HSPA+ phone, can provide me with upload speeds benchmarkable at 3.48 Mbps over UMTS/HSUPA, a 3.5G wireless network, and AT&T U-verse only offers 1.5 Mbps upstream over fibre?

A month ago, I was reading about Baby Bells, and came across one independent Bell: I then wished I lived in Ohio! Cincinnati Bell Fioptics Internet offerings: 20Mbps down, 5 up — 49,99; the fastest AT&T offering is slower and about 20% more expensive! The complete set of offerings for Cincinnati Bell Fioptiocs Internet is as follows: 10/2 — 39; 20/5 — 49; 30/10 — 59; 50/10 — 99; 100/20 — 299. I would totally go for 30 Mbps downstream with 10 Mbps upstream, for 59,99 USD, without much contemplation! I wish my FTTP U-verse with AT&T was even remotely comparative: 18/1.5 — 59 USD, is nothing but slow and expensive. The plans below 18/1.5 are nothing short of being laughable for a fibre service. :-)

This is kind of beyond my comprehension. I also don’t understand why AT&T is even allowed to advertise offering 24 Mbps downstream / 3.0 Mbps upstream U-verse HSI package, without specifying that it is only available FTTN / FTTC (node / curb), to copper customers; but not FTTP / FTTH (premises / home), to fibre customers. Does anyone know how they get along with it?


ping to usps in under 3ms from u-verse ftth

is that not crazy or what? AT&T U-verse FTTP/FTTH isn’t all that bad!

% ping -c8 trkcnfrm1.smi.usps.com
PING a1834.b.akamai.net (69.22.162.122): 56 data bytes
64 bytes from 69.22.162.122: icmp_seq=0 ttl=56 time=2.717 ms
64 bytes from 69.22.162.122: icmp_seq=1 ttl=56 time=2.599 ms
64 bytes from 69.22.162.122: icmp_seq=2 ttl=56 time=2.517 ms
64 bytes from 69.22.162.122: icmp_seq=3 ttl=56 time=2.534 ms
64 bytes from 69.22.162.122: icmp_seq=4 ttl=56 time=2.620 ms
64 bytes from 69.22.162.122: icmp_seq=5 ttl=56 time=2.582 ms
64 bytes from 69.22.162.122: icmp_seq=6 ttl=56 time=2.553 ms
64 bytes from 69.22.162.122: icmp_seq=7 ttl=56 time=2.620 ms

--- a1834.b.akamai.net ping statistics ---
8 packets transmitted, 8 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.517/2.593/2.717/0.059 ms
% traceroute -I trkcnfrm1.smi.usps.com
traceroute: Warning: trkcnfrm1.smi.usps.com has multiple addresses; using 69.22.162.122
traceroute to a1834.b.akamai.net (69.22.162.122), 64 hops max, 60 byte packets
 1  home (99.124.xxx.xxx)  1.057 ms  0.693 ms  0.615 ms
 2  76-220-32-3.lightspeed.sntcca.sbcglobal.net (76.220.32.3)  2.551 ms  1.908 ms  1.824 ms
 3  * * *
 4  * * *
 5  151.164.103.232 (151.164.103.232)  1.835 ms  1.737 ms  1.773 ms
 6  ppp-151-164-52-237.rcsntx.swbell.net (151.164.52.237)  2.392 ms  1.967 ms  1.968 ms
 7  asn4436-nlayer.pxpaca.sbcglobal.net (151.164.46.70)  3.480 ms  3.611 ms  3.774 ms
 8  69.22.162.122 (69.22.162.122)  2.202 ms  2.405 ms  2.147 ms