Major props to Cox for cranking up my speeds to 18Mb/s downstream and 4Mb/s upstream. That totally rocks.
I’m getting that speed now. Here’s what Cox’s local diagnostic tool says:
TCP/Web100 Network Diagnostic Tool v5.4.12
click START to begin
Connected to: speedtest.sbcox.net – Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client-to-server [C2S]) . . . . . 3.79Mb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 18.04Mb/s
The slowest link in the end-to-end path is a 10 Mbps Ethernet subnet
Information: Other network traffic is congesting the link
That won’t last. The connection will degrade again, or go down completely. Here we go:
Connected to: speedtest.sbcox.net – Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client-to-server [C2S]) . . . . . 738.0kb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 15.09Mb/s
Your Workstation is connected to a Cable/DSL modem
Information: Other network traffic is congesting the link
[C2S]: Packet queuing detected
Here’s a ping test to Google.com:
PING google.com (74.125.127.100): 56 data bytes
64 bytes from 74.125.127.100: icmp_seq=0 ttl=246 time=368.432 ms
64 bytes from 74.125.127.100: icmp_seq=1 ttl=246 time=77.353 ms
64 bytes from 74.125.127.100: icmp_seq=2 ttl=247 time=323.272 ms
64 bytes from 74.125.127.100: icmp_seq=3 ttl=246 time=343.178 ms
64 bytes from 74.125.127.100: icmp_seq=4 ttl=247 time=366.341 ms
64 bytes from 74.125.127.100: icmp_seq=5 ttl=246 time=385.083 ms
64 bytes from 74.125.127.100: icmp_seq=6 ttl=246 time=406.209 ms
64 bytes from 74.125.127.100: icmp_seq=7 ttl=246 time=434.731 ms
64 bytes from 74.125.127.100: icmp_seq=8 ttl=246 time=444.653 ms
64 bytes from 74.125.127.100: icmp_seq=9 ttl=247 time=474.976 ms
64 bytes from 74.125.127.100: icmp_seq=10 ttl=247 time=472.244 ms
64 bytes from 74.125.127.100: icmp_seq=11 ttl=246 time=488.023 ms
No packet loss on that one. Not so on the next, to UCSB, which is so close I can see it from here:
PING ucsb.edu (128.111.24.40): 56 data bytes
64 bytes from 128.111.24.40: icmp_seq=0 ttl=52 time=407.920 ms
64 bytes from 128.111.24.40: icmp_seq=1 ttl=52 time=427.506 ms
64 bytes from 128.111.24.40: icmp_seq=2 ttl=52 time=441.176 ms
64 bytes from 128.111.24.40: icmp_seq=3 ttl=52 time=456.073 ms
64 bytes from 128.111.24.40: icmp_seq=4 ttl=52 time=237.366 ms
64 bytes from 128.111.24.40: icmp_seq=5 ttl=52 time=262.868 ms
64 bytes from 128.111.24.40: icmp_seq=6 ttl=52 time=287.270 ms
64 bytes from 128.111.24.40: icmp_seq=7 ttl=52 time=307.931 ms
64 bytes from 128.111.24.40: icmp_seq=8 ttl=52 time=327.951 ms
64 bytes from 128.111.24.40: icmp_seq=9 ttl=52 time=352.974 ms
64 bytes from 128.111.24.40: icmp_seq=10 ttl=52 time=376.636 ms
ç64 bytes from 128.111.24.40: icmp_seq=11 ttl=52 time=395.893 ms
^C
— ucsb.edu ping statistics —
13 packets transmitted, 12 packets received, 7% packet loss
round-trip min/avg/max/stddev = 237.366/356.797/456.073/69.322 ms
That’s low to UCSB, by the way. I just checked again, and got 9% and 25% packet loss. At one point (when the guy was here this afternoon), it hit 57%.
Here’s a traceroute to UCSB:
traceroute to ucsb.edu (128.111.24.40), 64 hops max, 40 byte packets
1 192.168.1.1 (192.168.1.1) 0.687 ms 0.282 ms 0.250 ms
2 ip68-6-40-1.sb.sd.cox.net (68.6.40.1) 349.599 ms 379.786 ms 387.580 ms
3 68.6.13.121 (68.6.13.121) 387.466 ms 400.991 ms 404.500 ms
4 68.6.13.133 (68.6.13.133) 415.578 ms 153.695 ms 9.473 ms
5 paltbbrj01-ge600.0.r2.pt.cox.net (68.1.2.126) 16.965 ms 18.286 ms 15.639 ms
6 te4-1–4032.tr01-lsanca01.transitrail.ne… (137.164.129.15) 19.936 ms 24.520 ms 20.952 ms
7 calren46-cust.lsanca01.transitrail.net (137.164.131.246) 26.700 ms 24.166 ms 30.651 ms
8 dc-lax-core2–lax-peer1-ge.cenic.net (137.164.46.119) 44.268 ms 98.114 ms 200.339 ms
9 dc-lax-agg2–lax-core2-ge.cenic.net (137.164.46.112) 254.442 ms 277.958 ms 273.309 ms
10 dc-ucsb–dc-lax-dc2.cenic.net (137.164.23.3) 281.735 ms 313.441 ms 306.825 ms
11 r2–r1–1.commserv.ucsb.edu (128.111.252.169) 315.500 ms 327.080 ms 344.177 ms
12 128.111.4.234 (128.111.4.234) 346.396 ms 367.244 ms 357.468 ms
13 * * *
As for modem function, I see this for upstream:
Cable Modem Upstream
Upstream Lock : Locked
Upstream Channel ID : 11
Upstream Frequency : 23600000 Hz
Upstream Modulation : QAM16
Upstream Symbol Rate : 2560 Ksym/sec
Upstream transmit Power Level : 38.5 dBmV
Upstream Mini-Slot Size : 2
… and this for downstream:
Cable Modem Downstream
Downstream Lock : Locked
Downstream Channel Id : 1
Downstream Frequency : 651000000 Hz
Downstream Modulation : QAM256
Downstream Symbol Rate : 5360.537 Ksym/sec
Downstream Interleave Depth : taps32Increment4
Downstream Receive Power Level : 5.4 dBmV
Downstream SNR : 38.7 dB
The symptoms are what they were when I first blogged the problem on June 21, and again when I posted a follow-up on June 24. That was when the Cox service guy tightened everything up and all seemed well … until he left. When I called to report the problem not solved Cox said they would send a “senior technician” on Friday. A guy came today. The problems were exactly as we see above. He said he would have to come back with a “senior technician” (or whatever they call them — I might be a bit off on the title), which this dude clearly wasn’t. He wanted the two of them to come a week from next Wednesday. We’re gone next week anyway, but I got him to commit to a week from Monday. That’s July 6, in the morning. The problem has been with us at least since the 18th, when I arrived here from Boston.
This evening we got a call from a Cox survey robot, following up on the failed service visit this afternoon. My wife took the call. After she indicated our dissatisfaction with the visit (by pressing the appropriate numbers in answer to a series of questions), the robot said we should hold to talk to a human. Then it wanted our ten-digit Cox account number. My wife didn’t know it, so the robot said the call couldn’t be completed. And that was that.
I doubt another visit from anybody will solve the problem, because I don’t think the problem is here. I think it’s in Cox’s system. I think that’s what the traceroute shows.
But I don’t know.
I do know that this is inexcusably bad customer service.
For Cox, in case they’re reading this…
- I am connected directly to the cable modem. No routers, firewalls or other things between my laptop and the modem.
- I have rebooted the modem about a hundred times. I have re-started my computers. In fact I have tested the link with three different laptops. Same results. Re-booting sometimes helps, sometimes not.
- Please quit trying to fix this only at my end of the network. The network includes far more than me and my cable modem.
- Please make it easier to reach technically knowledgeable human beings.
- Make your chat system useful. At one point the chat person gave me Linksys’ number to call.
- Thanks for your time and attention.