Semi-Predictable Sync Drops

We've got a FTTC line (currently with Zen, previously with AAISP) which has been put in within the last 2 years. Its got the most recent faceplate style, and has been used with both an Openreach HG612 and more recently the Zen Fritzbox 7530.

The Openreach always sync'd up happily at ~69Mbps down, the Fritzbox has slowly worked its way back up to ~74 down, 20 up. When operating normaly, neither have / had any quantifiable number of line errors. The fritz has had sync for 30 minutes now, and is showing 0.12/min on the corrected DTU (So only 1 frame every 8 minutes it seems).

Both the OR and the Fritzbox have always seen a period every few days at either ~11pm or ~3am of a load of errors and then a resync after a minute or two. This would always last only about 3-4 minutes. The rest of the time, the line is rock solid, no errors, and as seen about as high a sync as it could be at my distance from the cab.

Recently, this has started happening a few times a week during the day time, much the same pattern.

I can't think of any sources of inteference within the house. The only thing really running at night is the fridge, heating is just a gas fired boiler and wouldn't be doing anything at 3AM, and theres practically nothing at that end of the house.

This certainly feels like something external to the house or something in the cab happening. What is my best course of action for getting this investigated by OpenReach / presenting any data needed? Previously they've been out but of course the line has been fine at that point in time.


Line Info:

Receive direction Send direction
Max. DSLAM throughput kbit/s 80000 20000
Min. DSLAM throughput kbit/s 128
Attainable throughput kbit/s 75956 24393
Current throughput kbit/s 74145 19999
Min. effective data rate kbit/s 72429
Seamless rate adaptation off off

Latency fast fast
Impulse Noise Protection (INP) 44 0
G.INP on off

Signal-to-noise ratio dB 6 15
Bitswap on off
Line attenuation dB 16 18
approximate line length m 343

Profile 17a
G.Vector off off

Carrier record A43c A43

Error Counter
FRITZ!Box Central Exchange
Seconds With
Errors (ES) 2 0
Many Errors (SES) 0 0

Not Remediable Errors (CRC)
per Minute 0.03 0
Last 15 Minutes 0 0

corrected DTU
per minute 0.1 0
Last 15 minutes 0 0

uncorrected DTU
per minute 0 0
last 15 minutes 0 0

Could be inference anywhere back to the cabinet, so you need to follow the route back to the cabinet looking for likely culprits like a commercial building recently reoccupied after covid restrictions lifted.

In reply to a post by kommando:

Could be inference anywhere back to the cabinet, so you need to follow the route back to the cabinet looking for likely culprits like a commercial building recently reoccupied after covid restrictions lifted.

Could be anything, even a neighbour's TV. (Although what's on at 3am, I don't know. Open University?)

Comments under that article suggest you buy a cheap USB software defined radio, and hunt with that.

Edited by candlerb (Tue 01-Feb-22 14:18:00)

Unfortunately (or fortunately?) Its a very residential area so no massive sources - The wires run overhead for about 5m to a pole then under the pavement down to a street cab about 350m away.

It definitely does seem like noise as its not just a loss of sync, its a sea of errors and then a loss of sync, just not so sure what it could be! Whatever it is seems very transient - it only lasts for 1-2mins and comes back with the original sync speed, straight to a happy place.

Do any of your neighbours with FTTC see the same fault, they may not have noticed the 3am ones but now its during the day it may be more obvious.

Circuits will often show a burst of errors just before the drop, when the drop is from the DSLAM end of things.

My bet is that your allocated port in the DSLAM is going Pete Tong. A lift and shift by Openreach would be my suggestion for sorting it out. The hard bit is persuading your CP, then Openreach, that you actually have an issue.

In reply to a post by Zarjaz:

Circuits will often show a burst of errors just before the drop, when the drop is from the DSLAM end of things.

^^ This.

A DLM initiated resync for example will show a large burst of CRC, ES and SES.
Usually 11 ES/SES to be precise, though CRC's show in the hundreds.

Yep, watch the error counters as your DLM reset goes through for instance. Similar seen when you run a CIDT test on an ADSL circuit.




Another random thought was a DSLAM running on back up batteries, and the brief drops are the batteries being changed out. I think the drops are too swift for this to be the answer though.

Edited by Zarjaz (Tue 01-Feb-22 19:05:22)

So I've spoken to Zen who looked at the resyncs and the general periods with non-errors and agreed it was "something strange"(!). We have an engineer coming out on Friday, so hopefully they will have some luck.

Very interestingly, it went mad again at around 4-6 last night:
https://ibb.co/25QHKkT

(The graph is a little misleading - as far as I can tell this was 2-3 outages).

Even more curiously, it lost sync at about 1 this morning, then came back with lower SNR and a significantly higher sync speed.

I want to get this pulling into ingress or similar but not quite got round to it - the fritzcollectd is a bit of a pain it seems.

Negotiated Connection Properties
Receive direction Send direction
Max. DSLAM throughput kbit/s 80000 20000
Min. DSLAM throughput kbit/s 128
Attainable throughput kbit/s 79806 25767
Current throughput kbit/s 79055 19999
Min. effective data rate kbit/s 79008
Seamless rate adaptation off off

Latency fast fast
Impulse Noise Protection (INP) 44 0
G.INP on off

Signal-to-noise ratio dB 4 15
Bitswap on on
Line attenuation dB 15 18
approximate line length m 332

Profile 17a
G.Vector off off

Carrier record A43 A43

Edited by bdav (Wed 02-Feb-22 10:10:01)

OK, my money is deffo on a lift and shift required now.

Get the Openreach bod to look at the service graphs on their task … it ought to show the drops. Let them know that you have tried two different sorts of router already to rule out them saying it’s your CPE.