Good performance but high FEC

We had Infinity installed on Monday and <touch wood>, very pleased with speed and performance. Prior to the stats below when Interleave was switched on, the CRC errors were around 300,000 each day. Since Interleave, CRC / ES now look good but seems high FEC, which I understand are the corrected errors. Is this OK or will DLM try to fix these now?

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 18869 Kbps, Downstream rate = 54484 Kbps
Path: 0, Upstream rate = 18914 Kbps, Downstream rate = 54327 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 3.3 6.0
Attn(dB): 0.0 0.0
Pwr(dBm): 13.0 6.8
VDSL2 framing
Path 0
B: 63 239
M: 1 1
T: 64 64
R: 16 14
S: 0.0375 0.4037
L: 17077 5033
D: 861 1
I: 80 127
N: 80 254
Counters
Path 0
OHF: 26831484 2307959
OHFErr: 134 31
RS: 856677230 3322129
RSCorr: 105514923 107
RSUnCorr: 1181 0

Path 0
HEC: 275 0
OCD: 0 0
LCD: 0 0
Total Cells: 764543754 0
Data Cells: 1811166512 0
Drop Cells: 0
Bit Errors: 0 0

ES: 115540 543
SES: 168 0
UAS: 86 86
AS: 48458

Path 0
INP: 3.00 0.00
PER: 1.79 6.45
delay: 8.00 0.00
OR: 106.73 34.67

Bitswap: 10402 3402

Total time = 1 days 7 hours 54 min 28 sec
FEC: 105514923 577
CRC: 134 594
ES: 115540 543
SES: 168 0
UAS: 86 86
LOS: 20 0
LOF: 22 0
Latest 15 minutes time = 9 min 28 sec
FEC: 801302 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 1340605 0
CRC: 1 1
ES: 1 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 7 hours 54 min 28 sec
FEC: 67632609 19
CRC: 88 12
ES: 33 12
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 37882314 191
CRC: 46 56
ES: 27791 40
SES: 29 0
UAS: 17 17
LOS: 5 0
LOF: 5 0
Since Link time = 13 hours 27 min 37 sec
FEC: 105514923 107
CRC: 134 31
ES: 49 23
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0

thanks for the info its useful to those of us who discuss the DLM mechanism, so you had 300k crc errors a day and DLM managed the line.

If you had that many CRC then inveitbly the FEC will be very high, from my experience on adsl, FEC was many multiple of the CRC it fixed. So I thnik what you are seeing is normal for your line, but dont worry FEC are fixed errors not real errors. Your CRC count now looks excellent.

Your DS Interleaving depth looks fairly high (861) & US is still OFF (1)

D: 861 1

Interleaving has also introduced DS Impulse Noise Protection at a reasonably low level:-

INP: 3.00 0.00

It has also introduced a DS delay (probably noticed in increased ping times:-
delay: 8.00 0.00

These measures do slow a connection down (sync speed-wise), but they do make it more stable, also dealing with some errors on the fly (RSCorr/FEC), which can sometimes actually end up quicker in realtime use than having Interleaving OFF & errored data needing to be re-transmitted.

Thanks both for some really useful feedback. I will see how things go over the next few days but so far it seems fast, stable and working at the speeds BT estimated when ordering. So up to now, quite happy

In reply to a post by dgilbert2:

Prior to the stats below when Interleave was switched on, the CRC errors were around 300,000 each day. Since Interleave, CRC / ES now look good but seems high FEC, which I understand are the corrected errors. Is this OK or will DLM try to fix these now?

The general principle of DLM is to reduce CRC errors to FEC ones (or, in the stats, OHFErr into RSCorr), and it employs tools of either setting FEC/Interleaving to various levels (which takes an overhead off the top of your speed), or limiting speeds by employing banding.

Adding FEC and interleaving is the part that creates the RSCorr, while banding would attempt to reduce (or get rid of) both the CRC errors *and* the RSCorr. DLM usually, as a first resort, employs FEC/interleaving. As a second resort, it increases the level, and only as a last resort does seem to employ banding.

It isn't my experience that DLM will attempt to do anything about a high level of RSCorr. It only really seems to care about the CRC count, at least when choosing whether to turn interleaving on (or up).

Your stats don't seem to be suffering enough CRC errors to warrant further intervention right now, but you do have a high level of RSCorr. With ongoing, itty-bitty "correctable" interference, it is easy to see that it may vary somewhat over time, so you should expect that DLM may well alter the amount of interleaving, going up & down.

Right now, these parameters are chosen by DLM for you:

INP: 3.00 0.00
delay: 8.00 0.00

which are fairly standard specifications for interleaving (3 symbols of noise protection, and 8ms maximum delay).

The sync negotiation has taken those 2 parameters, and chosen FEC and interleaving details of:

B: 63 239
R: 16 14
D: 861 1
I: 80 127
N: 80 254

As someone mentioned, the depth (D) is 861, which is an indication of how "spread out" your data is sent, in order for consecutive bytes to not be hit by the same burst of noise.

The FEC protection is running at a 20% overhead (R/N, or 16/80 bytes), which is a mid-level. I've seen higher and lower.

If you see any change in error rates, then DLM will most likely choose new INP and Delay values, and you will see new D, R and N values.

Note also that upstream has employed FEC (R/N is 14/254, or 5%) without interleaving (D=1). That is using a bit of the upstream bandwidth, but not causing any extra latency.

Do you know how long your line is, or how far away the cabinet is?

Thanks WWWombat for a really helpful reply. From what I can gather we are around 500m from the cabinet with a BT estimation of 56.4/19 which is pretty much what I'm getting.

As you say, I will have to wait and see if any further changes are made but if they are I hope they will be minor