You are currently browsing articles tagged traceroute.

I’ve left two messages with the very nice senior tech guy who came out on Monday and confirmed the problem without solving it. Another guy came yesterday when the problem wasn’t happening, and gave me the number of the senior guy to call.

Anyway, no response so far. Meanwhile, the usual: hjigh ping times and traceroutes that show the big latency starting at the first hop: inside Cox’s network.

A smart tech friend, suggests we just replace the cable modem and its power supply. Can’t hurt. Of course, that’s Cox’s gear and their job, and they’re awol, still.

Meanwhile, the quanity of work not getting done is huge.

If I had a choice of carriers, I’d switch in a heartbeat, but I don’t. Verizon is the only alternative, and my house is too far from a central office to get competitive data speeds. So, not much leverage there.

Another friend suggests calling the CEO’s office. If I don’t hear back from the senior tech guy today, I’ll try that in the morning.

Tags: , , , , ,

Starting a few days ago, nothing outside my house on the Net has been closer than about 300 miliseconds. Even, which I can see from here, is usually no more than 30 ms away on a ping test. Here’s the latest:

PING ( 56 data bytes
64 bytes from icmp_seq=0 ttl=52 time=357.023 ms
64 bytes from icmp_seq=1 ttl=52 time=369.475 ms
64 bytes from icmp_seq=2 ttl=52 time=389.372 ms
64 bytes from icmp_seq=3 ttl=52 time=414.025 ms
64 bytes from icmp_seq=4 ttl=52 time=428.384 ms
64 bytes from icmp_seq=5 ttl=52 time=28.120 ms
64 bytes from icmp_seq=6 ttl=52 time=164.643 ms
64 bytes from icmp_seq=7 ttl=52 time=292.241 ms
64 bytes from icmp_seq=8 ttl=52 time=332.866 ms
64 bytes from icmp_seq=9 ttl=52 time=330.573 ms
64 bytes from icmp_seq=10 ttl=52 time=369.385 ms
64 bytes from icmp_seq=11 ttl=52 time=375.593 ms
64 bytes from icmp_seq=12 ttl=52 time=405.028 ms
64 bytes from icmp_seq=13 ttl=52 time=413.990 ms
64 bytes from icmp_seq=14 ttl=52 time=437.124 ms

It’s been this way for days. I can’t get a human at Cox, our carrier, so I thought I’d ask the tech folks among ya’ll for a little diagnostic help.

Here is a traceroute:

traceroute to (, 64 hops max, 40 byte packets
1 (  5.828 ms  3.061 ms  2.840 ms
2 (  324.824 ms  352.686 ms  358.682 ms
3 (  359.635 ms  369.743 ms  372.376 ms
4 (  386.039 ms  389.809 ms  415.532 ms
5 (  430.554 ms  447.079 ms  423.461 ms
6  te4-1–… (  464.229 ms  453.908 ms  423.090 ms
7 (  206.217 ms  251.298 ms  261.263 ms
8  dc-lax-core1– (  264.824 ms  284.859 ms  285.808 ms
9  dc-lax-agg2– (  289.834 ms  307.450 ms  313.997 ms
10  dc-ucsb– (  323.183 ms  331.668 ms  345.606 ms
11  r2–r1– (  340.756 ms  377.695 ms  375.946 ms
12 (  365.500 ms  397.311 ms  393.919 ms

Looks to me like the problem shows up at the second hop. Any guesses as to what that is? Yes, I’ve rebooted the cable modem, many times. No difference.

I’m talking now over my Sprint data card. EVDO over the cell system. Latencies run around 70-90 ms. So the problem is clearly one with Cox, methinks.

I’m only home from the Live Oak Festival for a shower, so I’ll leaving again in a few minutes and won’t get around to dealing with this (or anything) until tomorrow. Just wanted to get the question out there to the LazyWeb in the meantime. If the problem really is Cox’s, I’d like to know what to tell them when I go down to their office. No use calling on the phone. Too many robots.

Happy solstice, everybody. And thanks!

Tags: , , ,