BT 80/20 - 20% reduction in DS sync after several years

I have been with BT for several years and am currently on their Halo 1 FTTC product. In October 2017, for no extra charge BT migrated me onto the 80/20 product so I had the maximum speeds possible.

I have therefore enjoyed a sync rate of 79XXX/ 19XXX up for many years (I forget exactly because frustratingly I don't have a copy of my previous router stats) and generally an excellent experience with months of uptime.

Link to BT Home Hub overview (alas not stats) following switch to 80/20 product.


My setup is a Huawei HG612 modem connected to a Ubiquiti Unifi Security Gateway (USG) which acts as gateway, router, firewall, DHCP server etc.. Therefore, the sync is all on the HG612 modem.

The power supply on the USG failed (27 November). I was not at home at the time so the internet remained down for 10 days. I have returned home, and before turning off the HG612 I noted from the lan interface that the sync speed had dropped. I paid little attention thinking it was to do with whatever problem had taken down the connection and temporarily connected the BT Home Hub 5 (Correction: Home Hub 6A) to confirm the line was good, and then replaced the power supply on the USG so it is now working again.

The HG612 is now consistently syncing at a far lower rate downstream of around 67,600kbps. The upstream remains unaffected. The downstream SNR margin is 6.3dB and I'm frankly lost as to what has led to this considerable change.

Full stats below:

Stats recorded 08 Dec 2021 17:02:54

DSLAM type / SW version: BDCM:0xa4a1 (164.161) / v0xa4a1
Modem/router firmware: Not monitored
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 16 hours 17 min 31 sec
Resyncs: 3 (since 06 Nov 2021 12:15:21)

Downstream Upstream
Line attenuation (dB): 14.9 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 67652 19999
SNR margin (dB): 6.3 15.2
Power (dBm): 13.4 6.6
Interleave depth: 8 1
INP: 48.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)

RSCorr/RS (%): 0.0000 0.0072
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 13.5

Can anyone shed any light on this?

I have also linked the Bitloading output from DSL stats, in case this means more to those more technical than me!

Please let me know if any more information will help and I will do my best to help. A 20% reduction isn't the end of the world but it is frustrating given it's on an otherwise reliable line. It even had me looking again at Virgin Media's offerings after swearing off them for many years!

Edit to correct signature:
-----------------------------------
BT Broadband Halo 1 FTTC 80/20
79,XXX/19,999 sync
Modem: Huawei HG612 3B modem
Router: Ubiquiti Unifi Security Gateway

Old signature:

Edited by oracleredux (Wed 08-Dec-21 19:31:45)

Brief improvement in SNR for a short period this afternoon:
Graph
Which makes me wonder if there is interference somewhere.

Is it similar with the HH5?

In reply to a post by witchunt:

Is it similar with the HH5?

I should correct myself - it's the Home Hub 6A, and nope, it is not:

Main connection page

Technical stats

A further update - according to the HG612 web interface, the SNR margin on the downstream is actually 14.9dB.

Screenshot

This is confusing since the SNR from dslstats (which uses Telnet) remains around 6dB:

Stats summary
Stats recorded 09 Dec 2021 09:04:54

DSLAM type / SW version: BDCM:0xa4a1 (164.161) / v0xa4a1
Modem/router firmware: Not monitored
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 13 hours 49 min 12 sec
Resyncs: 4 (since 06 Nov 2021 12:15:21)

Downstream Upstream
Line attenuation (dB): 14.9 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 67422 19999
SNR margin (dB): 6.4 15.3
Power (dBm): 13.4 6.6
Interleave depth: 8 1
INP: 48.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)

It looks like the command line is showing the 14.9dB figure as line attenuation vs the web interface which shows it as SNR margin.

Does anyone known whether the SNR margin pulled from command line or that on the web interface is correct?

If the downstream SNR is indeed 14.9dB then I do I need to contact BT or wait for the DSLAM to force a resync after the line has been stable for a while?

IIRC from over a decade ago, the web interface on the HG 612 always had that problem. Note that the attenuation and power lines have identical values. (The units of course being different in the label).

Telnet will be showing the correct figure.

Thanks @pluralist.

I figured as much given the Telnet and BT HH6 figures were more aligned.

Alas that does not answer my question as to why there has been such a reduction in line sync speed.

Bitloading

The bitloading output looks odd to me given the trough between Tone numbers 150 and 300 but I am not clear what it should look like.

Edited by oracleredux (Thu 09-Dec-21 09:52:23)

Can you get an image of ALL tones - right uop to 4000+

In reply to a post by MHC:

Can you get an image of ALL tones - right uop to 4000+

Thanks for the response - please see screenshot below:
Bitloading - all tones

Hope that was what you were after?

The oddity I notice there is that the tones finish rather earlier than I would expect - 4096 is, I belive, the top. Nothing looks totally untoward - just maybe a little low - I might have expected some in D1 to be up in the 14/15 bits and more at 12.

Thanks for the response.
Practically speaking, does that indicate a particular direction to focus on (e.g. faulty equipment, interference, a fault in the line) or is it just one of the vagaries of VDSL which I'll need to live with (i.e. I'm stuck with the lower DS sync speed)?

Edited by oracleredux (Thu 09-Dec-21 16:11:59)

Whatever you do don't keep re-sync'ing. It could just be DLM waiting for a few days stability before lowering your sync-time SNR Margin. Which if it happens it will be in three stages, 1dB at a time. Each causing a re-sync at a higher speed.

Thanks - I will leave untouched for a week or so and see if anything changes.
The 4 resyncs since 6 November were all due to my intervention to switch out the modem/ router to the BT HH6 and back again following testing and replacement of the failed PSU on the USG, so the line itself has been stable.

Edited by oracleredux (Thu 09-Dec-21 16:19:52)

Although, given the downstream SNR margin of 6.9dB (correction: 6.4dB), I am not sure whether this is any headroom for the DLM to wait for stability and then change the margin? Unless I'm misunderstanding the process.

Edited by oracleredux (Thu 09-Dec-21 16:22:51)

As mentioned, it should resync down to 3dB ... your 6.4 at present was probably a 6.0 sync and as the environment changes it has gone up to 6.4. So just leave it.


Nothing much you can do except wait and DLM will do it, in its own time!

If the line is clean, which MHC has cast doubt on, the sync-time margin can be reduced by DLM to 3dB. This has been so for many years now. It's just a matter of wait and see.

At least you are still getting a decent speed .

Thanks @Pluralist and @MHC.

I had not appreciated that SNR Margin can now be reduced to 6dB by DLM (the benefits of having a well performing line). I was recalling ADSL days where it was 6dB or 3dB with more forward thinking providers such as Be*. That being said, my parents have a BT line which never shifts off 6dB DS SNR (e.g. 52 days of uptime with no resyncs and a ~6.7dB SNR), and I have monitored that fairly frequently.

Agreed, ~65Mbit is not to be sniffed at!

Thanks again for the advice, I'll see where things are for week or so and report back.

No change in sync rate or SNR Margin which remains (most of the time) around 6.3dB). However, for around 30 minutes this morning the SNR Margin increased markedly to @11.5dB.

See:
SNR Down by band
SNR up by Band
Bitloading

I did not actively turn any equipment off in my house at that time (and would expect further examples if it was due to, for e.g. a fridge compressor, so it isn't clear what has cut in or out within my property or externally.

Stats summary:

Stats recorded 15 Dec 2021 13:25:24

DSLAM type / SW version: BDCM:0xa4a1 (164.161) / v0xa4a1
Modem/router firmware: Not monitored
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 6 days 18 hours 9 min 45 sec
Resyncs: 4 (since 06 Nov 2021 12:15:21)

Downstream Upstream
Line attenuation (dB): 14.9 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 67422 19999
SNR margin (dB): 6.3 14.8
Power (dBm): 13.4 6.6
Interleave depth: 8 1
INP: 48.00 0
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)

RSCorr/RS (%): 0.0001 0.0556
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 11.5

As ever, would welcome any insight but will keep monitoring.

That 08:30 to 09:05 change ... something odd about that.

Do you have a device that was turned off at that time? Try watching that for a couple of days to see it repeats.

Indeed - rather odd.

I didn't actively turn anything on or off during that period (and was the only one in the house). I have just turned off a few devices in the vicinity of the modem (PoE injectors, chargers, IoT devices etc) and none of those affected SNRM.

I will monitor and see what happens over the coming couple of days.

That step change up and down can be indicative of a wide band noise source being switch off and then back on, it may not be yours but could be a neighbour or on te street. If it is then it may well be teh answer to your loss of speed issue.

The Openreach line to my house is around 300 metres in length and supported 80/20 synch rates for several years.
As local FTTC take up has increased the crosstalk has resulted in the line now synching at 67/18 with the help of G.INP and a 3 dB downstream margin.
Dslstats reports simillar downstream Signal to Noise step changes when neighbours switch off their modem/routers.

It's also Christmas lights going up all over the place of course. Often causing havoc especially if faulty.

Given that it was first noticed around 7th December ... that could be a possible explanation.

Thanks all, interesting points. Fingers crossed for the Christmas lights, given they are seasonal, but I fear skandia2's explanation might be the reason - someone with a new FTTC install and maybe a dodgy internal wiring setup introducing a load of noise.

I will try and isolate other possible sources within my house. Pity I didn't have DSL stats setup a while ago such that I know precisely when the sync rate dropped.

I would suspect the USG given I first noticed this when the PSU on the USG failed, but removing the USG doesn't resolve the issue (see results above using BT HH6).

So, have you considered it could be one of your PSUs? What casue the USG one to fail? Did it damage the HG612 supply
too?

They are just basic switch mode 12v supplies so do generate a lot of noise but is mostly filtered out.

In reply to a post by MHC:

So, have you considered it could be one of your PSUs? What casue the USG one to fail? Did it damage the HG612 supply
too?

They are just basic switch mode 12v supplies so do generate a lot of noise but is mostly filtered out.

I have considered it may be one of my PSUs. I have tested removing a variety of those in the same area as the modem but will need to make my way around the rest of the devices in the house. As to the modem itself, I don't have a spare PSU to try, however, the SNR margin remains the same when syncing using the BTHH6, i.e. when the HG612 and its PSU is not connected, so that would seem to rule out the HG612.

I am not sure what caused the USG PSU to fail but from reading online they are not particularly reliable.

Edited by oracleredux (Wed 15-Dec-21 16:30:46)

I've mananaged to dig out my DSLStats historical data (all 115,000 entries) so now have an exact history of when the line degraded.

Historically, the downstream SNR Margin was around 7.3dB (upstream around 15.3db). This was reflected in line sync which always at the max allowed by BT: 79,999 / 19,999Kbps (with max obtainable being 85,492 /29,289).

On 16 November at 14:48 the downstream SNR margin dramatically reduced to 2dB (the upstream SNRM reduced slightly to 14/12dB or so). DS SNR had been holding steady at around 7.3dB for a long period and suddenly collapsed to 2dB.

This did not immediately impact on sync which held at 79,999 / 19,999Kbps on the narrower SNRMs of 2dB/12dB. Also there doesn't appear to have been any change in the stats when the USG PSU failed (03:00 on 27 Nov).

The HG612 held sync until I switched it off (to exchange for BT HH6) on 6 Dec. When I switched the HG612 back on the next day (7 Dec at 23:43), the sync rate dropped to 67,774Kbps in order to achieve a DS SNRM of 6.3db. There has been no subsequent change for the last 10 days.

Extract of data referred to above

In case it helps, I have the full logs (115,000 entires across 148 data points) but don't know what many of the stats relate to.

Charted data:
DS US Sync chart
SNR Margins

Edited by oracleredux (Sat 18-Dec-21 11:14:27)

If you go back to the recent post where the SNR improved for a short while - that was a 5.3 dB improvement.

Your historical data shows a drop on 16 Nov from 7.3 to 2 dB which is 5.3 dB. Coincidence? Or not? I would suggest there is something casung it - maybe not your house but a neighbour. Could be an electrical device, or as suggested, Xmas lights, or ...

Have you tried turning off EVERYTHING in your house and garage except the modem or hub. And I mean everything, lights, fridges, chargers. That will eliminate your property and point towards external.

edit to add:

Andl looking at your long term stats there are six points where the DS Max has returned to the previous level similaerly the Up Max - the six spikes. Which reinforces a possible single noise source. Can you pinpoint the time of day those occured.

INterested to hear Pluralist's thoughts too.

Edited by MHC (Sat 18-Dec-21 11:33:03)

The description given and the timing sounds very much like a bad crosstalker.

Basically another line on the cabinet that runs in close proximity to your line within the ducts/multi pair bundle has signed up to an FTTC service.

The interference this line causes when synced causes a large drop in downstream SNRM, with a smaller drop in the upstream SNRM.
At the next resync this means your line loses quite a bit of sync speed.

You posted a snapshot of the downstream and upstream SNRM briefly increasing and then reverting back to their normal values.
That matches what it looks like when a bad crosstalker turns off their modem, then turns it back on again.

A single bad crosstalker can knock over 20Mb from a lines sync rate/attainable rate. Other crosstalkers may have little to no impact at all. It's very much a lottery.

It's either a crosstalker as described above or it's some kind of electrical interference (from a pump or generator for example).

Imo is more likely a crosstalker though as I can't think of any equipment/machinery/appliance that would suddenly have that much impact on a line and be running 24/7.
That kind of interference tends to go on and off at regular intervals.

Agreed. The first thing that came to my mind was a new crosstalker. There isn't much you can do other than hope the vectoring is enabled on the cabinet, but I doubt OR are enabling vectoring now that they're focussing on FTTP.

Thanks all.

I fear a bad cross-talker is the explanation. I am going to leave alone until the new year and then do as MHC suggests and eliminate an internal issue as the cause.

Fingers crossed for Vectoring but from a quick search online, it seems BT are focused on G.Fast rather than Vectoring (which appears to only be possible for Huawei cabs anyway). As for for my cabinet, it is not enabled for either and not in a FTTP priority area.

So it looks like I'm stuck with the reduced speed for the foreseeable future. I'll just have to keep my fingers crossed that the cabinet doesn't fill up further and introduce more cross talkers.

Are you able to go back through the data and identify the time and duration of the "spikes" where it went back to the original?


Edit to add:

I was probably the first VDSL customer on my cabinet and had some wonderful max attainable rates well up th the 90s and high 20s. As more were added it dropped slowly to around 80/22 attainable and then a littlke more - no great big steps and I am probably teh longest (except one) line. I knew it would happen and it was fine. Then, the big one arrived I cannot remember exact numbers but it was a 10Mbps hit ... we knew who it was and they turned theirs off, mine returned to normal, back on and mine dropped. When te house was sold and new people moved in, new equipment but still the same problem!

Edited by MHC (Mon 20-Dec-21 11:04:00)

In reply to a post by oracleredux:

Fingers crossed for Vectoring but from a quick search online, it seems BT are focused on G.Fast rather than Vectoring

Excluding a couple trials, Openreach only ever deployed Vectoring on VDSL2 on targeted BDUK funded Huawei cabinets.
They only used it where it increased the number of properties on a cabinet who could obtain SuperFast speeds/targets as their funding for these cabinets was linked to how many properties they covered.

VDSL2 Vectoring has never been deployed commercially by Openreach and it never will be unfortunately.
There won't be any more upgrades to the VDSL2 cabinets.

The G.Fast rollout is also long since over/dead.

The focus is 100% FTTP.

But installed G.Fast is still live and reported on these forums a bit ago as preventing FTTP being installed for now whilst some more distant FTTC on the same cabinet is getting FTTP offered as an upgrade.

AIUI G.Fast requires vectoring to be enabled on at least the pod DSLAM.

I said the G.Fast rollout was over/dead.
Existing G.Fast remains in place, though the number of providers selling it is going down, not up.

Vectoring is mandatory on G.Fast.
That provides zero benefit to VDSL2 though.

I don't doubt your expansive knowledge John, but are OR really focussing 100% on FTTP, as an FTTC cabinet is planned to be installed in a local town to me?

Edited by Grimers (Mon 20-Dec-21 17:40:16)

They are still installing FTTC cabinets, though few and far between.
They are even still installing the odd G.Fast pod.

The Scottish R100 programme plans on using FTTC to meet some of its targets.

I said the focus is 100% on FTTP, not that they are only installing FTTP.

There is no current VDSL2 or G.Fast rollout programme, though they will continue to use them on a small scale where appropriate.

In reply to a post by MHC:

Are you able to go back through the data and identify the time and duration of the "spikes" where it went back to the original?

Happy New Year. I've gone through the data and these are (table extract) the times and duration of the "spikes".

One for a minute a couple of days after the original decrease in SNR, the same the next day, both overnight (offending modem resync?). Then 10 minutes in the middle of the day in early December and a couple of longer periods a few days later.

No discernable pattern that I can see. Have yet to turn everything off and isolate stuff my side of the meter but I fear it's as j0hn83 suggested and the same as MHC has seen - a crosstalker.

Edited by oracleredux (Thu 06-Jan-22 23:05:02)

My G.fast was pretty very good with vectoring!

Latest Stats as of now:

Stats recorded 07 Jan 2022 06:09:17

DSLAM type / SW version: BDCM:0xc190 (193.144) / v0xc190
Modem/router firmware: AnnexA version - A2pvfbH043q.d26u
DSL mode: G
Status: Showtime
Uptime: 7 days 3 hours 36 min 22 sec
Resyncs: 0 (since 07 Jan 2022 05:29:00)

Downstream Upstream
Line attenuation (dB): 37.8 0.0
Signal attenuation (dB): 37.8 0.0
Connection speed (kbps): 241117 41527
SNR margin (dB): 3.1 3.1
Power (dBm): 0.0 4.1
Interleave depth:
INP: 550.00 607.00
G.INP: Not enabled Not enabled
Vectoring status: Unknown

RSCorr/RS (%): 0.0364 0.1037
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0

Max, please stop posting your stats in threads where it's not relevant.

OP: I see the same drop as you do when my neighbour enabled their VDSL2. The house was on the market and the service cancelled and my rate went up to about 80Mbps, when people moved in and enabled their broadband it dropped to around 69Mbps.

Edited by jpm (Fri 07-Jan-22 07:52:56)

As you say, no discenable pattern which would rule out central heating for example, modem reboots/resync possible. And I would guess tha as it in 7th January, no christmas lights.