UPDATEI'm seeing the rumour mill starting again and misquoting
so I think we need to bring back some facts. I have some information direct from Openreach, some of the information is incomplete and needs further clarification, but from what I have so far, we may at least be able to fill in some of the blanks:
- The trials were only on Huawei cabs. There are no official plans yet to enable it on the ECI cabs.*
- The changes for those on Huawei cabs will start being rolled out on the 26th of May.
- The changes will be more of a DLM type configuration ie if the modem does not support G.INP then the (new) default profile can use both Interleaving and Error Correction if need be, but now by default Interleaving will be removed from the upstream The DSLAM is able to detect if the CPE is G.INP compatible or not
There is no definition of what BT call 'the fix'. Lines appear to have been put on FAST path, but its unclear if Error Correction has been turned off and what effect this has on the sync speed. The previous non Re-Tx profile automatically applied Interleaving. This is what has now been removed.
I not aware of an ECI modem software fix being rolled out to enable upstream g.inp as per what TP-Link has done. I have asked for clarification on this, but in the absence of hard facts, its possible that it could be a hardware limitation of the individual Customer Premise Equipment (CPE) for more information why this may be see information on G.INP below.
It
may be possible to update the HomeHub 5A's as they have different internal hardware to the ECI modems and
may have more memory and processing power due to it being a full modem/router. I believe it has a more powerful PSU but I dont know for sure.
More info on G.INP/Re-Transmission.Because of the way G.INP works, it requires a retransmission buffer which temporary stores all transmitted data until the other end acknowledges safe receipt of the data. If the receiving end Frame Check Sequence (FCS) is corrupt then data can be restored from the buffer. The modem/router is responsible for storing re-tx upstream data and obviously this requires that the CPE has sufficient memory and processing resources. G.INP typically causes latency of 1.5 - 2ms each way, but it is minimal compared to older form of
Interleaving and
Reed Solomon encoding.
Note that the 'local' device is responsible for buffering of the transmitted data. The CPE is responsible for buffering the upstream data it sends. The DSLAM is responsible for buffering any data it transmits ie it's upstream data which will be the CPE downstream.
Where this leaves the ECI DSLAMs, I dont know. I have asked for clarification but nothing has been forthcoming so far.
"although ECI equipment (either modems or DSLAMS) doesn’t currently support upstream retransmission"
Souce = ISPreview
To clarify further (This info is not from Openreach) - Interleaving causes DELAY - ie increase in latency/ping times. Interleaving alone does NOT cause reduction of sync speed.
- Error Correction is the transmission of redundant data so that data can be recovered in the event of small noise bursts. The redundant data causes overheads and the reduction in sync speed.
Historically BT switched on Error Correction and Interleaving at the same time, but they are totally independent. It is possible to use Error Correction on 'FAST' path. This will restore latency but will not recover any of the large losses in sync speed.
Because of the inability to log proper stats on the HomeHub5 & ECI modems, it is impossible to tell what Openreach have done to resolve this situation. I've seen mention that most seem to have recovered latency but not all have recovered the loss in sync speed. There is only one result that I've seen whose stats I would consider trustworthy. They do appear to have recovered some of their sync speed, but because that particular line was able to sync easily at 80/20 its unclear if Error Correction has been turned off. ** There is still the odd report of non recovery of full sync speed :/
----
*bar a few trial cabinets. (We are already aware of these ie Martlesham Heath).
** Line is now syncing at 79906 with a max data rate of 88845, so there is a small amount of overhead less in this case. Because the max attainable is more than the sync, its unclear how much of this is overheads and how much it would affect lines previously unable to attain the full 80/20.