Doc Searls Weblog

Just trying to make stuff happen

Connectivity hell, Part III

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.

, , ,
, , , , ,

Posted by:

Doc Searls

7 responses to “Connectivity hell, Part III”

  1. Friends of Dave (friendsofdave) ‘s status on Monday, 06-Jul-09 23:27:18 UTC – Identi.ca

    […] http://blogs.law.harvard.edu/doc/2009/07/06/connectivity-hell-part-iii/ […]

    Reply
  2. Ivan Stegic Avatar
    Ivan Stegic

    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/

    Reply
  3. John Davey Avatar
    John Davey

    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’?

    Reply
  4. judi Avatar
    judi

    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!

    Reply
  5. Zakk Avatar
    Zakk

    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.

    Reply
  6. dave taht Avatar
    dave taht

    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.

    Reply
  7. Daniel Jalkut Avatar
    Daniel Jalkut

    @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.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *