In reply to a post by j0hn83:

The 11 SES are caused by the 11 ES.

I was under the impression that SES (Severely Errored Seconds) are worse than an ES (Errored Second.) Only one event is needed to trigger an ES. A Severely Errored Second is a one second period which contains 30% or more errored blocks. Could therefore 11 SES, in a relative time period, result in a LOS and a subsequent resync? If that were to happen fairly regularly then that would surely indicate a probable line fault and an investigation by a SFI engineer.

In reply to a post by 4M2:

In reply to a post by j0hn83:

The 11 SES are caused by the 11 ES.

I was under the impression that SES (Severely Errored Seconds) are worse than an ES (Errored Second.) Only one event is needed to trigger an ES. A Severely Errored Second is a one second period which contains 30% or more errored blocks. Could therefore 11 SES, in a relative time period, result in a LOS and a subsequent resync? If that were to happen fairly regularly then that would surely indicate a probable line fault and an investigation by a SFI engineer.

They aren't actual errors.

They occur during the DLM resyncing the line.

Would you like that in another language?

In reply to a post by j0hn83:

That's not to say there's no issues with the line.
It is currently banded.

The error figures are low though, and don't justify contacting an ISP on any line.
Knowing how the DLM causes ES on Broadcom modems i know there are zero CRC, ES, SES or LOS in those 23 hours of stats.

I'll rephrase, the symptom is the internet stops working entirely during frequent periods over the day. The internal equipment is fine so it must be a line issue. I thought that posting the stats might help narrow down the problem rather than use them as a basis to report an issue.

The CRC errors DIRECTLY (within the preceeding 15min period) coinsided with the only occasion during the previous 24hrs that the line lost sync and retrained so seem to be a relavent symptom of the problem. There were ZERO recorded CRC errors before this happened and 575 during the event. Whether the total is low or high, whatever caused the line ro resync, it happened the same time as those CRC errors.

I didn't notice it as I wasn't using the internet, but it retrained about 45 mins ago (00:15) which is almost the exact time it retrained last night. Is that a BT function for weak lines or does it suggest some sort of local interference? Also noticed the upstream line rate has dropped by about 2mbit from that posted in my previous line stats.

Obviously I need to get plusnet to arrange a visit from BT, but just was curious to know if anything seemed distinctly out of the ordinary to help narrow down the problem before they send an engineer that will just plug in a machine that says it is working fine (during his test).

In reply to a post by milesharrison:

The CRC errors DIRECTLY (within the preceeding 15min period) coinsided with the only occasion during the previous 24hrs that the line lost sync and retrained so seem to be a relavent symptom of the problem. There were ZERO recorded CRC errors before this happened and 575 during the event. Whether the total is low or high, whatever caused the line ro resync, it happened the same time as those CRC errors.

I knew that without you telling me that, which is why i was stressing the 11 ES/SES is of no concern.

It's likely the DLM making adjustments to your line.
For example it could be turning G.INP on or off on the upstream.

I didn't notice it as I wasn't using the internet, but it retrained about 45 mins ago (00:15) which is almost the exact time it retrained last night. Is that a BT function for weak lines or does it suggest some sort of local interference? Also noticed the upstream line rate has dropped by about 2mbit from that posted in my previous line stats.

Yes again it's the DLM making adjustments. It needs to resync the line to do this.
Sometimes it will do this every other day, sometimes once a month.
You may find upstream G.INP is now off (the upstream INP will have changed from 44) which is why the sync is a little lower.

There was likely another 10 or 11 downstream ES coinciding with this resync.
It's normal.

Could you post the new stats?

Edited by j0hn83 (Mon 28-Dec-20 01:20:27)

A once a day or every other day retraining they could live with, but not multiple periods throughout the day where the internet either slows to a complete crawl (<3mbps actual throughput) or stops entirely for 10 mins (without a retrain event) ruining whatever they are watching on netflix etc.

However I can't see why a daily retraining would be necessary under normal circumstances. My VDSL at home will sit happy for a month on end without a retrain. If we could limit hers to say 20mbit to improve stability, it would be a dissappointing, but effective improvement.

There has been water ingress in the wires which is almost certainly the problem with her connection. I'm just wondering what way we can get a permenant solution to improve its reliability. One BT engineer moved (extended) the master socket to another room to avoid a bad corner of damp. That didn't help. The next one moved it up the wall by a meter to table level to help get it away from the damp, but that didn't help.

The water is in the line and I imagine the damage is done. Surely the solution would be to replace the copper running from the telegraph pole. I am trying to find a way of convincing them that that's necessary as their solutions fail and probably cost them more in the long run with repeat visits. Had a look at the BT Wholesale checker to spy on her neighbours using their phone numbers. They're all synced between 45-55mbit.

Addition: Just conked out again, approx 1:45 after the last retrain. Upstream is back to where it was, but Downstream is quite a bit less. The speed however isn't really a concern. It's the stability.

====================================================================================
VDSL Training Status: Showtime
Mode: VDSL2 Annex B
VDSL Profile: Profile 17a
G.Vector: Disable
Traffic Type: PTM Mode
Link Uptime: 0 day: 0 hour: 0 minute
====================================================================================
VDSL Port Details Upstream Downstream
Line Rate: 8.501 Mbps 27.398 Mbps
Actual Net Data Rate: 8.502 Mbps 27.399 Mbps
Trellis Coding: ON ON
SNR Margin: 6.1 dB 12.6 dB
Actual Delay: 0 ms 0 ms
Transmit Power: 4.9 dBm 12.5 dBm
Receive Power: -8.7 dBm -14.8 dBm
Actual INP: 44.0 symbols 54.0 symbols
Total Attenuation: 0.0 dB 22.9 dB
Attainable Net Data Rate: 8.502 Mbps 40.966 Mbps
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 9.2 40.2 59.1 N/A N/A 17.7 47.6 73.7
Signal Attenuation(dB): 9.2 39.6 57.8 N/A N/A 25.6 47.2 76.5
SNR Margin(dB): 6.1 6.1 6.1 N/A N/A 12.7 12.6 0.0
TX Power(dBm): 0.4 -2.5 1.3 N/A N/A 10.7 7.7 -128.0
====================================================================================

VDSL Counters

Downstream Upstream
Since Link time = 31 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 55 sec
FEC: 1920 0
CRC: 535 0
ES: 10 0
SES: 10 0
UAS: 37 27
LOS: 1 0
LOF: 5 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 11 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 7 hours 41 min 55 sec
FEC: 2908 4
CRC: 535 1
ES: 10 1
SES: 10 0
UAS: 97 87
LOS: 1 0
LOF: 5 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Total time = 7 hours 41 min 55 sec
FEC: 2908 4
CRC: 535 1
ES: 10 1
SES: 10 0
UAS: 97 87
LOS: 1 0
LOF: 5 0
LOM: 0 0

Edited by milesharrison (Mon 28-Dec-20 02:01:14)

The Downstream has been further banded/capped by the DLM.
This time it is capped at 27.4Mb

Again, not a single CRC, ES or SES outside what is forced by the DLM when it lowered the banding.

There are ALWAYS 10 or 11 ES/SES when the DLM takes a line offline for a resync.

If the line wasn't capped it would sync around 41Mb.
Stable and with a reduced SNRM it would nudge 50Mb.

Banding isn't applied due to errors but due to multiple resyncs.

I've no idea what is causing the banding.

Do you keep rebooting the modem? Why does the total time counter keep resetting?
Rebooting the modem is seen as instability by the DLM.

Edited by j0hn83 (Mon 28-Dec-20 10:01:23)

In reply to a post by milesharrison:

I didn't notice it as I wasn't using the internet, but it retrained about 45 mins ago (00:15) which is almost the exact time it retrained last night. Is that a BT function for weak lines or does it suggest some sort of local interference? Also noticed the upstream line rate has dropped by about 2mbit from that posted in my previous line stats.

Keep a watch tonight and tomorrow ... if te same time, then there is a possibility of an external source. Heating/hot water circulating pump, street light, ...

There has been water ingress in the wires which is almost certainly the problem with her connection. I'm just wondering what way we can get a permenant solution to improve its reliability. One BT engineer moved (extended) the master socket to another room to avoid a bad corner of damp. That didn't help. The next one moved it up the wall by a meter to table level to help get it away from the damp, but that didn't help.

Sounds to me like you ought to get the damp issue within the property sorted first of all.

In reply to a post by j0hn83:

Again, not a single CRC, ES or SES outside what is forced by the DLM when it lowered the banding.

There are ALWAYS 10 or 11 ES/SES when the DLM takes a line offline for a resync.

Thank you for correcting my misreading of the OP's stats. When I have seen in particular numerous SES and a LOS prior to a resync I have wrongly attributed those SES to a line fault leading to a LOS both of which are reported by the modem/router stats. A modem/router system log may simply just say the DSL link is down and when one looks at the detailed stats numerous SES and a LOS can be seen and thus an incorrect assumption can be made.

Cheers