To their credit, fixing my problem has become a higher priority with Cox. A senior guy came out today, confirmed the problem (intermittent high latencies and packet losses), made some changes that adjusted voltages at the modem, and found by tracing the coax from our house to the new pole behind it that the guys who installed the pole nearly severed the coax when they did it. So he replaced that part of the line and brought the whole pole situation up closer to spec… for a few minutes.
Alas, the problem is still there. The engineer from Cox duplicated the problem on his own laptop, so he told me the ball is still in Cox’s court.
At its worst the problem is so bad, in fact, that this was as far as I got with my last ping test:
PING google.com (74.125.67.100): 56 data bytes
64 bytes from 74.125.67.100: icmp_seq=2 ttl=56 time=101.462 ms
^C
— google.com ping statistics —
9 packets transmitted, 1 packets received, 88% packet loss
The guy from Cox said my plight had been escalated, and has the attention of higher-up engineers there. He also said they’d come out to continue trouble-shooting the problem. “Probably by Thursday.”
We’ve had the problem since June 17.
Meanwhile, I’m connecting to the Net and posting this through my Sprint datacard, just like I did last week in Maryland. Same results: good connections, adequate speeds and awful latencies:
dsearls2$ ping harvard.edu
PING harvard.edu (128.103.60.28): 56 data bytes
64 bytes from 128.103.60.28: icmp_seq=0 ttl=235 time=1395.515 ms
64 bytes from 128.103.60.28: icmp_seq=1 ttl=235 time=750.396 ms
64 bytes from 128.103.60.28: icmp_seq=2 ttl=235 time=295.272 ms
64 bytes from 128.103.60.28: icmp_seq=3 ttl=235 time=823.698 ms
64 bytes from 128.103.60.28: icmp_seq=4 ttl=235 time=1404.692 ms
64 bytes from 128.103.60.28: icmp_seq=5 ttl=235 time=1360.761 ms
64 bytes from 128.103.60.28: icmp_seq=6 ttl=235 time=803.610 ms
64 bytes from 128.103.60.28: icmp_seq=7 ttl=235 time=446.081 ms
64 bytes from 128.103.60.28: icmp_seq=8 ttl=235 time=554.643 ms
64 bytes from 128.103.60.28: icmp_seq=9 ttl=235 time=425.423 ms
^C
— harvard.edu ping statistics —
12 packets transmitted, 10 packets received, 16% packet loss
For work such as this blog post, which seems to require lots of dialog between my browser and WordPress at the server, the latencies are exasperating, because there’s so much dialog between server and client. I watch the browser status bar say “Connecting to blogs.law.harvard.edu…”, “Waiting for blogs.law.harvard.edu…” and “Transferring from blogs.law.harvard.edu…” over and over and over for a minute or more, every time I click on a button (such as “save draft” or “publish”).
So don’t expect to read much here until we finally get over this hump. Which has been in front of me since 17 June. Meanwhile I’m hoping to get back to editing in .opml soon, which should make things faster.
But I’ll need real connectivity soon, and I can only get that from Cox. (Don’t tell me about Verizon. They’re great back at my place in Boston, where I have FiOS; but here in Santa Barbara I’m too far from their central office to get more than mimimal-speed ADSL.)
The good thing is, Cox knows the problem is one they still have to solve, and they seem serious about fixing it. Eventually.
Meanwhile, for interested Cox folks, here’s how pings to Google currently go:
dsearls2$ ping google.com
PING google.com (74.125.127.100): 56 data bytes
64 bytes from 74.125.127.100: icmp_seq=0 ttl=45 time=110.803 ms
64 bytes from 74.125.127.100: icmp_seq=1 ttl=45 time=164.317 ms
64 bytes from 74.125.127.100: icmp_seq=2 ttl=45 time=204.076 ms
64 bytes from 74.125.127.100: icmp_seq=3 ttl=45 time=259.795 ms
64 bytes from 74.125.127.100: icmp_seq=4 ttl=45 time=397.490 ms
64 bytes from 74.125.127.100: icmp_seq=5 ttl=45 time=581.123 ms
64 bytes from 74.125.127.100: icmp_seq=6 ttl=45 time=506.292 ms
64 bytes from 74.125.127.100: icmp_seq=7 ttl=45 time=128.939 ms
64 bytes from 74.125.127.100: icmp_seq=8 ttl=45 time=328.000 ms
64 bytes from 74.125.127.100: icmp_seq=9 ttl=45 time=160.761 ms
64 bytes from 74.125.127.100: icmp_seq=10 ttl=45 time=176.398 ms
64 bytes from 74.125.127.100: icmp_seq=11 ttl=45 time=187.511 ms
64 bytes from 74.125.127.100: icmp_seq=12 ttl=45 time=188.291 ms
64 bytes from 74.125.127.100: icmp_seq=13 ttl=45 time=347.966 ms
64 bytes from 74.125.127.100: icmp_seq=14 ttl=45 time=285.017 ms
64 bytes from 74.125.127.100: icmp_seq=15 ttl=45 time=389.641 ms
64 bytes from 74.125.127.100: icmp_seq=16 ttl=45 time=399.993 ms
64 bytes from 74.125.127.100: icmp_seq=17 ttl=45 time=113.803 ms
64 bytes from 74.125.127.100: icmp_seq=18 ttl=45 time=153.111 ms
64 bytes from 74.125.127.100: icmp_seq=19 ttl=45 time=147.549 ms
64 bytes from 74.125.127.100: icmp_seq=20 ttl=45 time=198.597 ms
^C
— google.com ping statistics —
21 packets transmitted, 21 packets received, 0% packet loss
And here’s how they go to the nearest Cox gateway:
ping 68.6.66.1
PING 68.6.66.1 (68.6.66.1): 56 data bytes
64 bytes from 68.6.66.1: icmp_seq=0 ttl=239 time=676.134 ms
64 bytes from 68.6.66.1: icmp_seq=1 ttl=239 time=263.575 ms
64 bytes from 68.6.66.1: icmp_seq=2 ttl=239 time=429.944 ms
64 bytes from 68.6.66.1: icmp_seq=3 ttl=239 time=470.586 ms
64 bytes from 68.6.66.1: icmp_seq=4 ttl=239 time=473.553 ms
64 bytes from 68.6.66.1: icmp_seq=5 ttl=239 time=416.172 ms
64 bytes from 68.6.66.1: icmp_seq=6 ttl=239 time=489.699 ms
64 bytes from 68.6.66.1: icmp_seq=7 ttl=239 time=471.640 ms
64 bytes from 68.6.66.1: icmp_seq=8 ttl=239 time=349.825 ms
64 bytes from 68.6.66.1: icmp_seq=9 ttl=239 time=588.051 ms
64 bytes from 68.6.66.1: icmp_seq=10 ttl=239 time=606.703 ms
64 bytes from 68.6.66.1: icmp_seq=11 ttl=239 time=573.560 ms
64 bytes from 68.6.66.1: icmp_seq=12 ttl=239 time=454.920 ms
64 bytes from 68.6.66.1: icmp_seq=13 ttl=239 time=259.428 ms
^C
— 68.6.66.1 ping statistics —
14 packets transmitted, 14 packets received, 0% packet loss
And here is a traceroute to the same gateway:
traceroute to 68.6.66.1 (68.6.66.1), 64 hops max, 40 byte packets
1 10.0.2.1 (10.0.2.1) 2.376 ms 0.699 ms 0.711 ms
2 68.28.49.69 (68.28.49.69) 109.610 ms 78.637 ms 73.791 ms
3 68.28.49.91 (68.28.49.91) 84.093 ms 161.432 ms 84.844 ms
4 68.28.51.54 (68.28.51.54) 187.814 ms 166.084 ms 181.780 ms
5 68.28.55.1 (68.28.55.1) 126.050 ms 100.136 ms 239.987 ms
6 68.28.55.16 (68.28.55.16) 80.512 ms 147.347 ms 373.152 ms
7 68.28.53.69 (68.28.53.69) 121.593 ms 265.198 ms 323.666 ms
8 sl-gw10-bur-1-0-0.sprintlink.net (144.223.255.17) 331.535 ms 346.841 ms 279.394 ms
9 sl-bb20-bur-10-0-0.sprintlink.net (144.232.0.66) 397.594 ms 542.053 ms 546.655 ms
10 sl-crs1-ana-0-1-3-1.sprintlink.net (144.232.24.231) 986.040 ms 451.456 ms 630.898 ms
11 sl-st21-la-0-0-0.sprintlink.net (144.232.20.206) 726.689 ms 452.451 ms 235.828 ms
12 144.232.18.198 (144.232.18.198) 194.067 ms 295.496 ms 99.809 ms
13 64.209.108.70 (64.209.108.70) 262.008 ms 93.663 ms 114.594 ms
14 68.1.2.127 (68.1.2.127) 145.956 ms 123.435 ms 345.784 ms
15 ip68-6-66-1.sb.sd.cox.net (68.6.66.1) 346.696 ms 654.332 ms 406.933 ms
Draw (or re-draw) your own conclusions.
Maybe somebody out there in geekland can see the problem and help offer a solution. Thanks.
-
Doc, have you tried using a WordPress client app like MarsEdit on your Mac? You might be a better option at beating the latency issues you’re having. Just a thought… http://www.red-sweater.com/marsedit/
-
Doc, can you VPN into another net (Harvard’s or Linux Journal’s) and just port your work through a VM or a remote desktop? Might make it a bit more tolerable… Redirect Firefox through an SSL connection to another net? sumpthin’?
-
Doc,
I suggest you treat blogging as if you were offline: write all of your posts in TextEdit (or Coda or Dreamweaver). At the bottom of each post, write a new line of your tags, comma separated.
When you do connect to your blog, type in the subject, copy and paste the body, move the tags, select categories, and press Publish. Voila, less hassle, more words!
-
Latency can be attributed to a leak somewhere, when the lead tech comes out ask if he can do a leak check around your residence or on the tap coming into your stub box. Unless they’ve done this all ready. Overall it sounds like an issue for engineering to baffle over.
-
I vastly prefer to edit almost everything offline, in emacs. I do gather large numbers of urls while online (a research phase) and later edit them down into a given set of articles. (a writing phase that is independent of the net entirely)
It really bothers me that so many people are so dependent on the internet for every second of work, and become dysfunctional, unable to plan or act, without it. One EMP and the Millenial generation will die off inside of a week.
Just to amuse myself, I just pinged google from where I live in Nicaragua…
64 bytes from gw-in-f104.google.com (74.125.67.104): icmp_seq=1 ttl=46 time=68.3 ms
64 bytes from gw-in-f104.google.com (74.125.67.104): icmp_seq=2 ttl=46 time=65.7 ms
64 bytes from gw-in-f104.google.com (74.125.67.104): icmp_seq=3 ttl=46 time=67.9 ms
64 bytes from gw-in-f104.google.com (74.125.67.104): icmp_seq=4 ttl=46 time=72.4 ms
64 bytes from gw-in-f104.google.com (74.125.67.104): icmp_seq=5 ttl=46 time=67.3 ms:snark:
Move to the third world! Take advantage of proven 3rd and 4th generation technology, instead of all that oversold first generation crap that the big Corporations of America are still trying to get you pay for. -
@Ivan: Thanks for recommending MarsEdit. It sounds like Doc would certainly like to get to the bottom of the real problem here, but it’s true that a client such as MarsEdit would help with the repeated client-server communication that happens in the web interface.
@judi: essentially a client application does exactly what you are suggesting, but makes it easier since you type everything into similar fields as you would on the blog interface. When done, you just click “Send” and it’s published.
Comments are now closed.
7 comments