Diagnosing DSL. Again.

Gibbs has moved and once again, his DSL service isn't working right ...

In the last 11 years I have moved house three times. Each time I have purchased Internet service from AT&T and each time AT&T has managed to make establishing service an epic struggle that consumes hours of my time, leaves me without service for days or weeks, and drives me to the edge of homicidal despair.

I don't have space enough in this column to relate the full details of this latest AT&T saga, but the end result is, as of today, while I should have an AT&T asymmetrical DSL U-verse service delivering a download rate of, theoretically, 6Mbps, what I have is more of a probabilistic service ... "probabilistic" as in, "I wonder when it will stop working?"

BACKGROUND: SF lets AT&T move ahead with U-verse

My service problems fall into three types: First, the service keeps failing roughly once per day for anywhere between two to four hours; second, the service has sometimes failed to deliver more than 50% of the packets sent, resulting in an effective halving (or worse) of the data rate; and, third, when the service stabilizes after one of these multi-hour outages, the download line speed is configured to a rate of under 800Kbps.

When my service first started vanishing I realized I needed to document what was going on so I fired up that old Gearhead favorite, PingPlotter, published by Nessoft.

I've written about PingPlotter a couple of times before and my description still stands: "PingPlotter is essentially good ol' *nix traceroute with a pretty face and muscles."

So, I started running PingPlotter and found that the next hop after my Motorola NVG510 ADSL2+ router, which would be a digital subscriber line access multiplexer (DSLAM) at the central office (CO), wasn't responding to about 70% of all pings, even though other routers in the path to my target server, att.com, were responding.

This was odd and a sign something was wrong, as ISPs' routers usually either respond or don't respond (they are often set up to not respond to "unnecessary" requests to maximize performance). Just ignoring some random percentage of pings indicates a problem and, lo and behold, after my first round of complaints an engineer was dispatched to the CO and changed my line card in the DSLAM. Now all pings to the first hop were generating a response.

Alas, this wasn't the end of my problems. My line performed fine for a few days then on two consecutive days it stopped working completely for three or four hours. Then it worked for a few days, then it stopped at random times for a few hours. There was no rhyme or reason for this behavior and all of my calls to customer service went through the same scripted drudgery to reach no conclusion other than someone was going to be sent somewhere to do something. I'm now waiting for a senior tech dispatched by AT&T's Office of the President (yes, I managed to get my "pain" escalated) to come and figure out what is going on ... or rather, what is not going on.

The third type of problem is different from the others in that it appears that a DSL line reset for whatever reason can result in the line being misconfigured, such that you don't get the data rate you contracted for. I suspect that when such a thing happens to most consumers they probably have no idea that the service they're getting is not the service they paid for.

These consumers might see, and be annoyed and frustrated by, significant lag when playing online games or their Netflix streaming video halting and buffering, but the cause won't be obvious. I'd guess that if and when they call AT&T customer service they will be led through the usual script and at some point the customer service representative will ask them to reset the modem, after which their problem will be magically solved! No one, especially the consumer, will have a clue what the real problem was.

You can, however, determine your DSL performance by interrogating your DSL modem ... which we will discuss next week. By the way, PingPlotter, once again, gets a Gearhead rating of 5 out of 5.

Gibbs is not well-connected in Ventura, Calif. Try to ping him at gearhead@gibbs.co. You can always follow him on Twitter (@quistuipater) and on Facebook (quistuipater).

Copyright © 2012 IDG Communications, Inc.

The 10 most powerful companies in enterprise networking 2022