Downstream FEC Spikes

Hi guys,

Here's a telnet output recently from my Billion BiPAC 8800AXL router:

Broadband Router
Login: admin
Password:
> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 7776 Kbps, Downstream rate = 41615 Kbps
Bearer: 0, Upstream rate = 7776 Kbps, Downstream rate = 41399 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 6.4 6.4
Attn(dB): 26.4 0.0
Pwr(dBm): 12.2 6.3

VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 239
M: 1 1
T: 0 41
R: 10 0
S: 0.1877 0.9806
L: 10827 1958
D: 8 1
I: 254 120
N: 254 240
Q: 8 0
V: 0 0
RxQueue: 33 0
TxQueue: 11 0
G.INP Framing: 18 0
G.INP lookback: 11 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0

Counters
Bearer 0
OHF: 0 41111
OHFErr: 0 47
RS: 721015368 1115013
RSCorr: 102528 0
RSUnCorr: 0 0
Bearer 1
OHF: 2114427 0
OHFErr: 0 0
RS: 12686195 0
RSCorr: 1441 0
RSUnCorr: 0 0

Retransmit Counters
rtx_tx: 67633899 0
rtx_c: 38322 0
rtx_uc: 0 0

G.INP Counters
LEFTRS: 48 0
minEFTR: 41383 0
errFreeBits: 21430451 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2702737137 0
Data Cells: 129376789 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 41
SES: 0 0
UAS: 29 29
AS: 33969

Bearer 0
INP: 48.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 10.09
OR: 0.01 25.37
AgR: 41441.08 7801.52

Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01

Bitswap: 3924/3925 31/31

Total time = 9 hours 26 min 38 sec
FEC: 102528 0
CRC: 0 47
ES: 0 41
SES: 0 0
UAS: 29 29
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 11 min 38 sec
FEC: 3584 0
CRC: 0 5
ES: 0 5
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 5479 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 = 9 hours 26 min 38 sec
FEC: 102528 0
CRC: 0 47
ES: 0 41
SES: 0 0
UAS: 29 29
LOS: 0 0
LOF: 0 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
Since Link time = 9 hours 26 min 7 sec
FEC: 102528 0
CRC: 0 47
ES: 0 41
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

Are the amount of FEC's shown that high? I've noticed that occasionally (though sometimes frequently) there are several thousands per minute. So, something must be interfering to a degree, but I can't think of anything else other than our heat pump system that could be causing it. The router is connected to the master socket via a master socket 5C and MK4 and there are no extensions.

Thanks,

William

Edited by deleted (Tue 16-May-17 18:45:50)

Bump!

A lot worse this evening!

Broadband Router
Login: admin
Password:
> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 7776 Kbps, Downstream rate = 41611 Kbps
Bearer: 0, Upstream rate = 7776 Kbps, Downstream rate = 41399 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 6.3 6.6
Attn(dB): 26.4 0.0
Pwr(dBm): 12.2 6.3

VDSL2 framing
Bearer 0
MSGc: -6 26
B: 243 239
M: 1 1
T: 0 41
R: 10 0
S: 0.1877 0.9806
L: 10827 1958
D: 8 1
I: 254 120
N: 254 240
Q: 8 0
V: 0 0
RxQueue: 33 0
TxQueue: 11 0
G.INP Framing: 18 0
G.INP lookback: 11 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0

Counters
Bearer 0
OHF: 0 834810
OHFErr: 0 174
RS: 2670932896 2163573
RSCorr: 1449461 0
RSUnCorr: 0 0
Bearer 1
OHF: 7832529 0
OHFErr: 1 0
RS: 46994802 0
RSCorr: 1695 0
RSUnCorr: 1 0

Retransmit Counters
rtx_tx: 67694261 0
rtx_c: 98683 0
rtx_uc: 0 0

G.INP Counters
LEFTRS: 242 0
minEFTR: 41399 0
errFreeBits: 79384979 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1423181394 0
Data Cells: 271047928 0
Drop Cells: 0
Bit Errors: 0 0

Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0

ES: 0 142
SES: 0 0
UAS: 29 29
AS: 125831

Bearer 0
INP: 48.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 10.09
OR: 0.01 25.37
AgR: 41441.08 7801.52

Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01

Bitswap: 45553/45562 456/457

Total time = 1 days 10 hours 57 min 40 sec
FEC: 1449461 0
CRC: 0 174
ES: 0 142
SES: 0 0
UAS: 29 29
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 12 min 40 sec
FEC: 24894 0
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: 18852 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 = 10 hours 57 min 40 sec
FEC: 239110 0
CRC: 0 98
ES: 0 78
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1210351 0
CRC: 0 76
ES: 0 64
SES: 0 0
UAS: 29 29
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 10 hours 57 min 11 sec
FEC: 1449461 0
CRC: 0 174
ES: 0 142
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0

William why are you worrying about FEC spikes. I get several thousand a day and it is normal for this technology and they show that Error Correction is working, it does not affect data quality on your computer. Now CRCs are the ones to worry about they are not being corrected.

I'm not worrying, just curious. The device(s) that are causing the downstream FEC spikes could go faulty and produce more interference. I could leave it as is, but prevention is better than cure.

I would say you were worrying judging by your bump post and the frowny smiley.

You need an AM radio tuned to 620khz and plod around the house see if you can find any interference or you could ask your ISP for an SFI engineer but that will likely cost. If you can't find anything in the house it is likely external and unlikely to be tracked down and fixed.

I would be entirely unconcerned about the downstream FEC considering that the FEC is set at a level that is proving effective in avoiding CRCs and errored seconds. You can see that both the Reed Solomon and retransmission mechanisms are working effectively on Bearer 0 as the failure counters for those layers (RSUnCorr and rtx_uc respectively) are 0, so those measures are mopping up what FEC is failing to deal with.

VDSL2, by its nature, cannot be error free, which is why there are various error mitigations built into the system. The aim of FEC is to deal with as many errors as possible without them appearing at higher, potentially service affecting, levels. The small proportion of errors that FEC has failed to mitigate are being dealt with by higher level mechanisms effectively. This implies that DLM has set appropriate parameters for your line which appears to be working normally.


As I've said to you previously, the key question is whether you have a service affecting issue. You do not disclose such an issue - and in the absence of a service affecting issue, nobody at Openreach or your ISP is going to do anything.

Thanks, Banger. I will have a look around with a radio. Thanks for the explanation, David. I do understand how FEC's work and yes, I agree I shouldn't be concerned about them. But, I just want to find what's causing them early before it potentially causes an issue down the line.

Edited by deleted (Thu 18-May-17 09:02:03)

I think you're okay.

Latest 15 minutes time = 3 min 26 sec
FEC: 1784870 0
CRC: 0 0
ES: 0 0

Latest 1 day time = 15 hours 48 min 26 sec
FEC: 493085655 126
CRC: 0 14
ES: 0 13

Thanks! I'd get that checked, that's a crazy amount of FEC's!

No point. I know the cause, it's still within speed range, as you saw no errored seconds so correction doing its job, and will replace the line with a Virgin Media cable service in time