From studying error counts at the DSLAM end, it's evident that the HG612 doesn't record RsUnCorr(ectables) properly. It records errors okay with ADSL connections, but not with VDSL connections. In the upstream direction of a VDSL2 connection, RsUncorr errors are not recorded at all.
Can you test this again, with DS interleaving on at say, a depth of 400 or 500 and US Interleaving on at some depth?
I was just saying to Colin that this would be a useful test. I will have a look at setting up the experiment. Interleaving isn't unfortunately configurable to the extent of setting the exact depth. Not even by DLM.
The Huawei DSLAM has a channel-profile parameter that allows the *maximum* interleaved *delay* to be set (and the inter-related *minimum* number of symbols to be protected by INP) but whether or not that maximum is fully utilised, or just a fraction of it, is up to the DSLAM.
So we can create a maximum of, say, 8ms delay in each direction, but the algorithm in the DSLAM will only increase the interleaver depth as much as needed, presumable to try and satisfy some BER, as well as keeping within that delay limit.
I saw downstream RSUnCorr counts when my VDSL2 connection had DS Interleaving at a depth of around 400 or so, but no upstream counts (possibly because upstream Interleaving was OFF):-
The DSLAM does appear to be recording *upstream* uncorrectable errors that the HG612 doesn't record. From a quick google it looks like it's a common issue with this and other Broadcom 6368 devices.
Interleaving and Forward Error Correction are not synonymous though. It's possible (maybe normal practice) to still use FEC without interleaving. The reverse isn't true though. So setting it to fastpath could still see FEC (RSCorr / RSUnCorr) errors reported.
cheers, a