TalkTalk Stuff – I/O-Gate

UPDATE: Finally agreed that the lines have been fixed by removal of DLM. Thanks, Alexandra.

The following is intended as a resource for TT tech staff (in the UK). It is not intended as a moan at TT.

For over 3 years (perhaps even 4, by now), my 2 TT broadband services have rarely been stable. One is usually better than the other at any given time, but the only satisfactory service was provided for 6 months by removing dynamic line management from the lines. since January (or so) it has been managing the lines once more, resulting in up to 10-15 drop-outs over a 24-hour period. A connection never lasts through a full working day or night unless a DLM reset has been performed. The line is then stable for around 48 hours before it again deteriorates. A new DLM system is currently operating, which, according to my direct experience of at least 3 TT DSL lines, performs even worse than the original one, due to some obvious misconfigurations.

Primarily, imposing a DS noise margin target of 3db without regard to the condition and context of the cables is folly. Industry standard is 9db, which can be pushed to 6 (or even lower) if a line demonstrates sufficient clarity, but this should not be done blind, as is apparently the case. My lines can support downstream nominal throughput of around 14Mb/s with an SNR of around 9db. This would be a sensible service level over copper. Frequently, the TT DLM pushes these lines to 22Mb/s (or higher), with noise margins dropping below 1 (i.e. more noise than signal), without noticing, reacting or fixing – the DLM just leaves it there until it drops. Sometimes the sync survives, so perhaps the DLM doesn’t know it has dropped on these occasions, but it should definitely be logging the errors and take action to mitigate.

My position is that an ADSL connection should normally be expected to survive for around 2 weeks, or of the order of the period between necessary reboots of a typical domestic router. This level of stability should be prioritised over throughput. In other words, pushing the connection to some level (like 20Mb/s) at the cost of causing frequent drop-outs, as is obviously happening here, is not a sensible poilicy.