Symptom: every once in a while, my DSL connection dies, then it comes back to life again a few minutes later.

I've been noticing this for quite a while now. Over the past few days, I've invested some serious energy into trying to track it down.

Basics:I've got AT&T DSL, the high-end variant (6Mb down, 768k up). I got the $50 cheapo Motorola modem, which I then have connected to my D-Link DGL-4300 (gigabit gaming router).

I've dialed everything in as well as I could. The Motorola modem originally wanted to serve up a 192.168.* address via DHCP. I reconfigured it to just pass through the PPPoE, which I then configured my D-Link box to handle. I then configured the D-Link box to attempt to keep the connection live all the time, and I disabled the "try to measure your bandwidth" thing they do for QoS (I just told it the specs of my DSL to save it some time). Last night, in frustration, I got the D-Link sending its logs to the syslog daemon on my Mac so I can see what happened.

The results? Roughly 24 hours after getting the syslog set up, the connection dropped. The log is below. Also amusing but probably not relevant: over the last 24 hours, my router dropped 659 packets, mostly inbound TCP connection attempts to weird high-numbered ports.

Is this enough that I should try calling AT&T tech support and complaining? Is that likely to be in the least bit productive?

You should try to gather more information first.

In particular, your DSL modem can probably tell you more about the signal quality on your line, from its internal web server, or with something like the dmt software tool (windows/unix).

For our line here, I have my 24/7 Linux server log the line status hourly, and after any connection reset:

Modem: Up, speed 2496/640kb/s, interleaved, atten 61.0/31.5 dB, margin 7.0/11.0 dB, power 19.0/11.5 dBm, resets=5

That kind of information can be quite valuable to have in hand before calling the telephone company.

In this case, you can see the S/N margin is quite low on my line -- 7.0dB downstream, and a better 11dB upstream. The "worst" usable value there would be 6dB, and ideally it should be 12dB or better.

Since the S/N is poor, the carrier wanted to downgrade the line profile to 1700/500, which would double the S/N, at the expense of low bandwidth for me.

So instead, I insisted that they use an interleaved (instead of "fast") profile, which spreads out the ECC data much more widely. This increases line latency by quite a bit, but makes things much more immune to line noise and retains the higher throughput.

Cheers