Twice in the last few days, I’ve had 6 sec line down-up notifications from AA’s CQM alert system. This duration is way too short for real loss of sync on the DSL link ie with a retrain/reconnection (because that takes well over a minute, ~ 80s often seen), therefore I conclude it’s just a blip here, where noise has temporarily overwhelmed the error correction capabilities of the modems, and a timeout in CQM polling with PPP LCP echo requests has been exceeded. Memory is dubious here but 6 sec sounds like the timeout for polling sent upstream by my Firebrick; there’s also polling by the ISP sent downstream to poll my Firebrick here, but I can’t remember where those timing settings live.
I could lengthen the timing for the poll sent upstream. I could lengthen that for downstream too if I could find where it lives. But that is just covering up an underlying problem and I think that is bad. The link-bonding, load-splitting system will drop a link out of the bonded set temporarily and move the traffic load to other links, which is a good thing if a link is temporarily unwell.
FYI These events are incredibly rare; of the order of a couple of events per year. I assume the real fix would be to raise the target SNRM, which I really really don’t want to do as reliability is fine apart from this extremely minor observation. Target SNRM is at 3dB downstream+6dB upstream, and I cope with 3dB d/s fine. I don’t want to slow things down hugely by raising 3dB d/s to 6dB.
Am I correct in my analysis of this?
