Reducing HEC Error's ADSL2?

Hi

Been looking at a connection (stats to follow) its a long ADSL2 line, I noticed the HEC errors are high..

What would be the best way to reduce these errors with losing too much speed,

I was thinking some basic Interleaving might help or maybe having the target SNR changed to 6/9db...

Currently line stats:

Mode: ADSL_G.dmt.bis
Traffic Type: ATM
Status: Up
Link Power State: L0

Downstream Upstream
Line Coding(Trellis): On On
SNR Margin (0.1 dB): 31 65
Attenuation (0.1 dB): 590 350
Output Power (0.1 dBm): 175 121
Attainable Rate (Kbps): 4,552 1,092

Path 0 Path 1
Downstream Upstream Downstream Upstream
Rate (Kbps): 4,183 864 0 0

MSGc (# of bytes in overhead channel message): 59 14 0 0
B (# of bytes in Mux Data Frame): 130 108 0 0
M (# of Mux Data Frames in FEC Data Frame): 1 1 0 0
T (Mux Data Frames over sync bytes): 1 1 0 0
R (# of check bytes in FEC Data Frame): 0 0 0 0
S (ratio of FEC over PMD Data Frame length): 0.9943 4.0000 0.0 0.0
L (# of bits in PMD Data Frame): 1054 218 0 0
D (interleaver depth): 1 1 0 0
Delay (msec): 0 1 0.0 0.0
INP (DMT symbol): 0.00 0.00 0.0 0.0

Super Frames: 0 0 0 0
Super Frame Errors: 10,462 3,961 0 0
RS Words: 0 637,061 0 0
RS Correctable Errors: 0 0 0 0
RS Uncorrectable Errors: 0 0 0 0

HEC Errors: 17,624 3,632 0 0
OCD Errors: 0 0 0 0
LCD Errors: 0 0 0 0
Total Cells: 6,284,624 1,293,974 0 0
Data Cells: 5,550 18,784 0 0
Bit Errors: 0 0 0 0

Total ES: 5,960 2,317
Total SES: 52 0
Total UAS: 98 98

The HEC process is something similar to the CRC mechanism for user data, but is applied to the ATM cell headers. It is more advanced, as it can correct single-bit errors, and detect multi-bit errors.

FEC, with or without interleaving, only applies to user data, so would have no effect on the HEC counters.

It seems likely that increasing the noise margin would help you, but presumably at the cost of about 0.5Mbps for each 3dB.

Is it worth doing?

I've never been sure whether the "HEC errors" counter indicates just the multi-bit errors (ie the uncorrectable ones), or if it includes the single-bit errors (ie the correctable ones) too.

However, any ATM cell that is dropped because of an uncorrectable HEC violation will ultimately contribute to a CRC violation. 17,000 HEC errors contribute to 10,000 CRC errors, but the header only comprises 10% of the cell size. Perhaps that tells us something.