AT&T's Going to Carolina With 1 Gig

AT&T plans to begin building out its 1 Gbit/s broadband service in parts of North Carolina in the next few weeks, marking its second deployment of the fiber service.

AT&T Inc. (NYSE: T) plans to bring U-verse with GigaPower to six North Carolina cities -- Carrboro, Cary, Chapel Hill, Durham, Raleigh, and Winston-Salem -- once it finalizes negotiations with the North Carolina Next Generation Network (NCNGN), a regional group spearheading network deployments. AT&T says it will begin the build-out as soon as the NCNGN's six member communities ratify an agreement.

The telco's plans call for adding public WiFi hotspots, free AT&T U-Verse with GigaPower at up to 100 public sites, fiber links to up to 100 local businesses, and free 3 Mbit/s AT&T U-verse broadband for 10 affordable housing complexes.

Google Fiber Inc. kicked off the fiber trend with its Kansas City rollout in 2012, but this will be the second time that AT&T is beating it to the punch in a new city. The first time came when AT&T launched the service in Austin, Texas, in December. (See Austin Gets Google's Next Fiber Gig.)

In Austin, AT&T is only offering 300 Mbit/s speeds for its customers, promising to bump them up to 1 Gig speeds by midyear, at which time Google's network will also be live. (See AT&T's Austin GigaPower Debuts at 300 Mbit/s .)

AT&T also announced today that it's working with PulteGroup to bring its fiber-to-the-premises network to four currently open-for-sale, single-family communities and five existing communities in the Austin area. It says it will double its deployment in Austin due to higher-than-expected demand and plans to expand to other markets, like parts of Dallas, this year and beyond.

Google has lit the competitive fire under traditional broadband providers to match its 1 Gig offer. Even small operators like C Spire are getting in the game. That regional operator plans to start offering services later this year in its home market of Mississippi in Starkville, Ridgeland, Quitman, and Horn Lake. (See C Spire Lets SPIT Percolate.)

— Sarah Reedy, Senior Editor, Light Reading

Page 1 / 3   >   >>
brookseven 4/17/2014 | 12:51:36 PM
Re: Gig for NC We were doing tests on lots of issues that speed tests were having in FiOS at the start of the deployment. We ran all kinds of tests from upstream/downstream ratios, delays, window sizes, spyware, cable tests (I can't tell you how many times we ran into 1/2 duplex issues in the field). All I can say, is that to get it to work at full speed at any given time means that all pieces are uncongested and working properly. Anything wrong and you lose just that little bit of speed. For example, 270 Mbps is only 10% off of 300 Mbps and that means that a single application would be consuming that amount of bandwidth. In most scenarios in the real world, this is either multi-application or has a lot of UDP for video. So most folks won't even notice a 10% off! unless they are running a speed test. Seven
lanbrown 4/17/2014 | 11:56:33 AM
Re: Gig for NC They have to support the window scaling option as should most computers these days; it is not necessarily "new" but something that has been around.  A speedtest would be horribly inaccurate without supporting it as would be for the computer.  64k is nothing when you are talking about large "pipe" sizes.  Of course, you have what the speedtest site says and what you will actually get when doing normal activities.
MarkC73 4/17/2014 | 11:27:04 AM
Re: Gig for NC for TCP window size, again I agree with you, but if you can do it on your side, and the server can't then you're stuck.  Thanks for clarifying.  I'm pretty sure the speedtest.net servers can do larger TCP window sizes.  I haven't tried in a very long time, so I wasn't sure.
MarkC73 4/17/2014 | 11:24:16 AM
Re: Gig for NC I was actually talking about the use of GigE LAG, which last time I've seen ATT Architecture, it has been a while, they don't particularly like to use LAG to their access gears.

We use LAG to our GPONs, the number of links used are a computation of peak utilization with a resiliency factor in-case of port or card failure.  Why, cost, 5+ years ago 10G was expensive for us so we used LAGs both in the core and access.

As we go higher in speeds, sometimes it is a challenge to convince the budget guys that we need to move from 4G LAG to a 10G interface for a single access system, when the actual utilization really doesn't justify it, but service intergity and network evolution do.

I don't disagree with anything you've stated, just to be clear, merely adding a non ATT view to the mix.  5 years ago, not all companies can do an all 10G network build to start.  So now as our trunks are moving to multiple 10G the access side is moving to single 10G

I defintely agree about the 10G interface on the test server.
lanbrown 4/17/2014 | 11:18:27 AM
Re: Gig for NC While the Window size can be changed, it is still limited as there are two windows; congestion and receive window size and since the data comes from one machine and going to another, it is negotiated in the three-way handshake.  To get around that though as in many cases, 64k is what many machines is configured for.  This is where window scaling comes into play; RFC 1323.
lanbrown 4/17/2014 | 11:08:43 AM
Re: Gig for NC Of course they would have to have moved to 10Gbit on the access side for GPON.  GPON offers roughly 2.5Gbps per link going to the splitter.


You did say this:
"Furthermore, you can't really get a good live test as most servers on the internet won't allocate you a GigE either."


So far the testing seems to work just fine.  AT&T does have their test site as well.  I just used the Verizon to make a point to your post.  Given that others most likely were using that server as well but yet I was able to consume almost 1/3 of the bandwidth if it had a 1Gbps link.  Chances are it is 10Gbps as well.

Using a remote server to test is better as it means you are really going over the Internet and not to some local server; Inter instead of Intra.
MarkC73 4/17/2014 | 11:01:55 AM
Re: Gig for NC I've dealt with mostly the Ookla or speedtest.net testing, and it's a tcp flow bursting at full bandwidth.  I don't know what max window size is in use or if each server can be configured differently to use the larger size.  Not sure about 1 ms, but latency is definetly a factor.  Outside of the one that we have and a few other local sites, the closest testservers are about minimum 50 ms RTD away.

Intersting enough, is that the hardest part about +50mbps service is education.  As some people don't hesitate to call in if they can't get 300mbps off their wireless laptop.  
brookseven 4/17/2014 | 10:44:58 AM
Re: Gig for NC My suspicion is that even small delays in the network that are natural are going to cause issues at 300Mb/s in a Speedtest unless it uses UDP.  We built spreadsheets in the past measuring Speedtest results versus ping delay from various testing sites in the US and even small (1 msec) deltas were measureable.


MarkC73 4/17/2014 | 9:44:29 AM
Re: Gig for NC The core wouldn't be an issue, and I'm sure they've upgraded their drops to their GPON to 10Gs as well.  As Nx1G LAGs are probably going to cause issues with speedtests.  The few that I've wiresharked, actually flood single tcp flows, meaning that most hashing algorithms aren't going to spread that traffic amongst link memebers.

It is interesting that Vz server lets you test from ATT, although, I guess it's not too surprising since they both don't have to pay transit costs.  I'm sure ATT will or has their own site to test to.
lanbrown 4/16/2014 | 11:12:43 PM
Re: Gig for NC I tested my 300Mbps service (currently) with Verizon's Speedtest test.  So the bits would come from Verizon throught AT&T and then to me.  The advertised speed was 300/300 and I got 315/270.


The core has been 10Gbps or higher even when they weren't offering the 300/300 or soon to be 1000/1000.  Even with 10Gbps it would still be in a LAG.


If you want to know what is used, read about GPON.
Page 1 / 3   >   >>
Sign In