Kitz Forum
Announcements => News Articles => Topic started by: Ixel on November 05, 2017, 03:40:54 PM
-
https://www.ispreview.co.uk/index.php/2017/11/openreach-test-low-level-error-correction-fttc-broadband-lines.html
Openreach (BT) has started a new Proof of Concept (PoC) to test the application of “low level error correction” on new Fibre-to-the-Cabinet (FTTC / VDSL2) broadband lines, which they hope could result in fewer customers raising fault reports.
At present new FTTC lines are initially provided on a line profile with their speed capped at the product rate and no error protection. “This can lead to [a] customer raising faults before [Dynamic Line Management] starts working due to excessive data errors which impact their broadband service,” said Openreach.
I assume this will mean that traditional interleaving will become the default profile if this goes live, and then hopefully ECI connections would get fastpath eventually or Huawei connections G.INP instead. Another clever way to hide problems if so, imagine it, an engineer turns up to do a DLM reset but it's not fastpath so CRC errors won't really show up on their JDSU/EXFO.
-
I thought that traditional interleaving was already the default profile (the "low" variant) ... since when it was introduced as a workaround for the ECI G.INP issue. It would then tend to be switched back after 2 days.
Or did that only happen as part of a DLM reset?
-
I thought that traditional interleaving was already the default profile (the "low" variant) ... since when it was introduced as a workaround for the ECI G.INP issue. It would then tend to be switched back after 2 days.
Or did that only happen as part of a DLM reset?
As far as I know it's the default for Huawei due to G.INP support. ECI has always been fastpath first for me, whether it's a new connection, DLM reset or a regrade.
-
As I believe it to be, though happy to be corrected...
ECI is fastpath by default. An ECI line will go straight to fastpath after a DLM reset.
Huawei is interleaved by default. It will go straight to interleaving after a DLM reset.
About the news post.. They can apply a small amount of FEC without adding any delay, as they do with the upstream. Perhaps that's what is meant by "low level" error correction.
-
As I believe it to be, though happy to be corrected...
ECI is fastpath by default. An ECI line will go straight to fastpath after a DLM reset.
Huawei is interleaved by default. It will go straight to interleaving after a DLM reset.
About the news post.. They can apply a small amount of FEC without adding any delay, as they do with the upstream. Perhaps that's what is meant by "low level" error correction.
Hopefully, I wouldn't mind if they did that. I noticed that for some reason the DrayTek will negotiate with an R value of 16 on both upstream and downstream whether fastpath or not, where something like the HG612 will have an R value of 0 on the downstream and an R value of 16 on the upstream if fastpath (interleaving can vary though, I've seen 10 personally). It might explain partly why the DrayTek manages my connection better than the HG612 or Zyxel previously.
-
ECI is fastpath by default. An ECI line will go straight to fastpath after a DLM reset.
Huawei is interleaved by default. It will go straight to interleaving after a DLM reset.
Right. The Huawei behaviour because they need to avoid G.INP, while the ECI behaviour because there is no G.INP that needs to be avoided. Yet.
About the news post.. They can apply a small amount of FEC without adding any delay, as they do with the upstream. Perhaps that's what is meant by "low level" error correction.
That's what I assume. Or at least "less delay" than the current 8ms
-
Right. The Huawei behaviour because they need to avoid G.INP, while the ECI behaviour because there is no G.INP that needs to be avoided. Yet.
That's what I assume. Or at least "less delay" than the current 8ms
If it is a reduced delay then I wouldn't even mind if they did a delay of up to a few milliseconds, I tried 2ms once on the ASUS a while ago when I was using it and it made a fairly significant difference to some trickling CRC errors.