FTTC and Error Seconds and Severe Error Seconds

Hi

After fixing my broadband a couple of weeks ago by changing the faceplate back to MK2 from MK3, I have a question probably a silly question but thought I would check. How does the FTTC DLM calculate error seconds in terms of downstream and upstream. For example when the DLM looks at your line every 24 hours and detects how many ES you got in every 15 minute section does it add them all up for both upstream and downstream so say DS got 45 ES in 24 hours and US got 113 ES in 24 hours, would the DLM then add them both together similary as the HG612 does and categorizes your line as performing below the expected parameters. Or is it separate for each stream UL and DL?

As for SES errors how many of them in 15 sections can there be or in 24 hours before the DLM takes action?

The reason I ask is because I have been trying different modem cables, bit ironic but aluminium DSL cables work better on my line (copper creates loads more errors and lower sync). My DL ES per 24hr averages now about 5-8 ES and no SES which is the best ive ever seen (See stats below). The only thing is the DLM took INP off upstream and now creating lots of ES on that side and not sure why.

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 5349 Kbps, Downstream rate = 26760 Kbps
Bearer: 0, Upstream rate = 5283 Kbps, Downstream rate = 22922 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.5 6.0
Attn(dB): 24.7 0.0
Pwr(dBm): 7.1 7.1
VDSL2 framing
Bearer 0
MSGc: 22 33
B: 47 165
M: 1 1
T: 64 5
R: 16 16
S: 0.0666 0.9979
L: 7688 1459
D: 973 1
I: 64 182
N: 64 182
Counters
Bearer 0
OHF: 102815544 230503
OHFErr: 195 634
RS: 550916781 2363730
RSCorr: 82872532 3645
RSUnCorr: 5457 0

Bearer 0
HEC: 1330 0
OCD: 95 0
LCD: 95 0
Total Cells: 2185505112 0
Data Cells: 575257318 0
Drop Cells: 0
Bit Errors: 0 0

ES: 62 540
SES: 0 0
UAS: 21 21
AS: 439947

Bearer 0
INP: 8.00 0.00
INPRein: 0.00 0.00
delay: 16 0
PER: 4.27 16.27
OR: 52.35 19.16
AgR: 22974.25 5302.23

Bitswap: 306452/306581 1297/1343

Total time = 1 days 2 hours 12 min 48 sec
FEC: 82872532 3645
CRC: 195 634
ES: 62 540
SES: 0 0
UAS: 21 21
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 12 min 48 sec
FEC: 152433 7
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 157815 13
CRC: 2 4
ES: 1 4
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 2 hours 12 min 48 sec
FEC: 1457012 78
CRC: 4 19
ES: 2 17
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 16143513 811
CRC: 29 116
ES: 7 106
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 5 days 2 hours 12 min 25 sec
FEC: 82872532 3645
CRC: 195 634
ES: 62 540
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

In reply to a post by Computerman142:

Or is it separate for each stream UL and DL?

Separate

In reply to a post by Computerman142:

As for SES errors how many of them in 15 sections can there be or in 24 hours before the DLM takes action?

That's less well known. However, the SIN that documents requirements for VDSL2 modems does require the modem to report SES back to the DSLAM, so it is possible it is looked at.

In reply to a post by Computerman142:

The only thing is the DLM took INP off upstream and now creating lots of ES on that side and not sure why.

Every bit-sized perturbation causes a bit error. With a non-zero INP value, there are protection and recovery mechanisms that mean some of those bit errors are fixed. By a forward error correction or by retransmission.

If the bit error cannot be fixed by one of those two mechanisms, it becomes a CRC error, which triggers an ES. Depending on the density of bit errors, one ES might represent more than one CRC, and one CRC might represent one or more bit errors.

If the bit error is fixed, it does not contribute to either count.

When INP gets reduced to zero, there is less protection. The environment likely causes the same number of bit errors ... but because there is no protection, all of them will go on to create a CRC and an ES. End result: you see higher counts for CRC and ES.

They aren't aluminium modem cables, they are tinned copper.

If they were, they'd be very fragile.