Sonic Fiber vs AT&T Fiber offering....

[tweakoz]

(Sorry for the double post, I was not logged in on the above - and did not notice until I had submitted it)
The administrator is free to delete the above post if they wish.

Hi, New Sonic customer here..

I just had AT&T Internet 1000 installed last week. I was horrified at the experience. The tech came out on time and the installation itself was fine. The performance on the other hand was awful. It can barely manage 20mbps DL and 3mbps UL on average speedtests. One speedtest server has occasionally surpassed 100mbps and once in the last week I have seen it hit 300mbps (All of these numbers are from a wired, dual gigabit enabled supermicro dual xeon motherboard with cat 6 and cat 5e cable - running Linux). Of course those are speedtest numbers. Real world performance, it averages 20mbps - thats downloading from http, scp, iperf3, git, etc... I had to wonder if the line was damaged - though the fact that it peaked at 300mbps and the asymmetry of it leads me to believe that its just being shaped into mediocrity.

I then proceeded to engage customer support. It became obvious at that point AT&TCares(tm) really does not. Lots of research later (Which I probably should had done prior to getting AT&T) and I came into awareness of Sonic being available in my area. Based on the impressions of the customer support alone and seeing that the CEO actively participates in the forums, and that the company seems generally progressive, I went ahead and ordered the Sonic+AT&T gigabit fiber and am cancelling the Stock AT&T service. I am disappointed that AT&T is still technically running the new line, but hopeful that the customer support difference will be worth it.

I do have a few technical questions to which the answers are still unclear after a fair amount of research:

1. Can we connect directly to the ONT? I would prefer to not use the Pace RG and use my own infrastructure. I am aware of the HW and SW requirements needed in a gigabit system (I manage 10G and Infiniband networks @ my day job). I have seen posts on the AT&T forums about people doing this with custom connection scripts feeding authentication bytes to the ONT - So I know its technically possible even with stock AT&T. The question is - is omitting the Pace RG permitted with Sonic+AT&T? I am even OK renting the Pace RG and keeping it around for Sonic's remote diagnostic needs. But day to day I want to use equipment I can tweak to my specifications. As far as support goes, if Sonic can manage the "ONT to Internets" side of things, I can handle my own network.

2. I have read elsewhere that Sonic+AT&T DSL is rebranded Enterprise UVerse. Is the Enterprise part also true of AT&T+Sonic Gigabit Fiber ? Or put another way - Given that AT&T is still still in the path, how exactly will the traffic shaping differ from stock AT&T? - I get that there will be no data quantity cap (which was also true with Internet 1000). Am I going to be stuck with the same 20mbps DL and 3mbps UL? Beyond Family Comms, and media consumption, I do a fair amount of network related software development, both professionally and for fun @ home. The throttling pretty much makes it useless for that. I just want my ISP to keep their hands off the bits I had paid for. Even the 600mbps symmetric (60%) AT&T supposedly guarantees would be a far cry from the 20mbps (2%) I am getting.

3. Stock AT&T offers a 5 Static IP option for $15/mo. Just curious why Sonic does not. I can of course fake it through various means - but It would be nice to have at least 1 static IP built in...

Thanks,
mtm

[timyu94]

(Sorry for the double post, I was not logged in on the above - and did not notice until I had submitted it)
The administrator is free to delete the above post if they wish.

Thanks,
mtm

If you were using the Pace 5268ac is dmz+ then that was issue as A recent ATT firmware broke that and caused substantial throughput issues to any devices after it connected via dmz+ mode.

The BGW210-700 and older Arris 589/599 RGs with ip passthrough work fine.

--- you cannot replace the ATT RGs as they used embedded 802.1x certificates in them for authentication. With a managed switch you can be able to clone it and then toss the RG aside but any reboot or power outage will revert the settings and need to have the entire process redone.

[tweakoz]

--- you cannot replace the ATT RGs as they used embedded 802.1x certificates in them for authentication. With a managed switch you can be able to clone it and then toss the RG aside but any reboot or power outage will revert the settings and need to have the entire process redone.

Apparently, you can bridge the RG with the ONT and your router.
(802.1x auth goes to RG, everything else to your router)

https://www.dslreports.com/forum/r29903 ... ~start=264

https://github.com/aus/pfatt

On another note, I thought I read elsewhere on Sonic forums that Sonic Pace 5286ac's use Sonic Firmware ?

mtm

[bmah]

EDIT: D'oh. I thought I was posting this in a different thread. Oh well, it's on-topic here too.

After having used this (AT&T fiber resold by Sonic) service for a few days, a few comments and observations:

1. It feels kind of weird and stupid to have the AT&T gateway between the ONT and my pfSense box, but it actually works reasonably well. I'm using DMZ+ mode. I've downloaded multi-GB ISO images (think FreeBSD or CentOS distribution DVDs) at around 600Mbps over IPv6. Obviously a lot of other pieces besides the last-mile link contribute to network performance, but I'm mildly impressed.

2. IPv6 on AT&T's service actually works. Mostly. They delegate a /64, which pfSense is able to advertise to one LAN. Weirdly it appears that the AT&T gateway has a /60 allocated to it (inferred based on the address given to pfSense plus the prefix delegation). It's kind of dumb that they can't delegate something a teensy bit larger...like I'd really love about /62 or so but all my attempts to get a larger IPv6 delegation just result in getting the same /64.

3. AT&T seems to block IP protocol 41, which is used by GIF tunnels commonly used to implement for example, Hurricane Electric's IPv6 tunnel service. I used this over my soon-to-be-ex-Comcast connection so that I could have fixed IPv6 addresses...I'm not sure what a good workaround is. "A" workaround which I am currently doing is to set up an OpenVPN connection over the AT&T fiber to sonic.net's VPN server and do the Hurricane Electric tunnel over that. (Can I get an "Ewwwww" from the crowd?)

4. @tweakoz: With respect to the "hands off my bits", we've received reassurances from sonic.net (see elsewhere on these forums) that AT&T is contractually prohibited from throttling / capping / filtering our connections. Whether you believe this or not is up to you (I do...possibly with the exception of #3 above...FWIW I'm also a software guy who works for an R&E network provider and a sonic.net customer since around 2003).

5. The switch-over of my home landline number from the old FTTN (and ATA) to the new fiber (and ATA) went smoothly in retrospect, although at the time it seemed a little confusing what was going on and what my expectations should have been. One actual bug is that there is a little quickstart card that comes with the ATA that mentions waiting until the lights turn "green", except the lights on the currently shipping ATA are blue.

Hope this is helpful...

Bruce.

[tweakoz]

I figured out some more info about my slow downloads:

I think the slow download is mainly due to the insanely slow upload.
eg. TCP acks are the bottleneck.

iperf3 udp runs close to line speed (With ~100% packetloss)
iperf3 tcp is slow

Running iperf3 -b 2G -c iperf.scottlinux.com - still results in the same ~955mbps BW figure.

not quite sure what this is indicative of, poor line quality, or just dropped packets?

This computer is plugged directly into the RG.

mtm

Code: Select all

xyz@ix:~$ iperf3 -b 1G -c iperf.scottlinux.com
Connecting to host iperf.scottlinux.com, port 5201
[  4] local 192.168.1.40 port 35404 connected to 45.33.39.39 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   397 KBytes  3.26 Mbits/sec    0   23.7 KBytes       
[  4]   1.00-2.00   sec   251 KBytes  2.06 Mbits/sec    0   34.9 KBytes       
[  4]   2.00-3.00   sec   314 KBytes  2.57 Mbits/sec    0   46.0 KBytes       
[  4]   3.00-4.00   sec   251 KBytes  2.06 Mbits/sec    0   57.2 KBytes       
[  4]   4.00-5.00   sec   314 KBytes  2.57 Mbits/sec    0   73.9 KBytes       
[  4]   5.00-6.00   sec   439 KBytes  3.60 Mbits/sec    0    113 KBytes       
[  4]   6.00-7.00   sec   502 KBytes  4.11 Mbits/sec    0    165 KBytes       
[  4]   7.00-8.00   sec   628 KBytes  5.14 Mbits/sec    0    234 KBytes       
[  4]   8.00-9.00   sec   628 KBytes  5.14 Mbits/sec    0    312 KBytes       
[  4]   9.00-10.00  sec   816 KBytes  6.68 Mbits/sec    0    423 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  4.43 MBytes  3.72 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  2.57 MBytes  2.16 Mbits/sec                  receiver

iperf Done.
xyz@ix:~$ iperf3 -u -b 1G -c iperf.scottlinux.com
Connecting to host iperf.scottlinux.com, port 5201
[  4] local 192.168.1.40 port 33373 connected to 45.33.39.39 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec   103 MBytes   860 Mbits/sec  13130  
[  4]   1.00-2.00   sec   114 MBytes   955 Mbits/sec  14577  
[  4]   2.00-3.00   sec   114 MBytes   955 Mbits/sec  14580  
[  4]   3.00-4.00   sec   114 MBytes   955 Mbits/sec  14575  
[  4]   4.00-5.00   sec   114 MBytes   955 Mbits/sec  14577  
[  4]   5.00-6.00   sec   114 MBytes   955 Mbits/sec  14577  
[  4]   6.00-7.00   sec   114 MBytes   955 Mbits/sec  14580  
[  4]   7.00-8.00   sec   114 MBytes   956 Mbits/sec  14580  
[  4]   8.00-9.00   sec   114 MBytes   955 Mbits/sec  14574  
[  4]   9.00-10.00  sec   114 MBytes   955 Mbits/sec  14578  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.10 GBytes   946 Mbits/sec  89.074 ms  137644/137746 (1e+02%)  
[  4] Sent 137746 datagrams

iperf Done.

[gtwrek]

[

If you were using the Pace 5268ac is dmz+ then that was issue as A recent ATT firmware broke that and caused substantial throughput issues to any devices after it connected via dmz+ mode.

The BGW210-700 and older Arris 589/599 RGs with ip passthrough work fine.

Any references to this problem? I think this is hitting me. I'll measure my throughput again at home, but I'm having real trouble lately with my 1 gig ATT service. It may be this: https://forums.att.com/t5/AT-T-Fiber-Eq ... 485/page/2

Bringing this back to Sonic - as inferred I'm currently an ATT 1 Gig fiber customer, and have noticed that now Sonic pre-qual's me for the new Sonic 1 gig over ATT. I'm just wondering however, along with many in this thread - these random issues that are cropping up on ATT's network. Will we get the same issues with Sonic's solution?

I know I'll receive better support from Sonic. Just hesitating pulling the trigger.

Regards,
Mark

[timyu94]

[

If you were using the Pace 5268ac is dmz+ then that was issue as A recent ATT firmware broke that and caused substantial throughput issues to any devices after it connected via dmz+ mode.

The BGW210-700 and older Arris 589/599 RGs with ip passthrough work fine.

Any references to this problem? I think this is hitting me. I'll measure my throughput again at home, but I'm having real trouble lately with my 1 gig ATT service. It may be this: https://forums.att.com/t5/AT-T-Fiber-Eq ... 485/page/2

Bringing this back to Sonic - as inferred I'm currently an ATT 1 Gig fiber customer, and have noticed that now Sonic pre-qual's me for the new Sonic 1 gig over ATT. I'm just wondering however, along with many in this thread - these random issues that are cropping up on ATT's network. Will we get the same issues with Sonic's solution?

I know I'll receive better support from Sonic. Just hesitating pulling the trigger.

Regards,
Mark

Top stickied post on the forum you linked.

https://forums.att.com/t5/AT-T-Fiber-Eq ... -p/5700776

Sonic resold ATT is the same with either FTTN or Fiber.

It's on ATT IP space, ATT equipment, and goes through the ATT network and supported by ATT personnel. The primary difference is their enterprise agreement which gets rid of them selling your information and tracking what you do (supposedly) plus unlimited data. Sonic acts as the middleman between yourself and ATT but otherwise they can't do much other than open tickets & call / message ATT themselves on your behalf.

[gtwrek]

Top stickied post on the forum you linked.

https://forums.att.com/t5/AT-T-Fiber-Eq ... -p/5700776

Sonic resold ATT is the same with either FTTN or Fiber.

It's on ATT IP space, ATT equipment, and goes through the ATT network and supported by ATT personnel. The primary difference is their enterprise agreement which gets rid of them selling your information and tracking what you do (supposedly) plus unlimited data. Sonic acts as the middleman between yourself and ATT but otherwise they can't do much other than open tickets & call / message ATT themselves on your behalf.

Gah - just spent an hour reading through that thread. I can only shake my head in disbelief. I'm confident I have the problems detailed in that thread. I'm sighing how I'll have to jump though the hoops tonight with ATT support to try and resolve (basically getting ATT to ship an RG other than the Pace 5268ac. (With a roll of the dice on whether the new RG the send is what they promised or not...)

I've dealt with Sonic support before, and know they're on top of their game. I've got to think that Sonic would be on top of a bad firmware update from ATT better than I would deal with it alone. Right?

It sure would help me (and others) if someone from Sonic could even give a head nod, nudge, wink or whatever that they know about these sorts of things and that they would deal with ATT better.

[dane]

I've dealt with Sonic support before, and know they're on top of their game. I've got to think that Sonic would be on top of a bad firmware update from ATT better than I would deal with it alone. Right?

It sure would help me (and others) if someone from Sonic could even give a head nod, nudge, wink or whatever that they know about these sorts of things and that they would deal with ATT better.

I'd like to think we'd be able to get resolution, and it'd certainly be more transparent and less frustrating, but sometimes it is like trying to push an elephant, and even we are not always successful at that. So, I can nod, nudge and wink and say "yeah, it's likely to be better over here working with us", but I can't promise an assured outcome, because, at the root, it's not my network.

And clearly, this is why we're so focused on building our own last-mile fiber: we care deeply about the customer experience and reliability from the premise (including WiFi) to the internet, peers, CDN and transport. And being able to dispatch, fix, troubleshoot and resolve everything in the middle is our real goal. But, it takes time to build those networks, and meanwhile, we also leverage these off-net products, with whatever warts they've got.

[bmah]

I figured out some more info about my slow downloads:

I think the slow download is mainly due to the insanely slow upload.
eg. TCP acks are the bottleneck.

iperf3 udp runs close to line speed (With ~100% packetloss)
iperf3 tcp is slow

Running iperf3 -b 2G -c iperf.scottlinux.com - still results in the same ~955mbps BW figure.

not quite sure what this is indicative of, poor line quality, or just dropped packets?

This computer is plugged directly into the RG.

Other posters have commented on the likely culprit (bad firmware loaded on an AT&T Pace gateway). I've read about people being able to get gateways swapped out, say for the Arris BGW210. Hopefully you can do that, or AT&T can just fix their firmware.

A couple things related to your use of iperf3 to test performance:

You probably don't need to use the the -b option with TCP tests...iperf3 will always use TCP's flow/congestion control to find the highest throughput the path can support. (-b limits the speed the sender will send at, but TCP may reduce that speed if the path can't handle it.)

With UDP, the sender will always send at the speed set by -b, regardless of the ability of the path to forward them. So that measurement didn't tell you much of anything.

Good luck!

Bruce
(iperf3 maintainer)