I've been a COX customer for years (over a decade now), before I could even sign myself up for their service I had my mother get it in her name and I've never gone back. (I even refuse to move where I cannot get Cox now, I know what the competitors are like out here... nobody holds even a match to Cox.)
I have noticed that in the past couple years, Cox has kind of changed the network topology of our region a few times, allow me to elaborate.
When I first signed up for Cox and got my modem and service installed, I immediately started inspecting the new network I was connected to. I had learned with previous providers, that they sometimes decide to ship all your data out of state before they let you out into the internet, and load everyone along the way onto that same backbone, so by the time you hit the internet, you're fighting with not 4000 local users, but 40,000+ over 7 states, ridiculous. The good news was, when I was living in downtown Phoenix for a couple years with my initial Cox service, the typical exit point (from Cox's networks to the internet) was actually downtown Phoenix, no more than about 10 miles from where I lived. This meant I enjoyed insanely good speeds pretty much no matter where I went on the internet besides California (lots of people, lots of internet traffic, backbones clogged). I was perfectly content with this simply because the only things I regularly connected to in CA were my web host, Google, and a few favorite servers for gaming, no big loss. Pings and bandwidth tests to downtown Phoenix regularly netted full bandwidth/low response times, while tests elsewhere usually suffered because of the backbone congestion, which is understandable, that's the nature of the beast that is the internet.
Fast forward 4 years, I'm in my own apartment now having moved out, gotten a job, grown up. Cox suddenly changes the Phoenix metro area's exit point to San Jose for residential customers. This was a shock to me, I even made calls regarding this fact inquiring what the hell was going on, of course to be met with "That's just the network, nothing we can change here." I soon realized that it now caused a backwards trend in the speedtests, no longer would I get full speed from the downtown Phoenix server, but now San Jose's server (on speedtest.net) was the fastest, with Phoenix being a mere 1/3 of my best. Lucky me most of my services were still centered in CA and I had become a really heavy Google user, it also opened up servers for gaming to me with way more people as the switch in backbones meant I was now an internet user in CA, where the gamers are plentiful.
This persists to this day, Residential customers are still being shunted to San Jose to get out onto the internet, and Business class customers appear to be shunted to Los Angeles, again, no biggy when the biggest names on the internet are right around the corner from the exit point. However, it does leave quite a number of vulnerabilities in the physical network to be had... Remember the fiber cut a few years ago where anyone on Cox had no internet for about a day or two? That was somebody digging with a backhoe along the I-10 without checking first, who cut the backbone that shunts everyone's activity out of AZ and into CA for internet access. If we had our typical Phoenix exit point, we would have never experienced that, but I digress, the exit point switch to CA has been an overall benefit. The fiber carrying our service has only been cut 2 maybe 3 times in about 2 times as many years, and our overall access to the net is relatively unaffected. Barring any local issues (like oversold nodes or a failing node like I've experienced), you get full speed on tests to locations like Los Angeles and San Jose all day every day, meaning that backbone running adjacent to the I-10 has been thoroughly maintained and upgraded to carry EVERYONE in AZ's traffic without fail, and at full bandwidth too. Kudos Cox.
To bring this all home to the original topic, I've seen a lot of people running speed tests to the local Phoenix server, and getting horrible speeds, post those with questions, and in an effort to save everyone some headache and time, I'm offering the following information on how YOU, the end-user, can identify your exit point from Cox's network to the internet so you can make an informed decision on selecting a Speedtest.net server to test against (and help to show you have internal network issues, rather than a false reading from a server that, based on your exit point from Cox's network, is effectively over 300 miles away).
Run a traceroute, and if you need to, enable address to name resolution (not needed on Windows, and most Linux distros). A simple "tracert" (Win)/"traceroute" (Linux) to say google.com, or for east coast, towerstream.com should suffice to show you your exit point from Cox's networks. Here's my traceroutes from Windows to both of those locations, and I'll point out the exit point, it's very easy to identify, Cox named it!
>tracert google.com
Tracing route to google.com [74.125.224.209]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms * [192.168.0.1]
2 7 ms 7 ms * 10.XX.XXX.X
3 6 ms 5 ms 5 ms 70.169.77.32
4 6 ms 10 ms 8 ms 70.169.75.94
5 7 ms 6 ms 6 ms mcdldsrj01-ae2.0.rd.ph.cox.net [70.169.76.225]
6 18 ms 16 ms 16 ms langbprj02-ae2.rd.la.cox.net [68.1.1.19]
7 18 ms 17 ms 19 ms 216.239.46.40
8 18 ms 18 ms 17 ms 72.14.236.13
9 22 ms 17 ms 17 ms 74.125.224.209
Trace complete.
In this example, it appears that #6 is our exit point, it's the last named Cox node on the route. I have replaced the local node's internal network IP with Xs as well, this is just out of courtesy for Cox.
Now that we have a potential candidate for our exit point from Cox's network, let's corroborate it with another traceroute to towerstream.com this time...
C:\Users\Cynagen>tracert towerstream.com
Tracing route to towerstream.com [66.228.71.5]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms * [192.168.0.1]
2 15 ms * 4 ms 10.XX.XXX.X
3 5 ms 6 ms 5 ms 70.169.77.34
4 6 ms 5 ms 5 ms 70.169.75.90
5 5 ms 4 ms 4 ms chnddsrj01-ae2.0.rd.ph.cox.net [70.169.76.229]
6 16 ms 16 ms 16 ms langbprj01-ae2.rd.la.cox.net [68.1.1.17]
7 17 ms 17 ms 17 ms xe-2-2-0.cr2.lax112.us.above.net [64.125.31.194]
8 43 ms 43 ms 43 ms xe-3-2-0.cr2.iah1.us.above.net [64.125.30.49]
9 73 ms 104 ms 73 ms xe-3-1-0.cr2.dca2.us.above.net [64.125.30.54]
10 81 ms 82 ms 82 ms xe-1-1-0.mpr4.bos2.us.above.net [64.125.24.117]
11 83 ms 81 ms 83 ms xe-1-0-0.mpr3.bos2.us.above.net [64.125.25.65]
12 83 ms 90 ms 82 ms 64.124.51.229.t495-rtr.towerstream.com [64.124.51.229]
13 81 ms 82 ms 82 ms ww1.towerstream.com [66.228.71.5]
Trace complete.
Again, we see that #6 is the last named (lang=Los Angeles, and la.cox.net=Los Angeles), and #7 is completely different, that's because we're now tracking east along Above.net's backbone to the east cost to hit Towerstream's servers.
This means that while I may be a physical resident of the Phoenix metro area, and my IP address when you get the reverse name lookup for it, it says "ph.ph.cox.net", meaning I'm from Phoenix metro, my internet connection really begins in California. Therefore all my speed tests should be run from the LA/SJ locations and only those locations as they're going to give me the most accurate result for what Cox is providing me, and trust me, Cox is definitely providing the bandwidth they sell me.
I encourage all forum-goers to get into this practice, it'll explain a lot of your concerns very very quickly. Slow browse to a website? Trace it, if you see high pings along the route, there's your problem, and if they're AFTER Cox's last point in the route, don't bother Cox, they can't help you. If you're not getting your bandwidth, do the same general traces that I did to both google.com and towerstream.com to get your actual exit point and run a speedtest from a server in the same city, see if you're actually getting limited INSIDE Cox's network, not by some external influence they can't do anything about.
This kind of practice is not uncommon for internet service providers like Cox. Like I mentioned earlier, my previous DSL provider shunted all my connections off to Chicago before I could get anywhere on the internet, and their backbone was usually overloaded by the time my packets reached Chicago only to be routed right back down the same pipe to get a local website. They do this because it's cost inefficient or prohibitive to make your exit point your local area, so it's cheaper to shunt off your requests to another exit point nearby (subjective term, I know).
Coming from doing tech support for a huge competitor, I saw a similar situation where the backbones outside our network were congested with traffic, and I was forced to repeatedly tell customers there's nothing I could do, only to get yelled at. I understand what it's like to be on the other end of the phone, getting yelled at because of something that's out of our control, while the information is available to even the end customer who's too lazy to do the research or read a post like this one and educate themselves. They say knowledge is power, it's completely and utterly true, and I challenge each and every one of you that actually sat down to read this mammoth post, to keep yourself educated about your internet connection, you never know when you might know MORE about an outage situation than the tech you're talking to on the phone! (Had that happen once before.)
Now go out and get a grip, on the internet that is. It's a mammoth beast, but with a few simple commands, some common sense, and maybe a little bit of detective work, you can bring it down to literally a line and try to isolate the problem on your own.
For those trying to self-troubleshoot a slow website, or gaming server, this can be invaluable information to determine where the issue may lie, and who you should be talking to about getting it fixed.
TL;DR: Why did you bother clicking on this post if you're going to skip to a meaningless tag... C'mon... Go read and educate yourself!