Fast speedtest, very slow wifi browsing

I have similar issues, I suspect the problem is ATT throttling our bandwidth somewhere upstream   All of the usual speed tests that I have tried show my speed is very high (> 300mbps), except the test at www.speedof.me.  This test uses large blocks of data to simulate streaming services.  When I run this one it shows my download speed is only 12 mbps, which is more in line with the actual performance I am seeing.

I left ATT 2 years ago because of their misleading speed.  Made the mistake of going back to them when fiber got installed in the neighborhood.  All was well for first 3 months, now all of the sudden I am back to not being able to consistently stream video.

Try www.speedof.me  to see your real internet speed performance.

Same issue. Any resolutions?

The problem relates to the tower. In another post, I found someone who said that the tower optimizes signal causing bad browsing. When you plug in an external hotspot to the tower it works far better.

I've noticed weird very large latency spikes on my AT&T internet lately. High latency would cause long pauses before page loads but speeds to be ok. Try running the BGW-210 built in speed test and make note of what your "average latency" is on the test. As long as you have not change your BGW-210's ip address this should get you to the speed test page. 192 dot 168 dot 1 dot 254 /cgi-bin/speed.ha

I have to type it weird because last time I didn't AT&T removed it saying it was unsafe to post my IP address even though that is a local network IP and useless to anyone else....

I've been doing traceroute tests to different sites over the past few days. I'm seeing one specific AT&T server/router (mainly, sometimes it's a core router in dallas) experiencing latency spikes of 200,400 even as high as 1,000+ MS (normal is ~20MS BTW) sometimes 2 or 3 times a min sometimes every 5 mins. It's very random spikes. on dslreports.com in the AT&T internet forums there have been several threads made of people noticing similar problems all over AT&T's service area going back 2 months +.

Interesting find. I'm going to have to run a traceroute from my end and see if I hit the same router. Do you have note of the ipv4/ipv6 of the router so I can see if we are both having the same issue? I wonder if I can get its startup-configuration and running-configuration and figure out if someone put the wrong commands in.

@sean8102 , when you see the latency spike on that core router, have you immediately checked the latency for the next hop?

Often the latency is only for packets that have an expired TTL and need an error reply generated and not for traffic that passes through normally.  If the next hop doesn't have noticeable latency when the "affected" hop does, then the "affected" hop really doesn't have high latency either.

@JefferMC I know ICMP packets get de prioritized. But there is def something wrong. I had this exact same issue once before back in November. It started out of nowhere, lasted 4 days then went away. I found this website for testing latency and packet loss.

Packet Loss Test – Test Your Connection Quality

(the default pre set comes out ok usually, it's the 1080p game stream / GeForce Now pre set that has horrible results, funny how I noticed this was happening again because of huge bursts of packet loss / latency spikes while using GeForce Now)

It dose NOT use ICMP. It uses WebRTC. This is the site's page explaining how it works. I can run one test and get a fairly good result (consistent latency, no packet losss) run the test again and get long spikes into 1000+ MS latency . Sometimes lots of packet loss. It varies wildly.

This would explain my random bursts of packet loss when trying to use the GeForce Now game streaming service. The screenshot im attaching now I ran just now at 3AM so I have a hard time believing it has anything to do with traffic levels. Sure wish @ATTHelp  would.... help

WebRTC is a tool used by applications executing in a browser.  It is not, in itself, a network protocol.  It is a means to be able to do something other than HTTP/HTTPS over TCP/IP from a browser page/app.

The tool you used does show true packet latency and loss to a particular server.  It cannot tell you where that is occurring along the way.

I'm not saying that AT&T doesn't have a problem.  I'm just trying to be sure that you diagnose the failed node properly.

@JefferMC Fair enough. I don't know of any troubleshooting I can do to prove where the problem is along the chain. I do find it interesting that even using my VPN produces the exact same results, on different computers (all using ethernet directly to the gateway of course). The gateways built in tracert shows the same latency spike at the same hop as pingplotter.

But really it dose not matter. Say I find a way that proves 100 percent where the problem is, it's in AT&T's network etc. What then? No one from AT&T I can reach will be able to do anything about it. They will just blow smoke up my you know what saying they will "look into it". I give up. It's a shame my service was literally perfect for 5 years and now this junk. But their built in speed test on the gateway shows 100/20 and 40-50 MS so AT&T can say not our problem. Maybe like last time these massive latency spikes started out of nowhere back in November and lasted 4 days, it will just go away randomly in a couple of days this time as well. 

Depending on the first level CSRs you reach, you can sometimes get them to, or get by them to someone who will, actually open a ticket for you.  If you know the node having an issue, you can speed the resolution.  If you can convince me you have pinpointed an issue, I will use the meager back channels I have access to try to get you some attention.

The traceroute in the screenshot doesn't prove anything for the reasons stated earlier... the nodes behind it are responding fine, and since that node had to pass the traffic to the nodes behind it that are responding fine, it must be doing normal processing fine, at least at the moment this traceroute was taken.  Generating an error response is a much different task than passing traffic.  You have to see a sustained increase in latency that persists past a hop to point to the hop (or the link in front of it).