Ongoing WAN/DSL drops - repeated DSL sync loss

[callyy]

Configuration:
• Router connected directly to master socket (test socket)

Timeline:
• 29 Jan – Issue started (same day BT Openreach works carried out in the street)
• 02 Feb – BT (home/internal) engineer visit; no fault found at time of visit
• 07 Feb – Router replaced (old ER115 → new SR203), connected to test socket

Additional info:
Drops occurring despite a safety-capped 12.9dB Noise Margin and speed reductions from 67Mbps to 49Mbps.

Problem:
I’m experiencing an ongoing intermittent broadband fault with repeated loss of DSL/WAN sync.
It presents as physical WAN/DSL drops, with the line retraining multiple times, often in clusters. This behaviour has been occurring daily since 29 Jan.

Given the persistence and repeatable pattern of the fault, I believe this now requires escalation as an intermittent line issue, potentially requiring specialist Openreach investigation or monitoring to capture the fault when it occurs.

I can provide full router logs, timestamps, and additional diagnostics if required.

Below is a simplified timeline from a typical weekday (Mon–Sat), showing a long stable period followed by clustered WAN/DSL drops later in the day. This pattern has repeated daily since end of Jan.

[X] = Physical WAN Drop | [—] = Stable Connection

12:00 - 15:00 | —————————————————————————————— (Stable)
15:00 - 16:00 | ——————————————————————— [X] ————— (1st Drop @ 15:52)
16:00 - 17:00 | —————————————————————————————— (Stable)
17:00 - 18:00 | — [X] — [X] — [X] — [X] — [X] —————— (Cluster 1)
18:00 - 19:00 | — [X] —— [X] —— [X] ———————————— (Cluster 2)
19:00 - 20:00 | — [X] ————————— [X][X] — [X] — [X] —— (Rapid drops)
20:00 - 21:00 | —————— [X] —— [X] — [X] — [X] —————— (Instability)
21:00 - 23:00 | [X] — [X] — [X] — [X] — [X] — [X] — [X] — (Sustained instability)

[JimM1]

@callyy If you can follow the link below, allow the table to fill up, capture the table and post back your router stat's....

How to read your Sky Hub statistics

[callyy]

Router Statistics
System Up Time: 31:57:10
Port	Status	TxPkts	RxPkts	Collision Pkts	Tx b/s	Rx b/s	Up Time
WAN	MER	6181	9147	0	0	0	00:06:30
LAN	Down	0	0	0	0	0	00:00:00
WLAN (2.4 GHz)	Up	4038435	2118524	0	0	1	31:55:21
WLAN (5 GHz)	Up	2237147	656153	0	0	0	31:55:20
Broadband Link	Downstream	Upstream
Connection Speed	43998 kbps	11999 kbps
Line Attenuation	D1(13.4 dB) , D2(24.2 dB) , D3(35.2 dB)	U0(6.6 dB) , U1(17.9 dB) , U2(26.0 dB)
Noise Margin	15.2 dB	18.2 dB

Thanks for your response — above are the stats as requested.

Even with the Noise Margin pushed very high, the WAN link had only been up for 6 minutes at the time of capture.
DLM has significantly reduced the sync speed to try to stabilise the line, but physical sync drops are still occurring.

This suggests the issue isn’t marginal noise or throughput-related and may point to an intermittent Physical Layer sync loss that requires Openreach investigation or monitoring.

[JimM1]

@callyy Your noise margin both Up/Down is off the chart, you need to get that DSL line fixed! OR Engineer is required to trace were it is, you say they have been and checked the home, you are direct on the Master Socket test port connection, are you using a ADSL filter or direct connected?

[callyy]

Thanks again for your response

The setup info is:

Current setup: Connected directly to the master test socket (behind the faceplate) using a microfilter and the Sky-supplied purple DSL cable. Both cables and filters have been replaced.

Previous setup: Connected via the pre-filtered RJ11 port on the Openreach MK4 faceplate. This showed the same very high noise margins (~15 dB) and repeated sync drops.

Result: The instability and stats persists in both configurations. Testing at the master test socket rules out internal wiring or the faceplate.

Given the consistently high noise margin, reduced sync speeds, and the timing coinciding with Openreach works in the street on 29 Jan, this appears to be an external/intermittent line issue.

[JimM1]

@callyy It's all up to you, will go find another older stat's link from when i was on the fttc connection, think i have both a good and a faulty one so will attach for you to see, on my other laptop just got to go find. You have probably a cable connection disturbed in a ground box, it happens and with that noise margin wan drops will occur until the cable joint get's fixed! Pictures you will see when they get cleared for viewing!

Good running SR203 idealish values!Hanging in there SR203 so lived with!

Bad running SR203 very High Noise margins, bad external cable connection!

[callyy]

Thanks for the confirmation.

A disturbed cable joint during the 29/01 street works would certainly fit both the timing and the very high noise margins I’m seeing alongside repeated sync loss.

With the internal setup now fully verified (MK4 faceplate, master test socket, and SR203 router), this points strongly to an external network issue.

At this stage, could a Sky team member please review the thread and advise on arranging further investigation (for example, Openreach line checks or monitoring) so the external fault can be identified and resolved?

[JimM1]

@callyy You are going to have to get a call done to sky, the Forum is not sky Customer Service, report it as still unstable connection and be carefull when talking to the OR/Contractror Engineer, do not be telling them how to do there job, ideally when they test they will see lot's off errors on the line, and will take time for the find on the cable fault!

[callyy]

Thanks, understood — agreed on not directing the engineer.

I’ve already reported the issue by phone and had an initial Openreach visit, but the fault wasn’t present at the time.

Since then, I’ve gathered consistent evidence showing the instability persists even at the master test socket with replaced equipment.

Given the amount of detail and logs involved, I was hoping a Sky team member could review this thread and if appropriate, move the discussion to private messaging so the information can be passed on clearly and efficiently.

That way, the right checks or follow-up visit can be arranged with the best chance of capturing the fault when it occurs.

[JimM1]

@callyy Your fault is there unless you are not sure, the download speed is in the toilet as the DLM is fighting to try and keep your line stable and it's losing the battle!

[callyy · Accepted solution]

Openreach engineer came out and due to the large line attenuation, identified a fault between house and DSLAM.

It turned out to be a broken wire.

Line Attenuation now:

D1(8.7 dB) , D2(19.6 dB) , D3(30.3 dB)         U0(2.0 dB) , U1(13.5 dB) , U2(21.3 dB)

@JimM1 appreciate the help, thanks

[JimM1]

@callyy Just be sure to grab your stat's keep them safe, and do another set in 10day's time once the DLM has settled and trained the line, they are handy to have with the old copper fttc connection, when you go Full Fibre you wont have to worry about that anymore different ball game for sure!