/etc/init.d/ifx_cpe_control_init.sh
#197
xTM_Mgmt_Mode=""
wanphy_phymode=0:
BS_ENA=1
SRA_ENA=1
+++ RETX_ENA=1 ++++
CNTL_MODE_ENA=0
CNTL_MODE=0
Taken from ITU G.998.4 - The RE-TX modes that can be set on the DSLAM
11.1.13 Retransmission Mode (RTX_MODE)
The RTX_MODE is a configuration parameter used to control activation of retransmission during initialization.
This parameter has 4 valid values:
0: RTX_FORBIDDEN: ITU-T G.998.4 retransmission not allowed.
1: RTX_PREFERRED: ITU-T G.998.4 retransmission is preferred by the operator.
(i.e., if ITU-T G.998.4 RTX capability is supported by both XTU's, the XTU's shall select ITU-T G.998.4 operation for this direction).
2: RTX_FORCED: Force the use of the ITU-T G.998.4 retransmission.
(i.e., if ITU-T G.998.4 RTX capability in this direction is not supported by both XTU's or not selected by the XTU's, an initialization failure shall result).
NOTE – Due to the optionality of ITU-T G.998.4 retransmission in upstream direction, the use of RTX_FORCED in upstream may lead to initialization failure, even if the XTU is supporting ITU-T G.998.4 (in downstream).
3: RTX_TESTMODE: Force the use of the ITU-T G.998.4 retransmission in the test mode described in clause 10.4.
(i.e., if ITU-T G.998.4 RTX capability is not supported by both XTU's or not selected by the XTU's, an initialization failure shall result).
In there (Ive highlighted one of them in green) explanation why Modems that don't have the updated firmware would fail to get internet access and the ECI modem Issue 1 situation described on the first page. So now the ECI modems apparently have RETX enabled, yet it doesnt seem to be able to fully support it?
Turning off DLM stops the DLM system trying to push RTX parameters to the modem which it cant understand, those parameters are used at initialisation to calculate the sync speed and bit loading etc and its why without the fix, the modem would not be able to go through all the stages of
initialisation----------
There's quite a nice paper I've found about RETX management. Bear in mind its written by ASSIA so techniques may not be quite the same as with the BT system, It recaps and confirms a few things we already knew but its written so that most people should be able to understand the basics of using RETX in a DLM environment.
http://www.assia-inc.com/products-services/pdf/DSL_Expresse_Retransmission.pdfDLM can switch over to FEC & Interleave if it detects that ReTX isn't working/keeping the line stable.
In the case of issue 2 RTX is preferred, but there are cases when it will push over to an Interleave & FEC DLM profile.
------------
We already know that the system is pushing over to Interleave & FEC for non compliant modems but what is uncertain is if those parameters are too harsh OR if its something in the DLM being interpreted unexpectedly by these modems.
Is the 'hybrid solution' causing confusion. The lines seeing the unexpected latency dont appear to be showing interleaving as having been applied when the ISP runs a line test and unfortunately we cannot see any decent line stats from those particular modems/routers to see exactly what has been applied to know whats going on for those modems. This is where because of lack of decent stats we are going to have to leave it in the hands of those BT/Latniq bods that can access stats. Out of interest is there anyone with a hacked ECI modem on a Huawei cab can see any of the usual parameters such as INP etc?
We know with INP we only had figures like INP=3 and by using other parameters such as interleaving depth, then the modem calculated how much Interleave and FEC to apply. Whereas now we are seeing things like G.INP = 46. What if its trying to put that say 46 parameter as Interleave & FEC (INP) protection. 46 INP is going to have a ludicrously high ms of noise protection. Latency is going to rocket and Forward Error Correction overheads will reduce sync speeds dramatically.