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

Ah, is it that 2nd line pwning it? Yeah, I was thinking of switching to Virgin Media if/when it comes here, but then I'd loose the interest DSL technology gives me.

Currently away and the FEC's are still accumulating at quite a high rate, so it's nothing in our house. Brilliant.

It's not an issue.

Stop trying to make it one.

In reply to a post by WilliamGrimsley:

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.

I'm really not sure that you do understand how FEC works.

The whole point of Forward Error Correction is that you build sufficient redundancy into the bitstream not only to detect errors but to be able correct them in most cases. On your line, DLM has tuned the parameters to the point where, though FEC is coming into play a fair bit, almost all the errors are being dealt with by FEC and those that are not corrected by FEC are being dealt with by the higher level Reed Solomon and retransmission mechanisms.

Bitstream corruption is a fact of life for many real life DSL circuits, as they're using carriers way into HF (and, I believe, beyond 30MHz into VHF for G.FAST) on twisted pair cabling that was originally deployed for a few kHz of baseband voice. That DSL works so well in often hostile real life conditions on less than brilliant cabling is a testament to how well it is designed. Though you have told us several times how you think DLM is rubbish (or words to that effect), it's doing what it is supposed to on your circuit; had DLM not selected that level of FEC you would likely either have service affecting problems or would have to run at a lower sync speed.

The mechanisms employed by DLM and the DLM algorithm itself are not always going to succeed. Sometimes DLM will do something inappropriate. Sometimes there is a genuine fault in the cable plant or the RF environment is so hostile that the noise is service affecting. I'm not the only person in these forums and far from the only person in the country who holds a licence permitting me to put a 26dBW carrier with DSL hostile modulation applied into the feedpoint of an efficient directional antenna in various parts of the spectrum used by DSL (though, in my case, I only have equipment capable of 20dBW input to the feeder and do not have strongly directional antennas).

It can be difficult enough to track down a source of service affecting noise with a proper REIN meter or a spectrum analyser plus, in either case, the skills and experience to use these tools effectively. You might just succeed in finding something on your premises with a medium wave radio, but it may well prove a futile search - and, in any event, you do not have a service affecting issue. DLM has tuned your line parameters appropriately and the statistics show that the error correction and mitigating measures are working well.

Absent some major change in conditions, such as a line plant fault, it is unlikely that your increasing FEC count will turn into a service affecting fault, which is why so many posters are telling you to stop obsessing over the statistics from your router. If your line suffers at some point in the future from increased crosstalk, Openreach do not regard this as a fault; they have taken the perfectly reasonable business decision not to make a widespread roll-out of VDSL2 vectoring, but to put their investment into ultrafast roll-out (G.FAST, which always uses vectoring, and FTTP).

It can be difficult enough to track down a source of service affecting noise with a proper REIN meter or a spectrum analyser plus, in either case, the skills and experience to use these tools effectively.

Yep, lots of things produce noise audible on an medium wave radio, this does NOT mean they are service affecting.

I'm not making it an issue, why would I want to do that? Also, maybe try using "please"...

Edited by deleted (Thu 18-May-17 21:16:08)

Ok, thanks for the incredibly detailed explanation, David. I understand some of your points there, but most of it went straight over the top of my head! Makes me realise that I only have a basic understanding of DSL! I know I'm coming over that I'm obsessing, but honestly, I really am not, I'm just interested in what could be causing all these retransmissions, because if they don't need to be there, they shouldn't be. Anyway, when I return home, I'll try and find an AM radio and see if I can find anything that could be causing the problem. If I can't, fine. I would then presume it is a device that is in another property.

Edited by deleted (Fri 19-May-17 09:18:49)

I know that, but it would be interesting to see what is causing the FEC's.

I do understand FTTC users will try there best to reduce any internal noise getting into ones modem, now i think in the past we discussed the use of ethernet powerline adapter can increase this noise and see a increased in FEC errors on the modem well it did for me.

So if you could use X amount of LAN cable just as a trial and put the PLA's aside and monitor your stats for a few days or a week could help in ruling that out as a possible cause.

In reply to a post by WilliamGrimsley:

Ok, thanks for the incredibly detailed explanation, David. I understand some of your points there, but most of it went straight over the top of my head! makes me realise that I only have a basic understanding of DSL!

As you have been told by several people many times before you went on a short sabbatical, and as you yourself have said at least three times. What is it that makes you repeatedly "unrealise" it?

I know I'm coming over that I'm obsessing, but honestly, I really am not,

You really, really are.

I'm just interested in what could be causing all these retransmissions,

FECs are not retransmissions.

because if they don't need to be there, they shouldn't be.

They do need to be there. They need to be there precisely because they prevent excess retransmissions.

Anyway, when I return home, I'll try and find an AM radio and see if I can find anything that could be causing the problem. If I can't, fine. I would then presume it is a device that is in another property.

A better way of finding if there is anything in your property causing the errors that are corrected by the FEC system is to turn off at the mains so nothing left on standby everything else in the property powered by electricity. Not forgetting fridges, freezers and even a gas cooker if you have one. Nearly all modern gas cookers are kept alive by electricity.

As for finding the source by using an AM radio, it doesn't need to be in a property. A mild electric storm (or thunderstorm) miles away can send you enough electrostatic noise to cause your modem to re-sync at a ridiculously low speed because it hasn't got the processor power to do all the corrections or handle the resultant retransmissions.

Phone wires passing over electricity substations, passing within a few metres of a workshop with welding machines, dodgy street lights particularly the new LED ones, faulty traffic lights, road works anywhere between you and the cabinet on FTTC or you and the exchange on ADSLx, etc. etc.

Exactly Bob, as I had previously said, not everything that makes a radio holler is affecting ones DSL service. Locating proper sources of interference is by no means an exact science.
The phrase 'dark ju-ju' springs to mind.

I removed the powerline adapters and it made a huge difference. But, there are still these spikes.

Spikes of non issue causing FEC's?

In reply to a post by RobertoS:

As you have been told by several people many times before you went on a short sabbatical, and as you yourself have said at least three times. What is it that makes you repeatedly "unrealise" it?

Yes, I went on a short "sabbatical", because everyone was becoming irritating, most of that was caused by me, but tbh not all of it. Anyway, not sure what you mean, but what I can say is there are a few members including yourself that have a better understanding of DSL than me, which I respect and am willing to learn further. I do, however, feel I have enough understanding of DSL to apply it in a self employed environment.

In reply to a post by RobertoS:

They do need to be there. They need to be there precisely because they prevent excess retransmissions.

I know they need to be there, if there's noise present, but if that noise was removed, then there would be less FEC's meaning a lower likelihood of CRC's.

In reply to a post by RobertoS:

A better way of finding if there is anything in your property causing the errors that are corrected by the FEC system is to turn off at the mains so nothing left on standby everything else in the property powered by electricity. Not forgetting fridges, freezers and even a gas cooker if you have one. Nearly all modern gas cookers are kept alive by electricity.

Right, fair enough. I'll try that if my parents are willing to do so. LOL.

In reply to a post by RobertoS:

As for finding the source by using an AM radio, it doesn't need to be in a property. A mild electric storm (or thunderstorm) miles away can send you enough electrostatic noise to cause your modem to re-sync at a ridiculously low speed because it hasn't got the processor power to do all the corrections or handle the resultant retransmissions.

Interestingly, we had quite a severe overhead thunderstorm last year! Yes, it caused a lot of SES, but not enough for the line to resync! Maybe with G.INP you need a very close lightning strike to cause a resync. Just shows how powerful G.INP is.

Edited by deleted (Fri 19-May-17 09:45:10)

Yes, but that's not the point. I don't want you to look like a fool when the device causing the issue starts causing my line to resync, when you told me to leave it.

You don't know that it will though. You can't predict the future.

Until it becomes service affecting (if it ever does), you're wasting your time.

True, but better to be safe than sorry.

A couple of weeks ago something happened on my line overnight that sent the error correction into overdrive with over 2.1 million FECs per minute and and ES up to around 680/hour and the line was still synced and sort of usable albeit slow. It never disconnected in the 8 hours the problem persisted.

In reply to a post by WilliamGrimsley:

I know they need to be there, if there's noise present, but if that noise was removed, then there would be less FEC's meaning a lower likelihood of CRC's

This where you may understand what you are saying. I think I do, but what you have written is confusing rubbish. Reducing FECs does not mean a lower likelihood of CRCs. Your post says that less FECs causes the reduced likelihood of CRCs.

No! Reducing noise is expected to reduce both FECs and CRCs. Neither causes the other.

Interestingly, we had quite a severe overhead thunderstorm last year! Yes, it caused a lot of SES, but not enough for the line to resync! Maybe with G.INP you need a very close lightning strike to cause a resync. Just shows how powerful G.INP is.

Yes, I was laying it on a bit thick about a distant storm causing a re-sync, but it has happened to me twice due apparently to lightning strikes on overhead high-voltage power lines seven miles away.

These effects are also present on ADSLx, which does not have G.INP. Which is, in case you've forgotten, largely a re-transmission system to obviate the need for high levels of interleaving. It doesn't remove it, but the turns out to be more efficient on FTTC than such heavy interleaving.

In reply to a post by WilliamGrimsley:

True, but better to be safe than sorry.

You are obsessing.

I wouldn't say it's confusing rubbish at all! I don't see anyone else having a problem with what I'm saying, so I think you need a reality check.

Yes, I know how G.INP removes the need for large amounts of interleaving, thank you!

Edited by deleted (Fri 19-May-17 15:55:37)

No, just curious.

Agreed, both tiresome and repetitive. Rather than interesting and informative makes for a quite boring read.

Who else is reading?

Still less, how many people even answer any of your queries other than those who try to put you straight and/or tell you to just stop obsessing over things that look perfectly normal results from communications software doing what it is designed to do?

In threads where you advise people, you are often close enough to correct for intervening not to be needed. Often however you misinform people who really do need the right answers where you don't know the answer but guess based on what you do partially know.

You said once you don't come here to be constantly told what you are posting is wrong. Easy. Only post when you know what you are saying is right.

And you've wasted enough time of good people about a curiosity

My recommendation drop the topic and move onto actually enjoying and using your connection rather than turning it into a full time hobby in itself, like those who polish a car all the time but never take it anywhere

I know you're only trying to come over with good grace, but that's a little bit rude, IMO... I'm not that sad! Anyway, I'll leave it here. I understand that I've taken this too far, and yes I agree, it has become rather boring!

Edited by deleted (Fri 19-May-17 22:17:36)

Think you've summed that up very well, Bob. I'll leave this here and take the advice given on this thread. Think I need to offer a big apology to everyone on this thread. So, I do apologise and will act accordingly to stop this happening again.

Edited by deleted (Fri 19-May-17 18:43:23)

Thank you Mr S, well said.