infrastructure

You are currently browsing the archive for the infrastructure category.

Connectivity hell, Part III

July 6, 2009 in Business, infrastructure, Places, problems | 7 comments

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.

Tags: , , , , ,

The Trillion-Dollar Market

July 4, 2009 in Business, infrastructure, VRM | 10 comments

Forget financial markets for a minute, and think about the directions money moves in retail markets. While much of it moves up and down the supply chains, the first source is customers. The money that matters most is what customers spend on goods and services.

Now here’s the question. Where is there more money to be made — in helping supply find demand or in helping demand find supply? Substitute “drive” for “find” and you come to the same place, for the same reason: customers are the ones spending the money.

For the life of the commercial Web, most of those looking to make money there have looked to make it the former way: by helping supply find or drive demand. That’s what marketing has always been about, and advertising in particular. Advertising, last I looked, was about a $trillion business. Now ask yourself: Wouldn’t there be more money to be made in helping the demand side find and drive supply?

Simply put, that’s what VRM is about. It’s also what Cluetrain was about ten years ago. It wasn’t about better ways for the supply side to make money. It wasn’t about doing better marketing. It was about giving full respect to the human beings from whom the Web’s and the Net’s biggest values derive. When Cluetrain (actually Chris Locke) said “we are not seats or eyeballs or end users or consumers. we are human beings and our reach exceeds your grasp. deal with it.“, it wasn’t saying “Here’s how you market to us.” It was saying “Our new power to deal in this new marketplace exceeds your old powers to drive, lock in, or otherwise control us.” When Cluetrain said “The sky is open to the stars”, it wasn’t issuing utopian palaver. It was speaking of a marketplace of buyers and sellers whose choices were wide open on both sides. [Later… Chris Locke, who wrote that line (and those that followed), offers a correction (and expansion) below.]

On Cluetrain’s 10th anniversary, we have hardly begun to explore the possibilities of truly free and open markets on the Internet. They are still inevitable, because supporting those markets is intrinsic to the Net’s essentially generative design. Lock down users, or lock one in and others out, and you compromise the wealth the Net can create for you. Simple as that.

And that wealth starts with customers.

This is also what How Facebook Could Create a Revolution, Do Good, and Make Billions, by Bernard Lunn in ReadWriteWeb, is about.

I just wrote a brief response in Gain of Facebook, on the ProjectVRM blog.

No time for more. Not because it’s the Fourth of July, but because I’m in a connectivity hole (with latencies and packet losses that start at 1+ second and 15% packet losses and go up from there), but because I’m at my daughter’s wedding, and I need to get ready. Cheers.

Tags: , , , , , , , ,

Life in Cox tech support hell

June 27, 2009 in Blogging, Business, Gear, infrastructure, problems | 19 comments

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.

Tags: , , , , , , ,

Living Ends

June 25, 2009 in Art, infrastructure, Life, Live Web | 11 comments

This twitter post, from @KNX1070 four minutes ago, says Michael Jackson is dead. Google News‘ latest, from Fox, says he’s being rushed to the hospital. Here’s the latest Google search, as of 3:42pm Pacific:

michaeljackson_search1

A snapshot in time, already changed. (FWIW, the KNX item came up the first time I searched, but not this time. The System That Isn’t, isn’t perfect.) The Twitter results up top are courtesy of a Greasemonkey script.

It is here that we see manifest the split between the Live Web and the Static Web.

I’ve been writing and talking about this split since my son Allen first mentioned the term in 2003.* He saw the World Live Web then as an absence, as unstarted business. Google searched the Static Web of sites and domains that were architected, designed and built like real estate projects. The Live Web would be more alive and human. In it machines wouldn’t answer your questions now. People would.

Now the Live Web is here, big-time. Or, as current parlance would have it, real-time.

I still prefer “live”. Can you imagine if NBC had called its top weekend show “Saturday Night Real-Time”? Or if they announced, “Real time, from New York..”?

Live is better.

If Michael Jackson were still with us, I’m sure he’d agree.

* Here’s the same link: http://www.google.com/search?hl=en&q… . I’m not sure why, but WordPress isn’t letting me get that link in there. I post the html, find no links in the results, and then when editing find the linked term flanked by partial the letter “a” in angle brackets, sans the slash that closes a link. Not sure what’s up with that. Maybe my tortuously broken connection. Anyway, I have more to add, but won’t bother. Plenty of other reading on the Web anyway. Rock on.

Tags: , , , , , , , , ,

Tech hell, cont’d

June 24, 2009 in Call center hell, infrastructure, Places, problems, VRM | 4 comments

The idea was to take some down time in Santa Barbara and get work done in my own nice office, with my nice comfortable chair, surrounded by space and time, with soft sea breezes blowing through.

Instead it’s been tech crash city since I got here last Thursday. (Except for getting out to the Live Oak Festival. That rocked. Also, trees, dirt and great music tend not to crash.)

First a system upgrade hosed a beloved old mail program. So far I can’t get the archives to migrate anywhere. I can still get email addressed to my searls.com and Gmail accounts, but not to my Harvard.edu account. I can send from Gmail. But balls are being dropped and lost all over the place.

Next my Internet connection through Cox got flaky. Mostly it’s bad. Details in my last post. A Cox repair guy finally came today. And, as Russ predicted, tightened everything up, tested it out, and all was fine. Dig this: I didn’t know that service had improved to 18Mb/s downstream and close to 4Mb/s upstream. It was right up there when he left, along with two-digit ping times to everything.

That was then. Soon as he left, we were back to bad. We’re at 3-digit ping times and packet losses. One other discovery: my 8-port Netgear Firewall/Router/Hub/Switch (I forget the name, which cannot be remembered — it demonstrates the opposite of branding) has Issues too. It introduces latencies and packet losses of its own when it’s in the loop. It’s out right now, not that it makes any difference. I’m back using my Sprint data card.

When I called Cox to get them to come back and finish the job, they said they’d send a senior tech on Friday afternoon. That’s two days from now. Then, in the middle of a tech support call with Apple, a Cox robot made an automated survey call. I couldn’t talk and hung up on it.

If you want to reach me, text or call. Or use a Twitter DM. Meanwhile, I’m going to take a shower and go for a long walk. Or vice versa.

Hope everybody’s enjoying Reboot. I really miss being there.

Tags: , ,

This latency is caused by ____ ?

June 21, 2009 in infrastructure, problems | 23 comments

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

PING ucsb.edu (128.111.24.40): 56 data bytes
64 bytes from 128.111.24.40: icmp_seq=0 ttl=52 time=357.023 ms
64 bytes from 128.111.24.40: icmp_seq=1 ttl=52 time=369.475 ms
64 bytes from 128.111.24.40: icmp_seq=2 ttl=52 time=389.372 ms
64 bytes from 128.111.24.40: icmp_seq=3 ttl=52 time=414.025 ms
64 bytes from 128.111.24.40: icmp_seq=4 ttl=52 time=428.384 ms
64 bytes from 128.111.24.40: icmp_seq=5 ttl=52 time=28.120 ms
64 bytes from 128.111.24.40: icmp_seq=6 ttl=52 time=164.643 ms
64 bytes from 128.111.24.40: icmp_seq=7 ttl=52 time=292.241 ms
64 bytes from 128.111.24.40: icmp_seq=8 ttl=52 time=332.866 ms
64 bytes from 128.111.24.40: icmp_seq=9 ttl=52 time=330.573 ms
64 bytes from 128.111.24.40: icmp_seq=10 ttl=52 time=369.385 ms
64 bytes from 128.111.24.40: icmp_seq=11 ttl=52 time=375.593 ms
64 bytes from 128.111.24.40: icmp_seq=12 ttl=52 time=405.028 ms
64 bytes from 128.111.24.40: icmp_seq=13 ttl=52 time=413.990 ms
64 bytes from 128.111.24.40: 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 ucsb.edu (128.111.24.40), 64 hops max, 40 byte packets
1  ip68-6-68-81.sb.sd.cox.net (68.6.68.81)  5.828 ms  3.061 ms  2.840 ms
2  ip68-6-68-1.sb.sd.cox.net (68.6.68.1)  324.824 ms  352.686 ms  358.682 ms
3  68.6.13.121 (68.6.13.121)  359.635 ms  369.743 ms  372.376 ms
4  68.6.13.133 (68.6.13.133)  386.039 ms  389.809 ms  415.532 ms
5  paltbbrj01-ge600.0.r2.pt.cox.net (68.1.2.126)  430.554 ms  447.079 ms  423.461 ms
6  te4-1–4032.tr01-lsanca01.transitrail.ne… (137.164.129.15)  464.229 ms  453.908 ms  423.090 ms
7  calren46-cust.lsanca01.transitrail.net (137.164.131.246)  206.217 ms  251.298 ms  261.263 ms
8  dc-lax-core1–lax-peer1-ge.cenic.net (137.164.46.117)  264.824 ms  284.859 ms  285.808 ms
9  dc-lax-agg2–lax-core1-ge.cenic.net (137.164.46.110)  289.834 ms  307.450 ms  313.997 ms
10  dc-ucsb–dc-lax-dc2.cenic.net (137.164.23.3)  323.183 ms  331.668 ms  345.606 ms
11  r2–r1–1.commserv.ucsb.edu (128.111.252.169)  340.756 ms  377.695 ms  375.946 ms
12  128.111.4.234 (128.111.4.234)  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: , , ,

Punching out of connectivity hell

June 19, 2009 in Business, infrastructure, problems, Travel | 3 comments

For reasons I don’t have time to trouble-shoot, there is too much latency between my house and Cox, my Internet provider here in Santa Barbara.

On top of that, re-setting my SMTP (outbound email) to smtp.west.cox.net, which has always worked in the past, doesn’t work this time. So mail isn’t going out. I don’t have time to trouble-shoot that either, because I’m already late for the Live Oak Festival, where we already have a tent set up. I’m just back at the house picking up some stuff.

See ya’ll Monday.

Tags: , , , ,

Apple control freakiness

June 16, 2009 in Art, Blogging, Business, Future, infrastructure, News, problems | 17 comments

Apple has the best taste in the world. It also has the tightest sphincter. This isn’t much of a problem as long as they keep it in their pants, for example by scaring employees away from saying anything about anything that has even the slightest chance of bringing down the Wrath of Steve or his factota. (How many bloggers does Apple have?)  But they drop trow every time they squeeze down—you know, like China—on an iPhone application they think might be “objectionable”.

I see by Jack Schofield that they’ve done it again, but this time they pissed off (or on) the wrong candidate: an app (from Exact Magic) that flows RSS feeds form the EFF. Sez Corynne McSherry in an EFF post, “… this morning Apple rejected the app. Why? Because it claims EFF’s content runs afoul of the iTune’s App Store’s policy against ‘objectionable’ content. Apparently, Apple objects to a blog post that linked to a ‘Downfall‘ parody video created by EFF Board Chairman Brad Templeton.”

Brad’s a funny guy. (He created rec.humor.funny back in the Net’s precambrian age.) He has also forgotten more about the Internet than most of us will ever learn. Check out The Internet: What is it really for? It was accurate and prophetic out the wazoo. Brad wrote it 1994, while Apple was busy failing to ape AOL with a walled garden called eWorld.

Apple’s App Store is an eWorld that succeeded. A nice big walled garden. Problem is, censorship isn’t good gardening. It is, says Corynne, “not just anti-competitive, discriminatory, censorial, and arbitrary, but downright absurd.” Or, as my very tasteful wife puts it, unattractive.

Also kinda prickly, if you pick on a porcupine like the EFF. Hence, to contine with Corynne’s post,

iPhone owners who don’t want Apple playing the role of language police for their software should have the freedom to go elsewhere. This is precisely why EFF has asked the Copyright Office to grant an exemption to the DMCA for jailbreaking iPhones. It’s none of Apple’s business if I want an app on my phone that lets me read EFF’s RSS feed, use Sling Player over 3G, or read the Kama Sutra.

Not surprisingly this followed, on the same post:

UPDATE: Apparently, Apple has changed its mind and has now approved the EFF Updates app. This despite the fact that the very same material is still linked in various EFF posts (including this one!). Just one more example of the arbitrary nature of Apple’s app approval process.

There’s a limit to how long (much less well, or poorly) Apple can keep sphinctering App Store choices. I’m betting it’ll stop when the iPhone gets serious competition from equally appealing phones that can run applications that come from anywhere, rather than just from some controlling BigCo’s walled garden.

Tags: , , , , , , , , , , ,

A perfect storm in midair

June 4, 2009 in Geology, infrastructure, Life | 6 comments

southbostonstorm

They might have split up or they might have capsized
They may have broke deep and took water
And all that remains is the faces and the names
Of the wives and the sons and the daughters.

— Gordon Lightfoot, from “The Wreck of the Edmund Fitzgerald”

A storm on Lake Superior drowned the Edmund Fitzgerald. From the way it looks now, a storm over the Atlantic destroyed Air France Flight 447 earlier this week.

A book and a movie nailed the “perfect storm” meme in our heads, and I suppose the label might apply here. Flight 447 was crossing through a region known to weather professionals as the intertropical convergence zone. Storms rise quickly there, and concentrate in a band that runs around the Earth like a broad equator of roiling clouds. While lines of thunderstorms familiar to those of us in temperate zones can run for hundreds of miles along a weather front, these intertropical mothers are different in several senses, not the least of which is that it’s harder to avoid getting tossed around while weaving through them in an airplane — especially in the middle of the night over the middle of an ocean. This is due partly to the widespread and rapid-forming nature of the storms themselves, and partly to the absence of navigation guidance from the ground.

There isn’t any ground underneath. The nearest radar is far beyond the horizon. And, in some cases, such as Flight 447’s, guidance from the air is also lacking. According to that first link (a Bloomberg piece by John Hughes), less than one flight per hour takes the route flown by Flight 447, which was last heard from at 2:14am, local time, over the Atlantic appoximately midway between South America and Africa.

That also puts it over the broad Mid-Atlantic Ridge, a mountain range that runs like a baseball seam between tectonic plates. It’s mountainous down there. Go to 3° 34′ 39.72″ N, 30° 22′ 27.84″ W (3.5777, -30.3744) on Google Earth, drop about 12,500 feet below the surface, and you would see approximately this —

flight447_depths

— if it were not also the blacker than the darkest night down there. Good luck finding the flight data and voice recorders. Or anything else that doesn’t float.

My guess is that our best guesses will narrow to some combination of known facts. Chief among these is that the plane was passing through a region of big thunderstorms that had also shown up quickly. I’m guessing that the pilots did their best to avoid the worst of what they could see with their instruments, and failed. Here is a summary of final messages from the plane.

Whether the plane broke up at altitude (we know it depressurized) or went out of control and crashed intact, the terminal moments of the flight must have been frightening beyond description for those on board.

I’m a frequent flyer who loves aviation. I’ve flown enough to be jaded and calm. But thunderstorms still creep me out. One pilot friend told me a few days ago that the last thing you want to do is go through a “hole” between two thunderheads, because turbulence there can be even worse than inside the clouds themselves. When you see thunderheads building, the expansion itself is a kind of wind, and so is what happens to the air pushed aside as the head builds its visible parts.

One wonders if any decisions will be made, based on what we learn from the crash of Flight 447. Will similar Airbus planes be given a new caution? An upgrade to avionics or reporting methods? A new procedural guide for times when scary storms suddenly materialize? Dunno yet. We’ll see.
I’ll be flying back and forth to London next week. I’m looking forward to the flight as well as the work — as I always do. But, like many travelers, I’ll not be quite as calm about the weather.

Tags: , , , , , , , , , ,

Opening the paying field

June 1, 2009 in Business, Future, Gear, infrastructure, Places, Politics | 8 comments

When we went looking for an apartment here a couple years ago, we had two primary considerations in addition to the usual ones: walking distance from a Red Line subway stop, and fiber-based Internet access. The latter is easy to spot if you know what to look for, starting with too many wires on the poles. After that you look for large loops among the wires. That means the wiring contains glass, which breaks if the loops are too small. The apartment we chose has other charms, but for me the best one is a choice between three high speed Internet services: Comcast, Verizon FiOS and RCN. Although Comcast comes via coaxial cable, it’s a HFC (hybrid fiber-coax) system, and competes fairly well against fiber all the way to the home. That’s what Verizon FiOS and RCN provide.

fiber

We chose Verizon FiOS, which gives us 20Mb symmetrical service for about $60/month. The 25 feet between the Optical Network Terminal box and my router is ironically provided by old Comcast cable TV co-ax. (Hey, if Comcast wants my business, they can beat Verizon’s offering.)

My point is that we live where we do because there is competition among Internet service providers. While I think competition could be a lot better than it is, each of those three companies still offer far more than what you’ll find pretty much everywhere in the U.S. where there is little or no competition at all.

The playing field in the skies above sidewalks is not pretty. Poles draped with six kinds of wiring (in our case electrical, phone, cable, cable, fiber, fiber — I just counted) are not attractive. At the point the poles become ugly beyond endurance, I expect that the homeowners will pay to bury the services. By the grace of local regulators, all they’ll bury will be electrical service and bundles of conduit, mostly for fiber. And they won’t bury them deep, because fiber isn’t bothered by proximity to electrical currents. In the old days (which is still today in most fiber-less places), minimum separations are required between electrical, cable and phone wiring — the latter two being copper. In Santa Barbara (our perma-home), service trenching has to be the depth of a grave to maintain those separations. There’s no fiber yet offered in Santa Barbara. At our house there the only carrier to provide “high” speed is the cable company, and it’s a fraction of what we get over fiber here near Boston.

All this comes to mind after reading D.C. Court Upholds Ban on MDU Contracts: FCC prevents new exclusive contracts and nullifies existing ones, by John Eggerton in Broadcasting & Cable.  It begins, “The U.S. Court of Appeals for the D.C. Circuit Monday upheld an FCC decision banning exclusive contracts between cable companies and the owners of apartments and other multiple-dwelling units (MDU).”

The rest of the piece is framed by the long-standing antipathy between cable and telephone companies (cable lost this one), each as providers of cable TV. For example,

Not surprisingly, Verizon praised the decision. It also saw it as a win for larger issues of access to programming:

“This ruling is a big win for millions of consumers living in apartments and condominiums who want nothing more than to enjoy the full benefits of video competition,” said Michael Glover, Verizon senior VP, deputy general counsel, in a statement. “In upholding the ban on new and existing exclusive access deals, the Court’s decision also confirms the FCC’s authority to address other barriers to more meaningful competitive choice and video competition, such as the cable companies’ refusal to provide competitors with access to regional sports programming.”

Which makes sense at a time in history when TV viewing still comprises a larger wad of demand than Internet use. This will change as more and more production, distribution and consumption moves to the Internet, and as demand increases for more Internet access by more different kinds of devices — especially mobile ones.

Already a growing percentage of my own Internet use, especially on the road, uses cellular connectivity rather than wi-fi (thanks to high charges for crappy connectivity at most hotels). Sprint is my mobile Internet provider. They have my business because they do a better job of getting me what I want: an “air card” that works on Linux and Mac laptops, and not just on Windows ones). Verizon wanted to charge me for my air card (Sprint’s was free with the deal, which was also cheaper), and AT&T’s gear messed up my laptops and didn’t work very well anyway.

In both cases — home and road — there is competition.

While I can think of many reforms I’d like to see around Internet connectivity (among citizens, regulators and regulatees), anything that fosters competition in the meantime is a Good Thing.

Tags: , , , , , , , , , , , , ,

« Older entries § Newer entries »