pushing the envelope

Being in a major city (ha!) has its rewards sometimes. Then there are other times when I'm left to scratch my head. Today's one of those days.

A few years ago, when DSL was first offered, I signed up with DirecTV's (wired) unit. That worked okay .. in the winter months. But when summer arrived and the temperature hit 90F the DSL circuit would dive, like a cheerleader at a silent auction. Each day, the circuit would tank earlier (I learned to do more of my work in the wee hours of the morning). Turns out that was because of the physical route my phone line takes to reach the CO [Central Office]; although I'm about 2 miles ("as the crow flies") to the CO, the route taken by the phone lines stretched that about 2500 feet past maximum. Technically, I was in "denial range" (a term which still amuses me).

That debugging experience allowed me to become conversationally fluent in DSL, spewing terms like NID and DSLAM as if they were my children. I never determined why the temperature had anything to do with it, but it aided my ability to predict when the circuit would fail each day.

Eventually, DirecTV got out of that (wired DSL) business, and sold the remnants to my current provider, who gave me a shiny new DSL modem (SpeedStream 5360) and a dynamic IP address. That's been mostly fine.

So today, it didn't surprise to understand the Indian (who are we kidding? .. his name isn't really "John") tech's suspicion that the "DSL Pro Package" (1.5-3.0 Mbps down and 384-512 Kbps up) is stretching the ability of my circuit to hold a carrier. Small files (most email, web pages with small-medium graphics) transfer fine, but if I try to grab a PodCast, or watch a streaming video, or (POP3) fetch an email of more than 75 kilobytes, I'm seeing frequent timeouts. Most of the time, I use WebMail to inspect and delete messages before downloading them (if at all). I've already tweaked the settings on my POP3 client (I think a 3 minute timeout is waaaaaaaay overly generous) and nosed around my IP settings (PPPoE, MTU of 1492, etc) so am confident the problem's not on my end.

Thursday update: turns out the problem was on my end - but it was hardware! See the 22/12/5 post.

So, tomorrow morning a Real Live Technician (complete with meters) is due at my NID to see what kind of signal I'm really getting from the RT. If it's marginal, I may regress to the DSL Standard Package (assuming they can't tweak the latency for the packet timeout). I'm happy they're staffed to have someone here that quickly .. now, I'll see what they uncover.