Any appliance with an electric motor, power switch or power adapter is capable of generating impulse noise. Telephone wiring in subscribers’ homes picks up the noise from such appliances which, in turn, impairs DSL transmission. The severity depends on how close the source of the impairment is to the telephone wiring and the quality of the wiring itself. Service providers tell us, however, that many of their subscribers’ homes have lower quality wiring, so are susceptible to impairment.Source: Alcatel-Lucent (http://www2.alcatel-lucent.com/techzine/g-inp-secret-stable-100-mbps-copper/)
Impulse noise comes in two main flavors – intermittent and repetitive. Noise that occurs as sporadic, unpredictable events is called SHINE (http://www.kitz.co.uk/adsl/rein.htm#REIN) (single high impulse noise event). SHINE (http://www.kitz.co.uk/adsl/rein.htm#REIN) often originates from turning an appliance on or off. Impulse noise that is consistent is known as REIN (http://www.kitz.co.uk/adsl/rein.htm#REIN) (repetitive electrical impulse noise). Household dimmers and faulty power adaptors are a common source of REIN (http://www.kitz.co.uk/adsl/rein.htm#REIN).
Impulse noise protection (INP) (http://www.kitz.co.uk/adsl/interleaving.htm#INP)is generally comprised of techniques used by DSL transceivers to protect against the effects of impulse noise on the transmitted signal. The former best practice for handling impulse noise was to use forward error correction (FEC) based on Reed Solomon codes, together with interleaving (i.e., I-FEC) to detect and then correct errors within a block of data.
I-FEC works well with REIN (http://www.kitz.co.uk/adsl/rein.htm#REIN), but is less efficient with SHINE (http://www.kitz.co.uk/adsl/rein.htm#SHINE), because it requires a fixed overhead of between 6% and 12% of bandwidth under normal circumstances, and up to 20% when attempting speeds of 100 Mbps. In effect, this means service providers actually need to squeeze 120 Mbps out of their VDSL2 lines to deliver 100 Mbps service to consumers due to the 20% overhead.
The G.inp standard (G.998.4) was approved by the International Telecommunication Union (ITU) in 2010. It is intended to provide enhanced protection against impulse noise or increase the efficiency of providing INP (http://www.kitz.co.uk/adsl/interleaving.htm#INP).
The G.inp standard specifies the use of physical layer retransmission to enhance INP (http://www.kitz.co.uk/adsl/interleaving.htm#INP). The approach is similar to the retransmission method used in TCP/IP. Instead of IP packets, however, data transfer units (DTU) are sent between transmitter and receiver. When packets get corrupted during transmission, the transmitting peer is informed and the DTU is resent.
There are several benefits to the G.inp approach. Compared to I-FEC, the method only consumes transmission capacity when retransmission is required, traditionally consuming less than 1% (more on that later). And unlike TCP/IP, all the traffic is protected, including TCP, IP, UDP, SMTP, HTTP and more.
In addition, the round-trip time — i.e., the (minimum) time required for retransmission — is very short in case of G.inp because the DTU error detection and retransmission occurs at the physical layer.. TCP/IP retransmission often takes up to 50 milliseconds, while G.inp only takes a couple of milliseconds (4 milliseconds is typical). The result is also that G.inp achieves enhanced INP with good efficiency at shorter delays compared to I-FEC.
Reducing latency is important even when retransmission is not required. Due to the end-to-end communication between the server and the client, having faster responses reduces the amount of time required to complete an end-user request, such as to start streaming a video or download a webpage. Beyond the speed of the connection, reduced latency improves response times and makes for a better end-user experience.
By providing extra protection and reducing latency on the weakest link – DSL – G.inp improves the entire communication chain.
We have not yet started the rollout for the ECI infrastructureMore information can be found at ISPreview (http://www.ispreview.co.uk/index.php/2015/04/bt-openreach-briefs-uk-fttc-fibre-broadband-isps-on-g-inp-issues.html)
ECI equipment (either modems or DSLAMS) doesn’t currently support upstream retransmission.
BT have confirmed that all trial lines have been loaded with the new profiles,further to this BT have confirmed that all other affected lines have now had the new profiles loaded.That is all lines across all providers.
Software version V100R001C01B030SP08
Firmware version A2pv6C038m.d24j
Are you sure you're getting a Huawei cabinet?
Would I be correct to assume new Huawei cabinets will be installed with this already enabled?Yes
When the engineer comes I guess I should be making a fuss if he provides me with a ECI modem!Yes. But you may not get anywhere. Unfortunately for a good while some area's have only been supplying ECI modems. I know going back to when mine was installed that the contractor only had ECI modems on their vans. Its been like that for a while and one of the OR guys has confirmed that their supplies dept only has ECI's in stock - this is the NW so not sure if it will be different down south, but just making you aware that he genuinely may not have a HG612 available.
The only solution we can offer is:
1). Wait and see if BT give an official statement and announce if they are able to release yet another f/w update for the ECI modems.
2). Purchase a compatible modem/router.
Modem Routers showing increased latency and lower sync
The first three on the list all contain a similar Lantiq VRX-268 modem chipsets and all seem to be in a similar situation.
BT Openreach ECI modem
BT Homehub 5 Type A (Software version 4.7.5.1.83.8.204)
TP Link TD W-9980
*Unconfirmed if all models
I was referring to "system" and "board" but maybe not.
I believe there are 2 types of G.VectorI havent read the specs or links, but if you are referring to the type of vectoring that is performed at the dslam then yes.
yeah I fell near the end of the ECI window :( cabinet went live in dec 2013.
QuoteI believe someone suggested that US rate of 20000 was synonoomommous with g.inp?
Ive always sync'd at 20,000 upstream. Ive never paid much attention to the 79999, 79998 or 79987 etc as I thought it was perhaps just a quirk of the modem/dslam.
These are some of mine
79999 20000 HG612
79987 20000 Zyxel
80000 20000 TP-Link
I havent read the specs or links, but if you are referring to the type of vectoring that is performed at the dslam then yes.
The ECI M41's can only do so at line card level.
The Huaweis at system/shelf level, but I believe they need to install another module into the cabs.
The later is far more efficient.
Seems like BT bought a bit of a dud with the ECI's. I keep hoping that ECI can find some way of slotting in a module rather than having to replace with a V41.
/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
>> The bottleneck on the ECIs is the backplane, hence the need for a new chassis.
I wonder if this would help things for eci/r ?
I havent read the specs or links, but if you are referring to the type of vectoring that is performed at the dslam then yes.
The ECI M41's can only do so at line card level.
The Huaweis at system/shelf level, but I believe they need to install another module into the cabs.
The later is far more efficient.
Seems like BT bought a bit of a dud with the ECI's. I keep hoping that ECI can find some way of slotting in a module rather than having to replace with a V41.
The Huawei kit needs installation of a Vectoring Processing Engine - basically a card that crunches telemetry supplied by the line cards then sends back the required noise cancellation parameters.
The bottleneck on the ECIs is the backplane, hence the need for a new chassis. The alternative would be to replace all the line cards with cards with their own optical interfaces then connect all the line cards together either directly or via an intermediate card.
The Huawei devices also offer node level vectoring where 2 VPEs are connected via a 40Gb cross-connect with telemetry between cabinets being exchanged on that path.
That 40Gb is required should also give some idea of the backplane capacity needed to do system level vectoring, too.
/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
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).
QuoteI believe someone suggested that US rate of 20000 was synonoomommous with g.inp?
Ive always sync'd at 20,000 upstream. Ive never paid much attention to the 79999, 79998 or 79987 etc as I thought it was perhaps just a quirk of the modem/dslam.
These are some of mine
79999 20000 HG612
79987 20000 Zyxel
80000 20000 TP-Link
I thought exactly the same. I bet it was w3 that pointed it out too :)
Its an interesting notion that the ECI modems will have gone through one firmware upgrade to go from <totally incompatible> to <quite incompatible>, but it certainly seems to be true that a lot are waiting for something more. I had originally thought that it was a problem with the agent failing to update some modems, but this idea probably fits the evidence better.
Have we seen anyone with an ECI modem that appears to have had G.INP activated with no ill effects? Any hint, anywhere? With ECI's being considerably harder to unlock
I imagine we will have a hard time confirming it ... other than the kind of efforts going on via TP-Link.
I have a HH5 and saw that i could no longer get max sync... found this thread :fingers: they roll out an update soon. I am running an unlocked Huawei at the moment with the latest SP08 which is back to full sync :)
Just seen a post on the Plusnet forums about the TP-Link W9980: http://community.plus.net/forum/index.php/topic,138451.0.html
Summary: the poster has been working with TP-Link's tech support and testing new firmware. He now has a version that works with G.INP with no loss of latency.
So just to be clear, are ALL Huawei DSLAMs getting the upgrade or not, I am a bit confused. I am on Huawei, and definitely do not have it at the moment.
I am currently on a Zyxel 8924 with V8 Beta 2 firmware.So just to be clear, are ALL Huawei DSLAMs getting the upgrade or not, I am a bit confused. I am on Huawei, and definitely do not have it at the moment.
It seems there are 2 Huawei DSLAM firmware & chipset versions in use now.
However, both versions do seem able to deliver G.INP.
Which are you connected to?
Telnet command xdslcmd info --vendor or adsl info --vendor should confirm.
Not having G.INP COULD be due to the firmware and/or software versions of the modem you are currently using.
I know you have tried a few different modems quite recently.
Which are you currently using & what are its firmware & software versions?
From your stats, it now looks like there are 3 Huawei DSLAM versions in use:-
Mine:-
ChipSet Vendor Id: BDCM:0xa44f
ChipSet VersionNumber: 0xa44f
Yours:-
ChipSet Vendor Id: BDCM:0xa451
ChipSet VersionNumber: 0xa451
One I saw yesterday:-
ChipSet Vendor Id: BDCM:0xa458
ChipSet VersionNumber: 0xa458
Only yours isn't using G.INP.
Is anyone else using a ZyXel 8924 with the same V8 Beta 2 firmware as Tyke that is actually using G.INP?
From your stats, it now looks like there are 3 Huawei DSLAM versions in use:-
One I saw yesterday:-
ChipSet Vendor Id: BDCM:0xa458
ChipSet VersionNumber: 0xa458
One I saw yesterday:-
ChipSet Vendor Id: BDCM:0xa458
ChipSet VersionNumber: 0xa458
Don't know if that's a typo or there's a 4th, as I have
ChipSet Vendor Id: BDCM:0xa485
ChipSet VersionNumber: 0xa485
are ALL Huawei DSLAMs getting the upgrade or not, I am a bit confused. I am on Huawei, and definitely do not have it at the moment.
Is anyone else using a ZyXel 8924 with the same V8 Beta 2 firmware as Tyke that is actually using G.INP?
I don't know how the guys with unlocked ECI's are doing, because at least they can access some stats so it would be good if any of them can report their findings please.
Is the cabinet a Huawei or an ECI? If it's Huawei it will have G.INP enabled. ECI - not known.
Think most of the unlocked eci users are on eci cabs although Kronos_2001 maybe on a Huawei.
It'sa full-sizethe large Huawei 288 cabinet
-------
Edited by admin to avoid confusion with full size Huawei MSANs
or by using the telnet command
xdslcmd info --vendor
Welcome Visiting Huawei Home Gateway
Copyright by Huawei Technologies Co., Ltd.
Login:admin
Password:
ATP>xdslcmd info --vendor
^
ATP>
or by using the telnet command
xdslcmd info --vendor
I think I'm missing something when telnetted in:Welcome Visiting Huawei Home Gateway
Copyright by Huawei Technologies Co., Ltd.
Login:admin
Password:
ATP>xdslcmd info --vendor
^
ATP>
# xdslcmd info --vendor
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 42685 Kbps, Downstream rate = 125020 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 Kbps
ChipSet Vendor Id: BDCM:0xa485
ChipSet VersionNumber: 0xa485
ChipSet SerialNumber:
What are we in and what can we do when we are at the ATP prompt?
Thanks:# xdslcmd info --vendor
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 42685 Kbps, Downstream rate = 125020 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79987 Kbps
ChipSet Vendor Id: BDCM:0xa485
ChipSet VersionNumber: 0xa485
ChipSet SerialNumber:
What are we in and what can we do when we are at the ATP prompt?
Where is your Bearer 1 Jelv don't you have G.INP activated on your line ?
Do I need to send out the search party?
Not having much of a clue with FTTC two possibilities come to mind:
1. This is a brand new cab - I went live on Tuesday and I was the first user - might it not be enabled on the cab?
2. My line is so good it doesn't need error correction?
> adsl profile --show
Modulations:
G.Dmt Enabled
G.lite Enabled
T1.413 Enabled
ADSL2 Enabled
AnnexL Enabled
ADSL2+ Enabled
AnnexM Disabled
VDSL2 Enabled
VDSL2 profiles:
8a Enabled
8b Enabled
8c Enabled
8d Enabled
12a Enabled
12b Enabled
17a Enabled
30a Enabled
US0 Enabled
Phone line pair:
Inner pair
Capability:
bitswap On
sra On
trellis On
sesdrop Off
CoMinMgn Off
24k On
phyReXmt(Us/Ds) Off/On
TpsTc AvPvAaPa
monitorTone: On
dynamicD: On
dynamicF: Off
SOS: On
Training Margin(Q4 in dB): -1(DEFAULT)
>
after having a look at those setting the users seems to have turned off phyr on the US is there a reason for that as it deffo helps with my upstream errors.
Assuming your DSLAM has been updated, there's every possibility that your connection will be switched to G.INP today (if it hasn't already done so).
Looking at this data, your DSLAM appears to be one of the newer ones:-
ChipSet Vendor Id: BDCM:0xa485
ChipSet VersionNumber: 0xa485
These DSLAM versions are being updated, but from other users' reports, it seems they may have updated more recently than the original 0xa44f versions.
As mentioned earlier, we still don't know for sure that ALL connections are having G.INP applied or if it is only those that 'need' it.
Your connection appears to have lots of spare capacity, so it will be interesting to be informed whether G.INP does get applied at some stage.
> adsl profile --show
Modulations:
G.Dmt Disabled
G.lite Disabled
T1.413 Disabled
ADSL2 Disabled
AnnexL Disabled
ADSL2+ Disabled
AnnexM Disabled
VDSL2 Enabled
VDSL2 profiles:
8a Enabled
8b Enabled
8c Enabled
8d Enabled
12a Enabled
12b Enabled
17a Enabled
US0 Enabled
Phone line pair:
Inner pair
Capability:
bitswap On
sra On
trellis On
sesdrop Off
CoMinMgn Off
24k On
phyReXmt(Us/Ds) On/On
TpsTc AvPvAa
monitorTone: On
dynamicD: On
dynamicF: Off
SOS: On
Training Margin(Q4 in dB): -1(DEFAULT)
>
Could it be that the rollout has been suspended until the present G.INP problems are resolved?
to me that would be an unethical stance for a large business like OprenReach the ECI modems can still access the internet after the fix (no DSL communication on a Huawei cabinet) there has to more to it than a just modem incompatabiliy with g.inp.
<Caveat> Unless something's happening at a higher level that I don't have access to ?.
Do you have the ability to look to see if a specific cabinet has been enabled (STMERE-3)?
Bear in mind through all of this I'm on an ECI modem that is locked so the only way I can see my sync rate is from Zen's portal "line data"
I work from home, permanently, and internet is critical for me as I manage a virtual infrastructure remotely.
BT Openreach has temporarily suspended g.inp enabled for now until further notice.
BT Openreach has temporarily suspended g.inp enabled for now until further notice.
We're on Huawei cab, ECI modem.
Looking at the last active time on his profile he's been on here since both of our posts - but no response.
I need to look at mobiles and consider 3G/4G backup but I don't use my mobile phone too much and therefore hate contracts. I'm just on £7.50 PAYG with giffgaff at the moment and don't even use all of that. Apart from maybe if I'm travelling for work then the data will get used.
Did I see that you said you'd placed a tentative bid on a Huawei HG612? Let us know how it goes :) Alternatively wombats suggestion of the Billion would be a possible good alternative.
The fix is to simply give a hg modem to all eci modem holders.
Or to get a fixed firmware rolled out.
suspending it does nothing for those already affected and holds back a very good technology for those on ECI cabinets.
if there has really been a suspension in the rollout, will they rollback those cabinets that have already seen the update?
I would imagine they would need a 6 month duration to get exec approval, followed by 6 months of testing to roll it back
I would imagine they would need a 6 month duration to get exec approval, followed by 6 months of testing to roll it back :p
I also received another email at 09:23 to confirm that a different user had G.INP disabled.
disabled as in fast path or disabled as in change to normal interleaving?
BE is it possible to add to MDWS that us normal users can get these notifications?
It would be of great interest to know the sequence of events before G.INP was disabled.
I lost G.INP as a consequence of a DLM Reset being performed on my line.
(G.INP was there before and gone after the reset)
It would be of great interest to know the sequence of events before G.INP was disabled.
I lost G.INP as a consequence of a DLM Reset being performed on my line.
(G.INP was there before and gone after the reset)
Unfortunately I don't have that information.
I simply get notified when users have G.INP enabled or disabled.
The point I was making was that perhaps the G.INP rollout hasn't actually been completely suspended.
The new one this morning to me looks like another newly subscribed member to MDWS (no previous stats) .. and if its the same one that Im thinking - Rolocollie - then it looks like he's on a Huawei cab.
One other thing that I have only just spotted is that the user with G.INP enabled today appears to be connected to an ECI DSLAM.
It doesn't matter though as AndyH seems to know all about it anyway:-
https://community.plus.net/forum/index.php/topic,138671.msg1223141.html#msg1223141
take a deep breath and double check your findings an ECI cabinet should turn green on MDWS.
It now shows as Huawei.
Perhaps tbailey2 also spotted it & corrected it?
It now shows as Huawei.
Perhaps tbailey2 also spotted it & corrected it?
You meen he corrected a flaw on his side ;)
Did I see that you said you'd placed a tentative bid on a Huawei HG612? Let us know how it goes :)
We have just received the below back from BT on thishttps://aastatus.net/posts.cgi?itype=Broadband&oseverity=2 (https://aastatus.net/posts.cgi?itype=Broadband&oseverity=2)
Following communications from a small number of BTWholesale FTTC comms providers regarding Openreach’s implementation of Retransmission and the identification of some your customers who have seen increased latency on some lines for some applications since retransmission was applied. Over the last 4 weeks I have been pushing Openreach to investigate,
feedback and provide answers and options related to this issue. As a result attached is a copy of a briefing from Openreach; sent to their CPs today, on how RetX works and what may have caused this increase latency.
This info is being briefed to all BTWholesale customers via our briefing on Saturday morning 25/4/15 but as you have contacted me direct I’m sending this direct as well as providing ann opportunity to participate in a trial.
Openreach have also advise me this afternoon that they intend to run a trial next week (w/c 25/4/15) on a small set of lines; where devices aren’t retransmission compatible in the upstream to see if changing certain parameters removes the latency and maintains the other benefits of retransmission. The exact date lines will be trialled has yet to be confirmed.
However, they have asked if I have any end users who would like to be included in this trail. To that end if you have particular lines you’d like to participate in this trial please can you provide the DN for the service by 17:00 on Monday 28th April so I can get them included.
This is a trial of a solution and should improve latency performance but there is a risk that there may be changes to the headline rate.
Did I see that you said you'd placed a tentative bid on a Huawei HG612? Let us know how it goes :)
Well, I managed to snag something from eBay but it's a slight gamble. As I said, all the ones specifically labelled as HG612 in the auction seem to be either £40+ already or being quite hotly contested. So I got one that doesn't say what it is. I can see from the port layout that it is either a Huawei, or an early revision ECI. For £12 I'm prepared to take a gamble. I'll either have some revision of Huawei or I'll have a backup to my rev./r ECI should that ever go pop.
I have considered a different router but probably completely the opposite to everyone else, I prefer a separate modem. I can then do what I like in terms of moving and re-routing all via RJ45 without going anywhere near telephone lines. My modem is directly at the point of entry to the house of the main cable so telephone cable is as short as it can possibly be.
Based on that, provided the picture is not a stock one (it doesn't look like it) then it's a Huawei due to the square LED openings :thumbs:
We shall see when it arrives.
* We have not yet started the rollout for the ECI infrastructure as we are investigating a minor issue with our hand held testers.
Quote* We have not yet started the rollout for the ECI infrastructure as we are investigating a minor issue with our hand held testers.
I think that Kitz, our leader, will smile at the above. We touched on the subject in an exchange of PMs, a day or so ago. ;)
Edit: Having re-read the article, b*cat proceeded to look at the comments . . . and felt a peculiar tingle in his whiskers when he saw who had written the very first one. :)
Mr Cat .... I wonder how those PM's may have begun ;) :) :)
I resorted to asking b*cat if he could recall which model of EXFO that the OR engineers used.
maybe the JDSU needs a firmware update ;D
"Exfo AXS-200/635"
ISPReview have posted some news: http://www.ispreview.co.uk/index.php/2015/04/bt-openreach-briefs-uk-fttc-fibre-broadband-isps-on-g-inp-issues.html
Shame they stated that the firmware update fixes the issue on ECI modems!
....that did not appear to include proper support for G.INP, which also impacted a few of Openreach’s ECI modems.
ECI equipment (either modems or DSLAMS) doesn’t currently support upstream retransmission.From what we have seen with the HH5A & ECIs & TD-W9980 it wasnt supporting upstream or downstream.
increasing upstream latency by approx. 8ms.
We have not yet started the rollout for the ECI infrastructure as we are investigating a minor issue with our hand held testers.
Ive yet got to read the info ISPr.. so no doubt will have something to say about that in a moment. :D
Thanks jelv, but have they edited that because I cant see it.
Those would suggest a total of between 16 and 24ms, worst case, but I thought we've had numbers higher than 30ms reported.
The report suggests that ECI modems can support G.INP downstream, but not upstream. This ought to imply that most cases of extra latency should only be 8ms, coming from fallback of just the upstream.
- The fallback mechanism, combined with the fact that DLM now seems very trigger-happy to apply one of the retransmission profiles to all and sundry, would explain the issues we've seen, providing we can get the numbers to match
There is no mention of what equipment is incompatible, apart from that mention of ECI upstream. With the work we've seen from Lantiq and TP-Link, I'm surprised we don't see more indications - but perhaps that will come from a BTW briefing
- The report suggests that ECI modems can support G.INP downstream, but not upstream. This ought to imply that most cases of extra latency should only be 8ms, coming from fallback of just the upstream.
- The report suggests that ECI modems can support G.INP downstream, but not upstream. This ought to imply that most cases of extra latency should only be 8ms, coming from fallback of just the upstream.
I did notice the Billion 8800NL has phyr turned off on the US by default could that also be related to the above :-\
Openreach have also advise me this afternoon that they intend to run a trial next week (w/c 25/4/15) on a small set of lines; where devices aren’t retransmission compatible in the upstream to see if changing certain parameters removes the latency and maintains the other benefits of retransmission. The exact date lines will be trialled has yet to be confirmed.Would appear to be their next step, So maybe they are going to test a new firmware? maybe they have copied tp link's beta fw
I told you so. That's the ECI cabinet roll out with g.inp won't be happen now. Next stage for Joe Garner will email me end of this month.
QuoteOpenreach have also advise me this afternoon that they intend to run a trial next week (w/c 25/4/15) on a small set of lines; where devices aren’t retransmission compatible in the upstream to see if changing certain parameters removes the latency and maintains the other benefits of retransmission. The exact date lines will be trialled has yet to be confirmed.Would appear to be their next step, So maybe they are going to test a new firmware? maybe they have copied tp link's beta fw
- The report suggests that ECI modems can support G.INP downstream, but not upstream. This ought to imply that most cases of extra latency should only be 8ms, coming from fallback of just the upstream.
I did notice the Billion 8800NL has phyr turned off on the US by default could that also be related to the above :-\
it appears the majority of modems have it turned off on US by default, presumably because its optional and therefore not all DSLAMs will support it.
Retransmission can operate in both downstream and upstream channels simultaneously, although ECI equipment (either modems or DSLAMS) doesn’t currently support upstream retransmission.
* Any infrastructure that doesn’t support retransmission in the upstream will default to interleaving, increasing upstream latency by approx. 8ms.
http://www.ebay.co.uk/itm/BT-Openreach-Fibre-Modem-/301600572359 (http://www.ebay.co.uk/itm/BT-Openreach-Fibre-Modem-/301600572359)
I might mail the seller and point out they haven't sent me the item in the auction
Hi All.
If there are any customers who are affected by this and are still using a ECI modem there is a trial we're looking to do with Openreach and Wholesale.
Basically we're looking at cases where devices aren’t retransmission compatible in the upstream to see if changing certain parameters removes the latency and maintains the other benefits of retransmission.
If anyone is interested drop me a message with your username and I'll get back to you.
http://www.ebay.co.uk/itm/BT-Openreach-Fibre-Modem-/301600572359 (http://www.ebay.co.uk/itm/BT-Openreach-Fibre-Modem-/301600572359)
Interesting!
http://community.plus.net/forum/index.php/topic,136287.msg1224011.html#msg1224011
*sigh* You got to love people on eBay that don't use a picture of the actual item they're selling! 1 ECI rev.R modem arrived. Will be shoved in the bottom of the drawer as a spare. I might mail the seller and point out they haven't sent me the item in the auction but other than that it's not worth the grief or the cost of sending it back.
[EDIT] Bah, not in the mood for messing about - just did a BIN for one that specifically says it's an unlocked Huawei - not that I'm desperately interested in the unlock, it's the compatibility I'm after.
ChipSet Vendor Id: IFTN:0xb204
I wonder if this confirms that G.INP is now being tested on ECI cabinet's.
*waits for my modem to disconnect and reconnect.. I'm not sure if I should be wishing for G.INP or not lol
Hello Mike, welcome to the Kitz forum.Quote from: MikeZChipSet Vendor Id: IFTN:0xb204
The Infineon chipset definitely confirms an ECI equipped cabinet.
I'm not too sure if you mean that you experienced an approximate four hour outage of service or that there was a somewhat shorter outage, somewhere within the 0200 - 0600 hours time-frame? ???
Certainly the facts, as you have described, do seem to fit the application of G.INP on your circuit.
The questions have to be asked -- Which exchange? And which cabinet number, please?
The stats on MDWS suggest it's regular interleaving that's been applied, not G.INP. :(
"Any lines which are connected using an non-compatible g.inp modem/router appear to default to a DLM profile that applies fairly heavy interleaving and error correction overheads."
I'm hoping that now I've got a modem that supports G.INP, the DLM will return to normal.
I'm hoping that now I've got a modem that supports G.INP, the DLM will return to normal.
Right. I'm not sure about this. In the past I think connecting a Huawei modem has resolved the delay immediately, but I'm not sure if that's always the case.
That info is for a users you has an incompatible modem on a Huawei cabinet you are on a ECI cabinet and as far as we know G.INP has not been enabled on any ECI cabs.
. . . I am not aware of any ECI cabs (other than say the Martlesham etcs) being G.inp enabled.
Your line is connected through an ECI equipped cabinet, yet in the same general area Bald_Eagle1's line is connected through a Huawei equipped cabinet. Are you both connected back to the same exchange, Oldham?
Your line is connected through an ECI equipped cabinet, yet in the same general area Bald_Eagle1's line is connected through a Huawei equipped cabinet. Are you both connected back to the same exchange, Oldham?
I think Bald_Eagle1 is directly connected to Oldham's exchange(?) and I'm on the local exchange, SHAW.
Your line is connected through an ECI equipped cabinet, yet in the same general area Bald_Eagle1's line is connected through a Huawei equipped cabinet. Are you both connected back to the same exchange, Oldham?
I think Bald_Eagle1 is directly connected to Oldham's exchange
I have asked similar questions myself because its not looking good for the ECI's atm.
Ive been promised a response from their Chief Engineer @ Network Strategy but have told it will be at the earliest next week as he is out of the office atm. As soon as I know whats going on I will update.
I don't see a problem as you're on an ECI cab with an ECI modem
I have asked similar questions myself because its not looking good for the ECI's atm.
Ive been promised a response from their Chief Engineer @ Network Strategy but have told it will be at the earliest next week as he is out of the office atm. As soon as I know whats going on I will update.
I can safely say since I have had FTTC - BT Infinity (Feb 13') it has been the best Broadband I have ever had. Before I was on VM which was over utilized on my segment.
Latency and speeds have been very good so far (touch wood).
I would be gutted for OpenReach to deploy a profile that screws with my internet. If they do then I guess I am off. But that is not what I want. But if my hand is forced..
I will also contact BT direct and tell them I am out if they deploy a system that causes more problems then good (on ECI equipment).
This really annoys me! - As I am sure you can see ;)
BTW do you happen to have a contact at OR I can e-mail to mention my concerns and someone at BT wholesale?
Thanks,
Retransmission can operate in both downstream and upstream channels simultaneously, although ECI equipment (either modems or DSLAMS) doesn’t currently support upstream retransmission.
As it stands atm no-one on an ECI cab is going to be able to get 80/20 because the IFTN chipset cant cope with G.INP.
Just imagine the crap that would have hit the fan if they'd continued. I cannot believe for one minute that this has been tested properly
I have asked similar questions myself because its not looking good for the ECI's atm.
Ive been promised a response from their Chief Engineer @ Network Strategy but have told it will be at the earliest next week as he is out of the office atm. As soon as I know whats going on I will update.
Quote from: kitzJust imagine the crap that would have hit the fan if they'd continued. I cannot believe for one minute that this has been tested properly
Haven't they been "testing" for 2 years though? They need to use end users that have some technical know how - this should have been noticed in week one of testing!
Annoyed I am on an ECI cabinet, annoyed it took them half a decade to eventually enable the cab and even more annoyed that without Ginp/vectoring my FTTC speed will be no faster than ADSL2+ after starting at 80/20 with all the crosstalk issues.
I hope BTOR have some good news even if it is to send back the ECI cabs and get something that works!
For what its worth I contacted ofcom, gave them the technical details, and they told me its a detriment to the service and as such people could exit without penalty.
This is very different to things like crosstalk, because if g.inp is enabled on ECI cabs with interleaving fallback on the upstream, then thats something entirely in openreach's control.
They were probably just testing if it connected ok, and level of fault reports.
The proper way to trial is ask the tech savvy users to test and be open with what you doing.
I had to stop reading over there, because I dont have time nor inclination to argue the toss with the Im alright jack & the I know more than you do brigade. Someone mentioned to me tonight that theyve had to stop posting there because of attitude, and just a couple of days ago someone else remarked on the change of the forums.
A better option would be to give isp's control over DLM and allow it to be disabled if requested by the EU, My connection until G.inp ran fine when on Fastpath even though at times there was bursts of errors for short periods of time, but i didn't consider it to be service affecting, where as i did feel DLM applying interleave was , only for it to return to fast path 2 weeks later 3-4 times in 23mths dlm intervened needlessly IMO
I had to stop reading over there, because I dont have time nor inclination to argue the toss with the Im alright jack & the I know more than you do brigade. Someone mentioned to me tonight that theyve had to stop posting there because of attitude, and just a couple of days ago someone else remarked on the change of the forums.
If a certain shill over there keeps posting rubbish I'll keep challenging him. There's already been a warning from a moderator on the topic about it verging on to personal attacks (challenging all who post rubbish is OK - but if all is only one person does that make it personal?).
The isp could basically verbally convey a verbal disclaimer to the EU , in that doing this may at some point cause a negative impact to your connection blah blah, blah, as for the EU reporting a fault then, before BT openreach involvement the isp would run tests, including with DLM on or a manual config with interleaving /g.inp applied , if a line was needing very high levels of interleaving INP ect and was still showing issues then raise a fault with bt . like llu suppliers used to. I can see no difficulty with that solution, apart from isp's having to employ trained people to provide tech support, DLM was designed to save isp's doing this, but it is far from perfect,A better option would be to give isp's control over DLM and allow it to be disabled if requested by the EU, My connection until G.inp ran fine when on Fastpath even though at times there was bursts of errors for short periods of time, but i didn't consider it to be service affecting, where as i did feel DLM applying interleave was , only for it to return to fast path 2 weeks later 3-4 times in 23mths dlm intervened needlessly IMO
There is a difficulty with that: an EU insists they want DLM disabled even though it would be beneficial because their line is prone to errors. They then raise a fault needing an engineer's visit. What happens next?
Took the words right out of my mouth.I very nearly wrote something on those lines yesterday, as that's the opinion that have formed too, we all could ignore him not respond to his remarks starve the troll/shillI had to stop reading over there, because I dont have time nor inclination to argue the toss with the Im alright jack & the I know more than you do brigade. Someone mentioned to me tonight that theyve had to stop posting there because of attitude, and just a couple of days ago someone else remarked on the change of the forums.
If a certain shill over there keeps posting rubbish I'll keep challenging him. There's already been a warning from a moderator on the topic about it verging on to personal attacks (challenging all who post rubbish is OK - but if all is only one person does that make it personal?).
I am guessing if that thread gets closed, andy will have achieved his aim.
kitz am I ok to post that pic elsewhere?
Shame the Huawei modem used a different server - Bristol not London. Apart from that, good graphic :)
We shall have to see what they come up with. The only excuse that I can think is that we know this was tested before they made changes to the DLM late last year. The current DLM system seems to be particularly harsh with the application of interleaving and this will be what causing most of the issues with latency and lack of speed. Anyhow I await a further reply before I jump the gun and lets hope they can do something to sort it, otherwise there will be a lot of unhappy hectors :(
Stats recorded 30 Apr 2015 12:43:18
DSLAM/MSAN type: BDCM:0xa451 / v0xa451
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 1 hours 1 min 59 sec
Resyncs: 0 (since 30 Apr 2015 12:33:45)
Downstream Upstream
Line attenuation (dB): 13.9 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 72558 19999
SNR margin (dB): 7.8 12.1
Power (dBm): 13.0 5.0
Interleave depth: 1141 673
INP: 3.00 4.00
G.INP: Not enabled
RSCorr/RS (%): 0.0001 0.0966
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
MartinW,
Your experience ties in with mine.
BT OR 'played' with my line to fix a fault and G.INP has disappeared and line sync has dropped speed permanently.
I am on a Huawei DSLAM using a Zyxel 8324 modem.
Was getting actual sync 77xxx now 68xxx not happy, because the drop is not for the ususal reasons, it happened within minutes by the line being 'Fixed'.
Plusnet refuse to acknowledge there is a fault becuase the only line fault they recognise is a drop in speed outside 'your estimate range'.
Plusnet cannot recognise the fault is actually BT OR messing up my line as it as syncing at 72xxx with the fault and was dropped to 70000 when fixed.
This was when using a HG612 modem.
It has dropped further to 68xxx which I cannot improve on with the Zyxel, which is at odds with past expereince where I got 5M higher line sync.
I am sticking with the Zyxel as it matches my Gigabit network and is more usable than the HG612.
My estimate range has been dropped as a consequence of 2 speed drops that were faults that BT OR 'Fixed' but didn't.
G.INP has been gone for weeks, might be more than a month, my memory has blured due to the on going saga with Plusnet. (Do not ask!) >:( ;D
Well, this is odd and possibly a little depressing!
HG612 arrived today so I've reflashed it to the latest I could find (SP08 software and 38m.d24j f/w) and there is no immediate difference. I figured it may take 24h or more to see a difference but in the meantime I wanted to confirm if G.INP is really the route cause of my speed drop and ping increase. Bear in mind around half of the 20mbit d/l drop was due to a dodgy module in the box up the pole and that is now resolved.
It looks like G.INP is not enabled and Interleave is currently way up at 1141 so I can't really explain my 8Mbit d/l speed drop (I was originally on 80001)
Does G.INP immediately show up if it is enabled? I assume so.
Here is my info from DSLStats...Code: [Select]Stats recorded 30 Apr 2015 12:43:18
DSLAM/MSAN type: BDCM:0xa451 / v0xa451
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 1 hours 1 min 59 sec
Resyncs: 0 (since 30 Apr 2015 12:33:45)
Downstream Upstream
Line attenuation (dB): 13.9 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 72558 19999
SNR margin (dB): 7.8 12.1
Power (dBm): 13.0 5.0
Interleave depth: 1141 673
INP: 3.00 4.00
G.INP: Not enabled
RSCorr/RS (%): 0.0001 0.0966
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
INP: 3.00 4.00would be much higher. Thats the standard (old) DLM settings.
Does G.INP immediately show up if it is enabled? I assume so.
My one concern about the image is not the different server (which wouldn't make that much difference) but the widely different dates and times which could mean contention was a factor. It does mean the ECI potentially was even worse!
There are however three things which puzzle me still.
1) Why is my download speed still consistantly 12M down on my IPProfile after 4 days?
2) I normally do speedtests with btwholesale and speedtest.net with the later showing US 1-2M greater than BT. When I got G.INP'ed (I'm assuming) my US reported by BT dropped to ~10Mbps while SpeedTest stayed at ~17Mbps. When G.INP was enabled on the HG612, both speedtests reported ~15Mbps.
There are however three things which puzzle me still.
1) Why is my download speed still consistantly 12M down on my IPProfile after 4 days?
2) I normally do speedtests with btwholesale and speedtest.net with the later showing US 1-2M greater than BT. When I got G.INP'ed (I'm assuming) my US reported by BT dropped to ~10Mbps while SpeedTest stayed at ~17Mbps. When G.INP was enabled on the HG612, both speedtests reported ~15Mbps.
Hi and welcome to the forums :)
What is your Plusnet profile?
https://portal.plus.net/my.html?action=stable_rate
We've seen a couple of cases whereby its the PN profile which has stopped the speed increases being immediate.
tried a DLM reset which didn't change the IPProfile or download speed.
Quotetried a DLM reset which didn't change the IPProfile or download speed.
This is rather familiar to lines which have been g.inped but have an incompatible router, and its mentioned in the main post that for some reason the OR guys appear have a job to get it to unstick and the only way is getting a compatible router.
Im a bit at a loss to try figure out why the line is now syncing at 67Mbps, and both the IPprofile and BT profile at 65Mbps why youre not yet getting full throughput.
Perhaps one of the other guys can spot something obvious that Ive missed?
Quotetried a DLM reset which didn't change the IPProfile or download speed.
This is rather familiar to lines which have been g.inped but have an incompatible router, and its mentioned in the main post that for some reason the OR guys appear have a job to get it to unstick and the only way is getting a compatible router.
Im a bit at a loss to try figure out why the line is now syncing at 67Mbps, and both the IPprofile and BT profile at 65Mbps why youre not yet getting full throughput.
Perhaps one of the other guys can spot something obvious that Ive missed?
<snipped to keep page length shorter>
My estimate range has been dropped as a consequence of 2 speed drops that were faults that BT OR 'Fixed' but didn't.
G.INP has been gone for weeks, might be more than a month, my memory has blured due to the on going saga with Plusnet. (Do not ask!) >:( ;D
The only way I will find out is if and when vectoring gets enabled.
The only way I will find out is if and when vectoring gets enabled.
Chry if G.INP has caused this much hassle to a lot of users god only knows when vectoring is enabled on their line and the modem is incompatible that's going to be another forum headline.
The only way I will find out is if and when vectoring gets enabled.
Chry if G.INP has caused this much hassle to a lot of users god only knows when vectoring is enabled on their line and the modem is incompatible that's going to be another forum headline.
at least with g.inp we're able to identify the issue. I've not seen any reference to vectoring anywhere so I'm not sure how we'd know it was enabled or even if it's supported by the modem or not.
we know the hg612 supports g.inp, what about vectoring for that modem?
we know the hg612 supports g.inp, what about vectoring for that modem?
You nailed it kitz! I've been following this thread for about 2 weeks and seem to have forgotten the finer details :) Using my original Technicolor TG582n instead of the Asus rt-ac68u I'm now getting 61Mb. I'll see if I can downgrade to one of the old firmware versions for Asus.
Thank you so much kitz.
we know the hg612 supports g.inp, what about vectoring for that modem?
But if you are connected to an ECI cab like me then there is no point buying another modem as the cabinet is a limitation anyway in regards to G.INP?
we know the hg612 supports g.inp, what about vectoring for that modem?
But if you are connected to an ECI cab like me then there is no point buying another modem as the cabinet is a limitation anyway in regards to G.INP?
Blue166 your lookin for an answer regarding what will happen if g.inp is enabled and what if it's not enabled, I think you want it but are peed off because you can have it at the moment is that correct ?
I would be peed of to if i was in your shoes ! you would like G.INP enabled on your line but for some reason it's not within your reach, look at the moment on your ECI cabinet your better of without it until oprenreach finds away for both ECI cab and ECI modem to work in both directions using G.INP but it's not there yet.
You can keep on posting what will happen and what if ? the answer is we just don't know, I sound like the late Sir Patrick Moore but a least he was honest when faced with a difficult question.
Not quite back to the 80/20 that it was before G.INP was applied but we're not far off.
Could this be because those lines are generally swapping to Huawei modems? I couldn't get upstream beyond 17.5Mbps until I disabled QoS on the HG612.
Sadly I was too late to apply for the trial at AAISP. I was originally supplied an ECI modem but am on a Huawei cabinet.
AAISP are now supplying the Zyxel VMG1312 which supports G.INP. I wonder if they would swap your Technicolor for one? It's a VDSL router so you could replace the ECI modem.
Whats the point if your modem is G.INP enable and the line had G.INP removed by the DSLAM you can't use your new G.INP equipment until OR start the rollout again in 12 months time.
Whats the point if your modem is G.INP enable and the line had G.INP removed by the DSLAM you can't use your new G.INP equipment until OR start the rollout again in 12 months time.
PS you forgot another G.INP will be removed when you change your ISP.
Stats recorded 12 May 2015 07:49:24
DSLAM/MSAN type: BDCM:0xa44f / v0xa44f
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 11 hours 10 min 1 sec
Resyncs: 0 (since 12 May 2015 07:49:18)
Downstream Upstream
Line attenuation (dB): 11.1 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 79999 20000
SNR margin (dB): 7.9 13.3
Power (dBm): 13.4 -2.0
Interleave depth: 16 8
INP: 46.00 47.00
G.INP: Enabled
RSCorr/RS (%): 0.0000 0.0016
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
I don't need G.INP, I was perfectly happy with the line before it was turned on, and I have too
newt you swapped modems again?
I am always on the belief one should go for as high uptime as possible, so I think you doing yourself no favours with the swapping in and out, I suggest to leave it alone now.
I just won a HG612 at a fair price so will see if that resolves the issue.
My HG612 is a model 3B.
We had a loss of sync at around 02:20 on 15 May. Cabinet is ECI, router is Sky SR102. Latency is higher by a couple of ms (20% in absolute terms).
That's four loss of sync this year - one was Sky flashing the router, the rest have been BT turning g.INP on/off/god knows now in the early hours. Prior to that the line was up for just over 6 months.
Can you imagine what's going to happen if BT ever try to turn on vectoring?
We had a loss of sync at around 02:20 on 15 May. Cabinet is ECI, router is Sky SR102. Latency is higher by a couple of ms (20% in absolute terms).
That's four loss of sync this year - one was Sky flashing the router, the rest have been BT turning g.INP on/off/god knows now in the early hours. Prior to that the line was up for just over 6 months.
Can you imagine what's going to happen if BT ever try to turn on vectoring?
The repair is due to roll out for all relevant customers within the next few weeks, but unfortunately we are not able to put anyone to the head of the queueDoes anyone know what they have fixed? Is this good news for people with ECI cabinets or does it just fix problems with Ginp on Huwaii cabinets? Thanks
Openreach are very happy with the results of the trail and after some consultation they have now decided to roll this fix out across the network.
Sound like the Huawei Cab>ECI modem fix.
That news has made my day! I thought my ECI cab was obsolete!
we need to wait and see.
also bear in mind openreach been happy might not mean the same thing as end users been happy, we need to wait and see.
"although ECI equipment (either modems or DSLAMS) doesn’t currently support upstream retransmission"
Souce = ISPreview (http://link=http://www.ispreview.co.uk/index.php/2015/04/bt-openreach-briefs-uk-fttc-fibre-broadband-isps-on-g-inp-issues.html)
- The changes will be more of a DLM type configuration ie if the modem does not support G.INP then it will be moved over to the (new) non-ReTx default profile which can use both Interleaving and Error Correction if need be. The DSLAM is able to detect if the CPE is G.INP compatible or not
I guess OR needed to find a workable compromise for all FTTC modems and then start to set their sights on the ECI cabinet to get G.INP working :-\
Certainly after the cockup they made of g.inp they wont be keen on vectoring now.
How they can make such a hash of g.inp I dont know, its years old tech.
but I think what Kitz was saying is that it's not the interleaving as such which decreases the sync speed, but the error correction which is usually applied at the same time (but doesn't have to be).
I think there can be FEC without interleaving.
But interleaving without FEC seems rather pointless!
Interleaving here has lost me 6Mb of sync so yes it definitely does decrease sync speed.
Error Correction doesnt need to be interleaved, but there's no point using Interleaving without Error Correction. Why bother chopping up the data if there's no error correction in place to make use of the re-assembled data.
"Interleaving causes DELAY - ie increase in latency/ping times. Interleaving does NOT cause loss of sync speed."
For every non-G.INP VDSL2 connection that I have seen stats for since 2011, a switch from fastpath to Interleaved has ALWAYS coincided with an increase in attainable rate & definitely a decrease in sync speed.
When fastpath and/or reduced Interleaving depth have been restored, attainable rate has reduced again & sync speed has increased.
Do you have an explanation for this?
Based on what you say, my suspicion (but that's all it is) is that sync speed has been reduced by DLM to provide more stability, alongside Interleaving/delay etc.
From the limited detailed stats I have seen from G.INP active connections to date, it appears that a reduction in Bearer 0 Interleaving depth etc. has actually resulted in slightly LOWER sync speeds.
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 239 236
M: 1 1
T: 23 5
R: 0 16
It was a good idea to use Asbokids f/w as a test, because it gives you a rough idea of what your line conditions would now be like if you were using an ECI modem on a Huawei cab. I cant see the exact figures, but it looks like g.inp would cost you 5Mb of sync speed if you werent using the HG612 :(
Yes lets hope they don't bork things further, and cause issues to those who have benefited from G.inp
I'm just a little concerned about what is going to happen from 26th May
The changes apply to the DLM's default nonReTX profile, which applies to those lines using a non-ginp compatible modem.
The DSLAM is able to detect if the modem is g.inp compatible or not, so nothing any different should occur for those already sucessfully on a G.INP profile.
Thanks for that clarification, Kitz.
Just one question though.......
You mention this:-
"Interleaving causes DELAY - ie increase in latency/ping times. Interleaving does NOT cause loss of sync speed."
For every non-G.INP VDSL2 connection that I have seen stats for since 2011, a switch from fastpath to Interleaved has ALWAYS coincided with an increase in attainable rate & definitely a decrease in sync speed.
When fastpath and/or reduced Interleaving depth have been restored, attainable rate has reduced again & sync speed has increased.
Do you have an explanation for this?
Based on what you say, my suspicion (but that's all it is) is that sync speed has been reduced by DLM to provide more stability, alongside Interleaving/delay etc.
From the limited detailed stats I have seen from G.INP active connections to date, it appears that a reduction in Bearer 0 Interleaving depth etc. has actually resulted in slightly LOWER sync speeds.
From what I can gather you shouldn't be unaffected.
The changes apply to the DLM's default nonReTX profile, which applies to those lines using a non-ginp compatible modem.
The DSLAM is able to detect if the modem is g.inp compatible or not, so nothing any different should occur for those already sucessfully on a G.INP profile.
Thanks for the stats - this is very interesting because its the first full set of stats that Ive seen for any non G.INP modem and it provides a full picture of the true situation. Something weve been unable to do in the past due to the ECI/HH5A not having access to proper stats
What would be really interesting is to compare those stats you do have so far, with a new set using Asbo's f/w after the new changes have been applied*. Did you happen to make a note of your latency ie PING to bbc whilst using the old f/w on the 4th May as it would be interesting to compare the three sets. It may give us a much better idea just what BT are doing.
*Note changes only roll out from 26th of May and it may take several days/weeks for all cabinets to be updated.
Could i ask a question in relation to the above, if the modem is non compatible with G.INP then will that meen your line won't be G.INP enabled and how long do you think it takes the DSLAM to register a modem that is compatible with G.INP ?
Unintended double negative, perhaps?
I will indeed try Asbo's firmware again once I'm certain that my cabinet has been updated.
Sorry, but I don't pay too much attention to latency as it never seems to be an issue here.
I don't have any records apart from an occasional Speedtest.net speed test.
From those tests, Ping is usually around 13 or so.
FWIW, 26th May is pretty much a key date for me.
D: 293 89
D: 8 2
and/or the slight increase in line attenuation that I see as the weather warms up every year?
@ BE Ive just had a look at your stats between the two
Non g.inpCode: [Select]D: 293 89
g.inpCode: [Select]D: 8 2
Looks like your latency would have increased by quite a lot.
I dont know how to convert it into real time figures but it seems awfully high :'(
D: 293 89
R: 16 16
INP: 3.00 4.00
delay: 8.00 8.00
Bearer 0: D: 8 2
Bearer 0: R: 14 14
Bearer 0: INP 46.00 43.00
Bearer 0: INPRein: 0.00 0.00
Bearer 0: delay: 0 0
Bearer 1: D: 1 1
Bearer 1: R: 16 16
Bearer 1: INP: 2.50 4.00
Bearer 1: INPRein: 2.50 4.00
Bearer 1: delay: 0 0
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 31464 Kbps, Downstream rate = 84808 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 69311 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 10.7
Attn(dB): 13.5 0.0
Pwr(dBm): 12.5 3.2
VDSL2 framing
Bearer 0
MSGc: 18 36
B: 45 29
M: 1 1
T: 64 64
R: 14 10
S: 0.0211 0.0476
L: 22736 6717
D: 1219 673
I: 60 40
N: 60 40
Counters
Bearer 0
OHF: 148176 43994
OHFErr: 0 0
RS: 37745881 3997337
RSCorr: 25 0
RSUnCorr: 0 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 26754701 0
Data Cells: 5492 0
Drop Cells: 0
Bit Errors: 0 0
ES: 0 0
SES: 0 0
UAS: 37 37
AS: 201
Bearer 0
INP: 3.00 4.00
INPRein: 0.00 0.00
delay: 6 8
PER: 1.35 4.59
OR: 141.54 73.18
AgR: 69452.43 20072.59
Bitswap: 4/4 0/0
=~=~=~=~=~=~=~=~=~=~=~= Plink log 2015.03.18 05:07:23 =~=~=~=~=~=~=~=~=~=~=~=
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 32160 Kbps, Downstream rate = 84864 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 7.1 13.9
Attn(dB): 13.5 0.0
Pwr(dBm): 12.4 3.2
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 130 97
M: 1 1
T: 0 0
R: 8 8
S: 0.0518 0.1554
L: 21468 5457
D: 16 8
I: 139 106
N: 139 106
Q: 16 8
V: 14 2
RxQueue: 57 39
TxQueue: 19 13
G.INP Framing: 18 18
G.INP lookback: 19 13
RRC bits: 24 24
Bearer 1
MSGc: 186 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 5.3333 16.0000
L: 48 16
D: 3 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 4538432 1520719
RSCorr: 0 0
RSUnCorr: 0 0
Bearer 1
OHF: 3735 3692
OHFErr: 0 0
RS: 44078 14770
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 0 0
rtx_c: 0 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 79999 19997
errFreeBits: 73210 17995
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 9190749 0
Data Cells: 2499 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 11 1
SES: 10 0
UAS: 69 59
AS: 61
Bearer 0
INP: 46.00 47.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 80614.82 20102.08
Bearer 1
INP: 4.00 4.00
INPRein: 4.00 4.00
delay: 3 0
PER: 16.06 16.06
OR: 95.62 31.87
AgR: 95.62 31.87
Bitswap: 0/0 0/0
So you gained approximately 10Mb of sync when G.INP was enabled? Was that as soon as it was enabled or was there a delay?
So you gained approximately 10Mb of sync when G.INP was enabled? Was that as soon as it was enabled or was there a delay?
But, I noticed looking at DSLStats, Interleave is on,& next to is (8).
So you gained approximately 10Mb of sync when G.INP was enabled? Was that as soon as it was enabled or was there a delay?
So you gained approximately 10Mb of sync when G.INP was enabled? Was that as soon as it was enabled or was there a delay?
Can someone tell me if G.INP always has a min of 8ms Interleaving? Since it was enable I have been unable to get it lower I was on fast path before:
Downstream Upstream
Line attenuation (dB): 15.9 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 79998 20000
SNR margin (dB): 6.2 9.1
Power (dBm): 14.2 6.8
Interleave depth: 8 8
INP: 45.00 47.00
G.INP: Enabled
I think AndyH once remarked that you don't want it on an ECI cab as it introduces a lot of latency.
My line is on the G.INP ECI modem trial and I just put a Billion 8800NL on instead so I could see what the DLM was doing. At the moment there is only G.INP on the downstream,
Was there not a config setting on the 8800NL GUI to turn on/off PHyR on the upstream ?Yes, I have up and down ticked. Up is off by default, but I turned it on before the router was connected to the line. I've attached a screenshot.
Well we'll see if it comes true or not :)I think AndyH once remarked that you don't want it on an ECI cab as it introduces a lot of latency.
My understanding is that the emanations from AndyH have been discredited and should be ignored. :-X
My line is on the G.INP ECI modem trial and I just put a Billion 8800NL on instead so I could see what the DLM was doing. At the moment there is only G.INP on the downstream, I'll leave the Billion connected and see what happens as it does support it on the upstream.
we have been working closely with industry on our approach to the application of interleaving where upstream retransmission is not supported, and will be providing an update on progress more widely soon.
Any chance you could leave the Billion 8800NL on and have it upload the line stats to:
http://www.mydslwebstats.co.uk/
Pretty please?
I'm afraid I can't really answer that, unless it only affects those modems such as ECI, HH5A etc. that aren't G.INP capable on the upstream direction.
So, it appears from that statement that users with HG612 or some other modems that are both downstream & upstream G.INP retransmission capable/ready will not be negatively affected by the application of interleaving when connected to Huawei DSLAMS.
I'm afraid I can't really answer that, unless it only affects those modems such as ECI, HH5A etc. that aren't G.INP capable on the upstream direction.
But it was posted by a member that a HG612 modem on a Huawei cabinet lost G.INP on their upstream I can't verify this as there is nothing to backup the claim :(
I'm afraid I can't really answer that, unless it only affects those modems such as ECI, HH5A etc. that aren't G.INP capable on the upstream direction.
But it was posted by a member that a HG612 modem on a Huawei cabinet lost G.INP on their upstream I can't verify this as there is nothing to backup the claim :(
I'm afraid I can't really answer that, unless it only affects those modems such as ECI, HH5A etc. that aren't G.INP capable on the upstream direction.
But it was posted by a member that a HG612 modem on a Huawei cabinet lost G.INP on their upstream I can't verify this as there is nothing to backup the claim :(
I'm afraid I can't really answer that, unless it only affects those modems such as ECI, HH5A etc. that aren't G.INP capable on the upstream direction.
But it was posted by a member that a HG612 modem on a Huawei cabinet lost G.INP on their upstream I can't verify this as there is nothing to backup the claim :(
Could be, but now my upstream ES count is increasing, so seems G.INP was helping ???
Perhaps it didn't need it?
Are you & ip75 both using HG612 modems or maybe a Billion or ZyXel?
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 30714 Kbps, Downstream rate = 82800 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 79999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.6 15.1
Attn(dB): 15.5 0.0
Pwr(dBm): 12.6 6.6
VDSL2 framing
Bearer 0
MSGc: -6 26
B: 130 237
M: 1 1
T: 0 42
R: 8 16
S: 0.0518 0.3781
L: 21468 5374
D: 16 1
I: 139 127
N: 139 254
Q: 16 0
V: 14 0
RxQueue: 60 0
TxQueue: 20 0
G.INP Framing: 18 0
G.INP lookback: 20 0
RRC bits: 0 24
Bearer 1
MSGc: 186 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 5.3333 0.0000
L: 48 0
D: 3 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 1533486
OHFErr: 0 162
RS: 1355617520 2033848
RSCorr: 7019640 1110
RSUnCorr: 0 0
Bearer 1
OHF: 15001649 0
OHFErr: 0 0
RS: 180019051 0
RSCorr: 8 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 2448301 9785
rtx_c: 2409703 6451
rtx_uc: 76978 0
G.INP Counters
LEFTRS: 83966 167
minEFTR: 79982 19991
errFreeBits: 651307888 1655204713
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2711175453 0
Data Cells: 188806563 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 77 121
SES: 31 0
UAS: 116 95
AS: 240968
Bearer 0
INP: 48.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 3.98
OR: 0.01 64.22
AgR: 80614.82 20063.54
Bearer 1
INP: 4.00 0.00
INPRein: 4.00 0.00
delay: 3 0
PER: 16.06 0.01
OR: 95.62 0.01
AgR: 95.62 0.01
Bitswap: 157969/157969 623/624
Total time = 1 days 23 hours 25 min 26 sec
FEC: 201909852 73922
CRC: 7800 176
ES: 77 121
SES: 31 0
UAS: 116 95
LOS: 2 0
LOF: 20 0
LOM: 0 0
Latest 15 minutes time = 10 min 26 sec
FEC: 32697 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 46822 6
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 23 hours 25 min 26 sec
FEC: 2675194 351
CRC: 0 57
ES: 0 36
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 2996217 427
CRC: 0 60
ES: 0 43
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 2 days 18 hours 56 min 7 sec
FEC: 7019640 1110
CRC: 0 162
ES: 0 109
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
QuoteSo, it appears from that statement that users with HG612 or some other modems that are both downstream & upstream G.INP retransmission capable/ready will not be negatively affected by the application of interleaving when connected to Huawei DSLAMS.
afaik that should be correct.
What they have been working on is a solution for incompatible modems by changing the non-ReTx profiles. The first thing that the DSLAM does before selecting the DLM profile is check whether the modem is g.inp compatible or not. I went into a little more depth on the 'nonRe-Tx' profiles in my update last week (http://forum.kitz.co.uk/index.php/topic,15283.315.html).
FYI attached is an example of the ReTX parameters that be configured by the DLM.
Are you & ip75 both using HG612 modems or maybe a Billion or ZyXel?
HG612 with wolfy's latest firmware I'm using
Are you & ip75 both using HG612 modems or maybe a Billion or ZyXel?
HG612 with wolfy's latest firmware I'm using
Hmm.
I might see something in due course via my HG612 then.
I have to say that some of BTOR's statements can be a little ambiguous at times, at least for us EUs.
Could be, but now my upstream ES count is increasing, so seems G.INP was helping ???I'm afraid I can't really answer that, unless it only affects those modems such as ECI, HH5A etc. that aren't G.INP capable on the upstream direction.
But it was posted by a member that a HG612 modem on a Huawei cabinet lost G.INP on their upstream I can't verify this as there is nothing to backup the claim :(
Perhaps it didn't need it?
I dont know for certain....
But you are still below the 300 MTBE limit which DLM considers ok?
Thanks, kitz.
I hoped you would spot my question & re-confirm what you had mentioned previously.
Don't know, but either way, upstream isn't of a concern to me so I didn't think it was a major issue :-[
Don't know, but either way, upstream isn't of a concern to me so I didn't think it was a major issue :-[
I would not dismiss your upstream errors as it also part of the overall MTBE count ;)
I have to say that some of BTOR's statements can be a little ambiguous at times, at least for us EUs.
Don't know, but either way, upstream isn't of a concern to me so I didn't think it was a major issue :-[
I would not dismiss your upstream errors as it also part of the overall MTBE count ;)
It only affects upstream profiling though doesn't it? Next step should be upstream G.INP technically if we assume DLM removed G.INP up if it didn't need it.
It only affects upstream profiling though doesn't it? Next step should be upstream G.INP technically if we assume DLM removed G.INP up if it didn't need it.
My line is on the G.INP ECI modem trial and I just put a Billion 8800NL on instead so I could see what the DLM was doing. At the moment there is only G.INP on the downstream, I'll leave the Billion connected and see what happens as it does support it on the upstream.This is interesting news.
But they are counted separately. The upstream and downstream are configured independently.
As I understand it, they are removing the upstream G.Inp in order to test that scenario.
Wwhen you say Ginp on the downstream is that to the end user - e.g the 80 bit of the 80/20 connection?That's right, on the 80Mb bit, my download. I was on the trial as I have/had an ECI modem on a Huawei cabinet and my latency went right up when G.INP was first introduced. It seems this has been 'fixed' by removing interleaving and G.INP from the upstream.
There was talk the ECI cabs could only do Gimp in one direction - at least if it the end users download that makes more sense than the end users upload.
But they are counted separately. The upstream and downstream are configured independently.
But the MTBE threshold will be much lower on the upstream than it is on the downstream
and don't know how the DLM reacts when the US errored second has reached it's limit
I'm now going to leave the Billion connected so I can upload stats and see if G.INP is renabled on the upstream once a modem that supports it is connected.
Hi Bald_Eagle1,
This email is to alert you that the connection resynced at hh:mm:ss.
Current Stats Previous Stats
============= ==============
Downstream Sync 21432Kbps 22399Kbps
Upstream Sync 5000Kbps 5000Kbps
Bearer 0 DS INP 47.00 47.00
Bearer 0 US INP 46.00 46.00
Please see the attached xlogfile.txt file for ALL the current stats
Regards,
The HG612 Modem Stats Team
I'm now going to leave the Billion connected so I can upload stats and see if G.INP is renabled on the upstream once a modem that supports it is connected.Thank you :) Although I suspect it may not.
Looks like you are right, there was a resync caused by me upgrading the billion's firmware this morning, other than that, no change so far.
I can't remember if I have asked this but can someone please answer.
Is there any point in me buying a HG612 3B? I am currently on an ECI cab with an ECI modem. Will having a HG612 do anything for me if they ever enable G.INP? Or is the ECI cab no better than the modem?
Thanks,
I can't remember if I have asked this but can someone please answer.
Is there any point in me buying a HG612 3B? I am currently on an ECI cab with an ECI modem. Will having a HG612 do anything for me if they ever enable G.INP? Or is the ECI cab no better than the modem?
Thanks,
No there is pointing in buying the HG612 3B, that was a fix when using an ECI modem on the Huawie cab to enable the full G.INP profile which has now started again.
I am sure you are aware that G.INP has not been implemented on the ECI cabinet at the moment so any change of VDSL2 modem be it ECI or HG612 will not enable G.INP on your line.
We dont know yet exactly what is happening with the ECI's. The most we know for certain, is that the situation is up for review when BT finish the Huawei changes. In also still awaiting confirmation on Upstream. At least with the HG612 you can get line stats.
It kind of makes me wonder how they start the rollout as we know are exchanges has a four digit alphabetic code so they must start on A first and Z last :-\
it kind of makes me wonder how they start the rollout as we know are exchanges has a four digit alphabetic code so they must start on A first and Z last
ESABB ABBEYHILL FTTC & FOD Now City of Edinburgh
EMABBOT ABBOTS BROMLEY FTTC Now East Staffordshire District (B)
EMABRIP ABBOTS RIPTON FTTC/P & FOD Now Huntingdonshire District
STABTSY ABBOTSBURY FTTC/P Now West Dorset District
SWAAI ABERAERON FTTC/P Now Sir Ceredigion - Ceredigion
NSABC ABERCHIRDER FTTC Now Aberdeenshire
WNABC ABERCONWY FTTC/P Now Conwy - Conwy
SWAAV ABERCRAVE FTTC/P Now Powys - Powys
SWABT ABERCYNON FTTC & FOD Now Rhondda, Cynon, Taf - Rhondda, Cynon, Taff
SWAA ABERDARE FTTC/P Now Rhondda, Cynon, Taf - Rhondda, Cynon, Taff
Perhaps because a slow process allows for problems to be found, whereas a quick process could result in a very big problem.
It looks like BT Consumer is the problem as they handed out HH5As willy-nilly and as they are the dominant ISP they can force Openreach to do the wrong thing.
This thread has now been referenced on the Billion forum: http://www.billion.uk.com/forum/viewtopic.php?f=19&t=3522&view=unread#p12150
So openreach did what I told them to do a month ago. Leave US on fast path config.
so looks like this has been rolled out to my exchange (ESGIF).
Well they ain't doing it in alphabetical order as im on an exchange that begins LC
So thats another one :)
Historically, they usually do the largest exchange areas first or regionally.
lol... who knows... this is BT :D
Well the local exchange is housed in what looks like a hut next to the phone box and according to the installer is the size of a broom cupboard. :o However the headend is probably ESHAD which is housed in somewhat larger premises serving a much larger area. I imagine the ES prefix covers most of Eastern Scotland though.So thats another one :)
Historically, they usually do the largest exchange areas first or regionally.
So it will be large citys first and then larger towns second then onto to the smaller towns.
I imagine the ES prefix covers most of Eastern Scotland though
Would Openreach / BT be open to replacing ECI cabinets if no solution for G.INP (and I assume G.Fast when it comes out will have similar problems) can be found?
Another solution would be for BT to get a company to make their own version (or tender other companies to build it) of a cabinet specifically to Openreaches requirements, and replace ECI cabinets with that.
Would Openreach / BT be open to replacing ECI cabinets if no solution for G.INP (and I assume G.Fast when it comes out will have similar problems) can be found?
Another solution would be for BT to get a company to make their own version (or tender other companies to build it) of a cabinet specifically to Openreaches requirements, and replace ECI cabinets with that.
Here is the issue.As for reasons why BT stuck in their rut as far as DLM and allowing ISP's control over line configs go, you are no doubt correct it's because they want to save on support costs (BT consumer) could you imagine if they had to employ trained staff instead of what the currently have script monkey's it would cost them a lot, put an end to their sainsbury's vouchers and cash backs and their brethren Plusnet giving away or paying customers to sign up to their broadband
The moment they decided to rollout g.fast has probably also killed vectoring.
From their point of view when g.fast is rolled out and marketed, they want the performance gap between g.fast and vdsl2 to be as big as possible, so users are more likely to upgrade.
The right thing for them to do morally is swap out cabinets to modern equipment and everyone has g.inp and vectoring. But the reality will be something different.
There is also the issue of the retail isp's these guys should not be always seen as good guys against evil openreach. I imagine when the g.inp issues started, the main thing that upset the likes of plusnet was not the fact customers lost performance, but rather their customer support services got overwhelmed and as such their support costs increased. They have probably told openreach they dont want a repeat and as such openreach will be more passive in terms of modifying vdsl2 services in future. This also might explain why older openreach services such as adsl never got g.inp or sra, and why of course we have DLM.
Update
Wednesday 10:36:31 Apologise for the delay in updating this post. BT have confirmed that all trial lines have been loaded with the new profiles, further to this BT have confirmed that all other affected lines have now had the new profiles loaded. That is all lines across all providers.
I just saw this https://aastatus.net/2127QuoteUpdate
Wednesday 10:36:31 Apologise for the delay in updating this post. BT have confirmed that all trial lines have been loaded with the new profiles, further to this BT have confirmed that all other affected lines have now had the new profiles loaded. That is all lines across all providers.
Yet there are some lines such as BaldEagle's which still has G.INP applied on the upstream.
Surly BT Openreach where never going to bork something that was running great.We'd hope!
you guys still have it as no DLM action has been taken on your lines.
Unless they forcefully push out the new DLM changes then you configurations will remain the same.
you guys still have it as no DLM action has been taken on your lines.
Unless they forcefully push out the new DLM changes then you configurations will remain the same.
And what about the guys who are on a huawei cabs and are still waiting for G.INP to be enable on their lines and if statement is correct :-\ saying that BT have confirmed that all other affected lines have now had the new profiles loaded. That is all lines across all providers.
As when i look at MDWS there is about 10 or so users awaing G.INP ???
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Last initialization procedure status: 0
Max: Upstream rate = 3859 Kbps, Downstream rate = 13923 Kbps
Bearer: 0, Upstream rate = 3800 Kbps, Downstream rate = 14259 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 6.0
Attn(dB): 26.7 0.0
Pwr(dBm): 12.6 1.7
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 219 228
M: 1 1
T: 0 0
R: 16 16
S: 0.4904 1.9085
L: 3850 1027
D: 8 2
I: 236 245
N: 236 245
Q: 8 2
V: 3 1
RxQueue: 12 12
TxQueue: 6 6
G.INP Framing: 18 18
G.INP lookback: 6 6
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 32496 10537
RSCorr: 78 2
RSUnCorr: 0 0
Bearer 1
OHF: 311 314
OHFErr: 0 0
RS: 1494 1257
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 12929012 1449808
rtx_c: 9340925 471698
rtx_uc: 14553236 339655
G.INP Counters
LEFTRS: 14176 5078
minEFTR: 14249 3799
errFreeBits: 962808844 307417316
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 110076 0
Data Cells: 12 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 8780 2895
SES: 4824 1128
UAS: 5264 4542
AS: 6
Bearer 0
INP: 43.00 41.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 14300.07 3824.78
Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87
Bitswap: 0/0 0/0
Total time = 1 days 12 hours 42 min 7 sec
FEC: 170318269 6765874
CRC: 240965 11314
ES: 8780 2895
SES: 4824 1128
UAS: 5264 4542
LOS: 33 105
LOF: 285 105
LOM: 76 0
Latest 15 minutes time = 12 min 7 sec
FEC: 129946 25476
CRC: 7446 75
ES: 154 48
SES: 130 37
UAS: 411 324
LOS: 6 6
LOF: 54 6
LOM: 12 0
Previous 15 minutes time = 15 min 0 sec
FEC: 27055 86
CRC: 2140 0
ES: 38 0
SES: 37 0
UAS: 846 810
LOS: 1 0
LOF: 8 0
LOM: 0 0
Latest 1 day time = 12 hours 42 min 7 sec
FEC: 13729701 2064466
CRC: 149599 3500
ES: 5505 950
SES: 2952 336
UAS: 4187 3766
LOS: 19 38
LOF: 168 38
LOM: 33 0
Previous 1 day time = 24 hours 0 sec
FEC: 32849 25437
CRC: 950 130
ES: 38 41
SES: 17 23
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 5 sec
FEC: 78 2
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
I had a resync earlier this morning:Disturbers modem reappeared last night and my SNRM dropped by over 3 and the attainable accordingly. However the line appears to be performing just as it was? I had expected to see a resync overnight, but I am still enjoying the faster rate. Should I just leave it be for now? I don’t see any huge numbers in the stats to worry about, at least to my untrained eye. G.INP must be doing its stuff! ;D
My upstream interleaving is now off and upstream INP is zero, so looks like this has been rolled out to my exchange (ESGIF). Unfortunately this has taken place when my main disturber is offline and my SNRM artificially high, so I have now a higher sync speed from 58708 Kbps to 67709 Kbps. It will be interesting to see what happens when their modem is switched back on. ;D
I have the consolation that I do the same to themI'd never considered that! It is a comforting feeling. :lol:
n another thread PN have informed me that my ECI cab was G-INP enabled earlier this month, resulting in the inevitable speed drop & ping increase.
@tijara33
Your line is also on G.INP at the moment. Are the ping times still higher?
../snip/..
@tijara33
Openreach are rolling a fix for the G.INP issues although I can't commend on when it will be done as I believe it's a gradual roll-out.
he has mistakenly been told by Plusnet that he is G.INP enabled,
I think they somehow are mistaken as bets are the ECI Dslam's don't support G.inp
I think they somehow are mistaken as bets are the ECI Dslam's don't support G.inp
Well this time I am hopeful the ECI cabinet G.INP rollout will begin soon after the MK2 G.INP rollout has been completed on Huawei cabinets maybe the 1st of September and this is all a guesstimate.
looking back though threads & post the issue is with the upstream on ECI modems it could be the same for the ECI cabinets just no way of getting G.INP working on the upstream.
I suppose we shall just have to wait see until all the Huawei's are done, what they decide to do next.
I thought both HUAWEI and ECI both supported their own native versions of PHyR?
Why is it proving to be such a headache enabling what supposedly already existed? Is this purely a modem problem?
. . . it stated interleaving not Retransmission so he was wrong told by Plusnet that he was G.INP enabled . . .
Because G.INP is different from the proprietary versions, it certainly means that the firmware needs changing, but it likely also requires a change to the DSP coding ... and it could well be that the hardware is not powerful enough to support G.INP bi-directionally (reports that speeds might drop a few Mbps suggest this is true). If the modem is running right on the limits of its capabilities, careful crafting is needed in an upgrade ... and it is likely to take time to get this firmware through BT's acceptance & regression tests. And this could be true at the CPE end and at the DSLAM end.
The second problem seems to be that BT's SIN allows G.INP upstream to be optional in any modem, but they (in an entirely different branch) didn't design DLM to make good choices when G.INP upstream turned out to be unavailable.
DLM was probably designed expecting this possibility to be a rare edge condition, so the engineers didn't pay much attention to it ... and didn't spot the issue arising during trials.
Just an update tijara was given his line profile and it stated interleaving not Retransmission so he was wrong told by Plusnet that he was G.INP enabled, so he like myself will still have to wait and see what is to become of us ECI cab users.
its not good that people are given out duff info really. This isn't a one off, Ive seen it about half a dozen times now. :(
And again a snippet from Plusnet Forums
Just under 1 million (of the 2.5 million lines on Huawei cabinets) have had the updated profile so far as they can only do 50-60k lines a day.
To be clear though, the profile update only removes the automatic application of upstream interleaving, where a line does not support retransmission in the upstream. It does not disable retransmission on lines that are capable of supporting it on the upstream.
who is correct and who is wrong ?
Take a look at MDWS (http://www.mydslwebstats.co.uk/HG612-MultUsersLivei.htm?UO=12)
What is unclear atm is if g.inp is being removed if the line can work sufficiently well without it
newt why do you need it on the US? as I remember you dont have US issues.
Per second Per minute Per hour Per day
CRC Up 0 0.07 4.18 100
Down 0 0.24 14.3 344
FEC Up 0 0.08 4.78 115
Down 8.19 492 29499 707966
HEC Up 0 0 0 0
Down 0.04 2.60 156 3747
ES Up 0 0.07 4.18 100
Down 0 0.10 6.27 150
SES Up 0 0 0 0
Down 0 0 0 0
what was your US prior to g.inp in first place, it should be compared to that not the g.inp rate.
According to andyh on plusnet forums . . .
hence the according to.
To be clear though, the profile update only removes the automatic application of upstream interleaving, where a line does not support retransmission in the upstream. It does not disable retransmission on lines that are capable of supporting it on the upstream.
With retransmission, a line experiencing frequent noise bursts can suffer significant throughput degradation.
0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Error Protection Off
link (http://community.plus.net/forum/index.php/topic,138084.msg1237534.html#msg1237534)
Should be, but why I want to see the full list. Those are basically banded to 10Mb... so for a line capable of syncing at 80/20 it will show something likeand that is the same profile for my line but error correction is most certainly ON, So their botch named fix doesn't work as intended, assuming they intended it to have error correction off that is, I am somewhat sceptical due to the secrecy by BT Do they think that all EU's are fools and won't know any better ? Kitz you already have had my stats following the botch rolled out on my circuit, re the thread i started about the loss of nearley 2mbps from the upstream as a direct result of G.inp and or theQuote0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Error Protection Off
The list looks like its showing the stages of DLM progression it can go through ie
Error Protection off > Retransmission Low > Retransmission High
assuming they intended it to have error correction off that is
So a less confusing and more open & honest way of wording the profile i'm on would be upstream error correction ON or Low or High ? instead of saying to obvious error protection is OFF just a thought , although i think the fast path profile did refer to fec being on, in that it said about error correction being on ,Openreach, what a mess and tangled web they keep on weaving God help us all if they ever decide to roll out vectoring , G fast would mean new hardware to EU's , although vectoring would be pushing the current hardware to it's limits as it can only support 100mbps in theoryQuoteassuming they intended it to have error correction off that is
You post possibly crossed with my last one. Note the difference between Error Protection and Error Correction
Also one of the reasons why Ive been harping on recently about the need to separately clarify Interleaving and Error Correction separately. Error Correction is FEC which we know they apply silently by default regardless if interleaving is applied or not. INP and G.INP are forms of Error Protection that can modify the amount of Error Correction (& Interleave if need be).
but error correction is most certainly ON
Need someone who has had g.inp Mk2 rolled out and who can give me their profile and full linestats please to confirm. Anyone available to provide this info for me please?
0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Error Protection Off
Because of this we have realised our past approach has been ineffective in recent months and we will now take a new approach in our aim to increase competition and transparency to consumers, This includes directly tackling the lack of inclusion of line rental on broadband prices, and the lack of information to consumers in regards to compatible equipment and line profiling.
0.128M-20MUpstream, Error Protection Off
release the information you have to see if the community can put the pieces together
kitz yeah I have been telling andyh its false on the forums, but noone is backing me up overthere, so I just look like a raving lunatic :)
When I posted about him here, sorry if I didnt make it clear, but I did not post it as a fact, rather just as his (and openreach's claim?). I defenitly disagree with what he said, and his affiliation with the BT group seems a bit more clear now as when I suggested to him to use his high level access to tell them they wrong he did a blunt corporate reply to tell people to report via the usual channels which we all know is useless.
I cant say everything I know regarding ofcom sadly but what I can say is ofcom are not happy currently about whats happening with the retail side of the market, they not happy about not a single isp passing on the wholesale changes of 1 month min terms for FTTC (hence the new changes regarding poor performance) and they also not happy with the current DLM situation where not a single isp even aaisp is passing on information. Instead customers are spending their own money to buy new compatible modems, which believe me ofcom has not taken lightly.
Ofcom have now admitted they were taking the wrong approach tommy, before (and to be fair it did work early on to a degree) they were regulating only wholesale with the assumption retail would take care of itself, however clearly that's all gone astray now.Well it isn't surprising IMO that the ISP's SP's haven't been passing on these savings, in particular the biggest providers, i find it hard to except that ofcom really believed that isp's would pass on the savings/changes made at the wholesale level, i didn't think they where so naive
looks like the mods at plusnet got sick of warning me, instead they just deleted my post silently.noticed that it had mysteriously disappeared So much for freedom of speech or opinions, their silly rules about quotes are a pain, i even had one of my posts edited by their mods and had not posted the wholes quote, i don't think they all can read properly they are certainly bias towards some people
http://community.plus.net/forum/index.php/topic,138084.msg1238310/topicseen.html#new
Will keep an eye out to see if kitz post stays intact.
My post was similar to deathtrap's I just said we know he doesnt care and kitz was posting the correct facts.
There doesn't seem to be an ETA, nor obvious pattern on which cabinets are being "upgraded", but there is an assumption that ECI will happen after Huawei.
looks like the mods at plusnet got sick of warning me, instead they just deleted my post silently.
http://community.plus.net/forum/index.php/topic,138084.msg1238310/topicseen.html#new
Will keep an eye out to see if kitz post stays intact.
My post was similar to deathtrap's I just said we know he doesnt care and kitz was posting the correct facts.
hmm i wonder how long my post there will last ;D
newt are you back on g.inp yet or still waiting?
newt are you back on g.inp yet or still waiting?
:no: still waiting it took my line 2 months and 19 days to get the MK1 G.INP rollout so i expect to get the MK2 in August, So if you add up both rollouts i have had to wait close to half a year :o
WTF!!!!!!!!!!!!!!!!!!!!
http://community.plus.net/forum/index.php/topic,138084.msg1238310/topicseen.html#new
"what Kitz says or her forums says it all really". Kitz is a chick?
I think I'm in love!
And also with Kate Russell (BBC Click)
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fkaterussell.weebly.com%2Fuploads%2F1%2F3%2F2%2F2%2F1322404%2F5502189.jpg&hash=b45737bd41c5a1b8a4c61d2c6066da4734bb9763)
Us ECI Cab users are still waiting.. for something .. anything :'( :)
I think I'm in love!
Btw - NewtronStar is kindly offering up his HomeHub5A for free in the name of research if there is anyone on a g.inp'd cab who wishes to play. The only reason he's getting rid is because it doesnt work with his new ISP (EU needs to be with BT or PN) - linky (http://forum.kitz.co.uk/index.php/topic,15580.0.html)
@ chrys, Ive not been back to read whats been said (or deleted), but I bet you any money there is no admittance that he was wrong.
I know what he will have done and thats seen ReTX in the profiles and jumped to conclusions and formed his own opinion. Although Im happier with the fix and it gives hope to ECI cabs, Im still not sure what the future re the ECI modems are. Still need to see proper stats for those and Ive not seen anyone reporting any improvements for those yet. The removal of Interleaving should ease things a tad, but if they have also upped the default Error correction like some say, then the lack of attainable sync could be an issue for some. I'm waiting to see proper stats though on those - which isnt going to be easy. :(
Btw - NewtronStar is kindly offering up his HomeHub5A for free in the name of research if there is anyone on a g.inp'd cab who wishes to play. The only reason he's getting rid is because it doesnt work with his new ISP (EU needs to be with BT or PN) - linky (http://forum.kitz.co.uk/index.php/topic,15580.0.html)
The earliest I am aware of had it activated 7th February.
He still appears to be on the 'Mk 1' G.INP profile (G.INP active for both DS & US).
His connection seems to be actively using/needing the benefits of G.INP's upstream ReTX, so I wonder if it is only those connections that are deemed to NOT need it that are now having it removed from their upstream
FWIW, I have attached a 96 day ongoing montage for one user who initially had G.INP activated around 5th March (i.e. one of the earlier users to have it activated).
At 03:10 this morning my connection re-synced, and it now has G.INP on the downstream only. Upstream interleave depth is now 1, upstream INP is 0, and the upstream SNRM increased by 2 dB for the same connection speed. I'm now seeing small numbers of upstream ES (1 to 5 per hour so far).
Has anyone got any decent increase in db margin and therefore connection speed by ginp being enabled? I am on fastpath 57/20 affected by crosstalk. Can I expect a speed bump if they decide to rollout to eci cabs?
Downstream Speed 74.7 Mbps
Upstream Speed 20.0 Mbps
Profile Name 0.128M-80M Downstream, Error Protection Off - 0.128M-20M Upstream, Error Protection Off
Do you think this could be due to Mk2 G.INP being enabled on the cab overnight ?
I think was work this morning near me.
Just after midnight I lost PPP, I thought was a plusnet or BTw issue, then not long after that I lost sync. Also not long after that PPP was still dropping, so at that point I got annoyed, turned everything off and went to bed. This morning is back on now but no g.inp.
Ok I just made a graph in modem stats for last 24h (thanks to work in other thread BE, is really fast now).
It reports a massive spike in crc it seems around the time I lost sync, 5k crc errors, but only 10ES, so was an errored second with tons of CRC.
That could still be caused by someone at the dslam yanking out the able tho :)
Just thought I would report it.
reread kitz I edited :)
@NS
Im as bad because I also should have twigged this and said earlier. So in reality it took them 2 months to do all the line upgrades.
. . . (second user on a newly enabled Huawei cab, ECI modem)
<snip>
Profile Name 0.128M-80M Downstream, Error Protection Off - 0.128M-20M Upstream, Error Protection Off
Profile Name 0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Retransmission Low
Profile Name 0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Error Protection Off
Unfortunately though when HG612stats locks up with the double instance, this then causes DSLstats to also not record.. so I dont have a clue what was happening at around 3:30 and Ive no stats from either. :(
I dont think so b*cat - unless I'm missing something?
Its only once every few months when it seems to get stuck with a double instance, so its no big deal. As soon as I clear it out of Task Manager then all is good again :) I suppose the most annoying thing is because DSLstats also detects an instance of it, then that also stops reporting too. I eventually noticed when I saw DSLstats flashing in my sys tray that something had gone wrong.
Looks like Baldeagle1 has joined the MK2 club :)
I'm not 100% sure that the Bearer 0 RR bits data is correct (RRC bits: 0 24).
If I am understanding the ITU G.998.4 pdf correctly, the RRC (Retransmission Return Channel) is used to send acknowledgements for what has been received. If something doesn't get acknowledged it gets re-transmitted. So if G.INP is only enabled for re-transmitting downstream data, then there will only be the RRC on the upstream.
There was quite a hit percentage-wise on my US sync speed, but SNRM had been running quite low for a few days for an unknown reason (increased crosstalk again :-\).
Yes, indeed, that makes perfect sense. :)
Cant see the actual figures from the graphs {edit swapped to MDWS figures} but as you say I can see
upstream SNRm appeared to have been running at about 5.5dB and came back up at 6.2 dB
Sync dropped from 4951 -> 4102
So a good portion of that speed loss is due the the loss of SNRm :(
On a Huawei cabinet here,with a HG612, & I just had major work done on my line,finally got rid of the aluminum cable, :dance::yay: :dance: gone from 9Mb to 65MB, been up four days & I'm still waiting for a resync to see if speed creeps up a bit.
I now find G.INP is no longer active on my line. :(, So , I presume it's G.INP MK2 has kicked in, which is a shame, as with G.INP MK1, I was getting around a extra 6Mb plus with it.
On a Huawei cabinet here,with a HG612, & I just had major work done on my line,finally got rid of the aluminum cable, :dance::yay: :dance: gone from 9Mb to 65MB, been up four days & I'm still waiting for a resync to see if speed creeps up a bit.
I now find G.INP is no longer active on my line. :(, So , I presume it's G.INP MK2 has kicked in, which is a shame, as with G.INP MK1, I was getting around a extra 6Mb plus with it.
Sounds more like you've had a reset and you will have to wait for the catch-ups. If you've lost 6Mbps from the downstream then it sounds like you havent got Mk2, but the 'old profile' pre g.inp Mk1. I havent looked at your stats to confirm whats going on with your line... but Mk2 should still apply downstream g.inp by default.
@KIAB: looking on MDWS is looks like the reason you don't have G.INP is because you don't need it. Before, you needed G.INP to get what you had and for it to be stable (before then you would've been interleaved which is why you'd have lost 6Mbps) - now you have a more stable line, you don't need interleaving or G.INP.
69/17.5 is a significant improvement compared to 45/8! ;D
I just got mk.IIed a few hours ago,
And I'm still banded on downstream..
Same here. Been stuck at 66999 down since G.INP MK I applied in March with around 8dB snrm. Bahusing what modem?
And I'm still banded on downstream..
Same here. Been stuck at 66999 down since G.INP MK I applied in March with around 8dB snrm. Bah
btw can you do me a favour please and see if you can check things like your R value from pre-INP to now that you are on G.INP Mk2. Ive seen someone imply that theirs has increased.. and that they are now getting more FEC overheads. I'd be interested on your line because I know its very stable and therefore should give a very good indication if there are differences or not.
Before G.INP | --- | Mk.I G.INP | --- | Mk.II G.INP |
Bearer 0 MSGc: 18 26 B: 239 237 M: 1 1 T: 23 42 R: 0 16 S: 0.0955 0.3781 L: 20104 5374 D: 1 1 I: 240 127 N: 240 254 | --- | Bearer 0 MSGc: -6 -6 B: 130 97 M: 1 1 T: 0 0 R: 8 8 S: 0.0518 0.1554 L: 21468 5457 D: 16 8 I: 139 106 N: 139 106 Q: 16 8 V: 14 2 RxQueue: 57 39 TxQueue: 19 13 G.INP Framing: 18 18 G.INP lookback: 19 13 RRC bits: 24 24 | --- | Bearer 0 MSGc: -6 26 B: 130 237 M: 1 1 T: 0 42 R: 8 16 S: 0.0518 0.3781 L: 21468 5374 D: 16 1 I: 139 127 N: 139 254 Q: 16 0 V: 14 0 RxQueue: 60 0 TxQueue: 20 0 G.INP Framing: 18 0 G.INP lookback: 20 0 RRC bits: 0 24 |
Bearer 0 INP: 0.00 0.00 INPRein: 0.00 0.00 delay: 0 0 | --- | Bearer 0 INP: 46.00 47.00 INPRein: 0.00 0.00 delay: 0 0 | --- | Bearer 0 INP: 48.00 0.00 INPRein: 0.00 0.00 delay: 0 0 |
I would expect that Mk.I should have slightly increased your downstream latency, but very minimally so not noticeable. I would also expect it to be slightly less on Mk.II but due to the small values I really cant see anyone noticing or them being able to say its affecting their line on a day to day basis.
Absolutely identical. It was one of the parameters I meant when I talked about framing, and I most certainly would have said something!
Hi Dray
This is to let you know that a resync/restart occurred on your line at 02-07-2015 11:49 local time (+/- 1 minute).
Reason: 1 Remote Defect Indicator/DLM
Current Downstream Sync Rate is now 80000kbps Current Upstream Sync Rate is now 19999kbps
Thanks also for the latency graph. If Ive read it correctly, then a very rough guestimate would put your average latency at 13-13.25 and now it appears to be at about 12.5ms As you say it is variable and early days, but on the face of it it does so far look like there perhaps has been a slight improvement?
You may have also missed by edit in my last post about throughput speed. I would be interested to see if you now have trouble reaching anything over 18Mbps on the upstream. tyvm for all your input.
Since Link time = 6 days 7 hours 11 min 11 sec
FEC: 54137 4380
CRC: 112 961
ES: 14 360
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Has the rollout finished yet for the Huwai cabinets? Should everyone with ECI cabs (me included) start to hope for some news soon?
Has the rollout finished yet for the Huwai cabinets? Should everyone with ECI cabs (me included) start to hope for some news soon?
Black sheep stated in another thread that us on ECI cabs might not see anything start until the end of the year, not great but it's something, hopefully that remains true but with openreach you never can tell.
And when doe's the non G.INP enabled Huawei lines start getting G.INP enabled as it's coming up two months since the rollout and getting very impatient here surly all the Mk1's should have been updated to Mk2 by now.
Just had my FTTC resync this morning around 4am
I had G.INP Mk1, then after some serious line work, & a DLM reset, it has gone for ever :(, & there is no signs of Mk 2 making an appearance.
line rebooted today and now have g.inp enabled.
any idea why my snr would have dropped?
new stats:
Connection Speed 40000 kbps 9999 kbps
Line Attenuation 16.8 dB 0.0 dB
Noise Margin 21.8 dB 22.22 dB
Previous stats:
Connection Speed 39998 kbps 9999 kbps
Line Attenuation 16.7 dB 0.0 dB
Noise Margin 26.3 dB 25.25 dB
new stats:
Connection Speed 40000 kbps 9999 kbps
Line Attenuation 16.8 dB 0.0 dB
Noise Margin 21.8 dB 22.22 dB
Previous stats:
Connection Speed 39998 kbps 9999 kbps
Line Attenuation 16.7 dB 0.0 dB
Noise Margin 26.3 dB 25.25 dB
lots of enables today.
lots of enables today.
18/06/2015 - Progress report
Mk1 to Mk2 updates about half way done.
Any Huawei lines which missed Mk1 because their line went live after March or have had a DLM reset will go straight to Mk2 profile when the Mk1 -> Mk2 upgrades are complete.
ECI situation to be reviewed after completion of the Huawei cabs.
12/07/2015 - Progress report
All Huawei Mk1 -> Mk2 upgrades should be complete.
Currently rolling out G.INP to the 'catchup' lines. Anticipated full completion of the Huawei lines within the next couple of weeks.
Found I now have G.INP enabled this morning, speed has gone up to 75Mb from the previous 69Mb. :)Does anyone know why Ginp may give you more not less speed? I have major crosstalk issues on eci cab so if ginp ever comes along I hope I will get a bit of speed back but as ginp is another channel bearer1 wouldn't that mean the bandwidth b1 takes up would cause a speed drop?
And the SNR has dropped a bit to Down 6.2 & Up 5.6.
Found I now have G.INP enabled this morning, speed has gone up to 75Mb from the previous 69Mb. :)Does anyone know why Ginp may give you more not less speed? I have major crosstalk issues on eci cab so if ginp ever comes along I hope I will get a bit of speed back but as ginp is another channel bearer1 wouldn't that mean the bandwidth b1 takes up would cause a speed drop?
And the SNR has dropped a bit to Down 6.2 & Up 5.6.
I can't explain why G.INP gives more speed generally though, but it's obviously related to how it corrects errors and is therefore far more efficient than the traditional INP.
In essence, G.INP improves the reliability of the connection which allows it to run at a faster rate.
So, would I see any further improvement in the speed changing from a HG612 to a Billion 8800NL?
Does anyone know why Ginp may give you more not less speed? I have major crosstalk issues on eci cab so if ginp ever comes along I hope I will get a bit of speed back but as ginp is another channel bearer1 wouldn't that mean the bandwidth b1 takes up would cause a speed drop?
now its all good I would leave as is, plus I think having the modem separate is superior.
Reed Soloman (RS encoding) means that redundant data is carried 100% of the time, so if the line isnt erroring then that redundant data is being transmitted taking up some of the bandwidth and reducing the available sync.
There's also some good/short lines that dont need any error protection or error correction which wont really see any benefit.
Note that it is a very new cab (only a couple of weeks old) supplied under BDUK
might have been an idea to leave it as g.inp kept your error rate low even with the lower snrm :)
G.INP has now been re-enabled on my line but only on the downstream.
It's a right pain as now I'm getting upstream errors (granted they are small).
G.INP was working perfectly on the downstream and upstream so I still don't understand why it was removed :no:
It looks like it makes a big difference - from 37 to 43 Mbps
It's a right pain as now I'm getting upstream errors
I'd rather have no errors than some errors
I'd rather have no errors than some errors
G.INP comes into its own when it replaces Interleaving and Error Correction. If the line has sufficient errors to benefit from Interleaving and RS error correction then g.inp is a very good thing... but even then there are cases where traditional RS & Interleaving are better than G.INP. It all depends on the type of burst noise you get.
Even when pre-G.INP, my connection was on fastpath for DS & US, I saw a low level of FEC/RSCorr error correction.
What is the unit of data that is considered lost/corrupted or successfully sent Kitz? A fixed-sized block? Small?
What is it that is retransmitted? The data or like harq?
RTx is designed to protect the performance and stability of DSL systems in the presence of impulse noise. It encapsulates payloads into frames that are called data transmission unit (DTU), which are stored in a buffer after transmission. INP is achieved by retransmitting – upon request of the receiver – just those received DTUs that were received with errors.
xDSL
Mode VDSL2
Traffic Type PTM
Status Up
Link Power State L0
Downstream Upstream
Line Coding (Trellis) On On
SNR Margin (dB) 8.2 6.1
Attenuation (dB) 25.4 0.0
Output Power (dBm) 11.9 6.6
Attainable Rate (Kbps) 29197 4852
Rate (Kbps) 24998 4885
B (# of bytes in Mux Data Frame) 114 143
M (# of Mux Data Frames in an RS codeword) 1 1
T (# of Mux Data Frames in an OH sub-frame) 0 38
R (# of redundancy bytes in the RS codeword) 8 12
S (# of data symbols over which the RS code word spans) 0.1450 0.9341
L (# of bits transmitted in each data symbol) 6784 1336
D (interleaver depth) 4 1
I (interleaver block size in bytes) 123 78
N (RS codeword size) 123 156
Delay (msec) 0 0
INP (DMT symbol) 51.00 0.00
OH Frames 0 0
OH Frame Errors 0 363
RS Words 3747157272 3784687
RS Correctable Errors 2919023 4735
RS Uncorrectable Errors 0 0
HEC Errors 0 0
OCD Errors 0 0
LCD Errors 0 0
Total Cells 1188700652 0
Data Cells 337508933 0
Bit Errors 0 0
Total ES 0 303
Total SES 0 0
Total UAS 25 25
Still not seeing G.INP on my line. Should they all be rolled out by this point?
I (interleaver depth) 4 1
INP (DMT symbol) 51.00 0.00
Shouldn't there also be a delay listed if that's true?
Also my speed has dropped lately rather than increased and my pings haven't decreased... so if G.INP has really been activated then I'm severely disappointed. :(
does G.INP have its own fastpath/interleaving vs the normal part of the line or are you saying that this line doesn't appear to be interleaved at all anymore?
INP (DMT symbol) 51.00 0.00
I'm currently using a Billion 8800NL
The way you can look at G.INP MK2 is the Downstream has very low interleaving (2 - 16) and the Upstream is on Fastpath (interleaved 1) if that helps.
QuoteINP (DMT symbol) 51.00 0.00
hmmmm... that looks like the line has g.inp mk2 applied at cab level.QuoteI'm currently using a Billion 8800NL
Do you have the latest g.inp firmware?
----
ETA
Sorry NS, just noticed that you also spotted the signs of g.inp Mk2.
I think Enverex may need to check that he's upgraded to the g.inp f/w - see this thread (http://forum.kitz.co.uk/index.php/topic,15124.15.html).
Stats recorded 21 Aug 2015 08:59:07Speed increased from just over 43Mb to 48.4Mb
DSLAM/MSAN type: BDCM:0xa485 / v0xa485
Modem/router firmware: AnnexA version - A2pv6F039g1.d24m
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 2 hours 13 min 1 sec
Resyncs: 1 (since 16 Aug 2015 12:53:33)
Downstream Upstream
Line attenuation (dB): 21.4 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 48446 10569
SNR margin (dB): 6.3 6.3
Power (dBm): 12.6 5.9
Interleave depth: 8 1
INP: 48.00 0
G.INP: Enabled
But I didn't think DLMs acted so fast on line improvements?Well after switching the Huawei modem for the ECI which worked fine for some 2 days then following DLM intervening left the ECI is a similar state IE appeared to have a sync but no PPPOE session, and i could not connect. the connection had been down for a few hrs before i was aware of it,
AlecR: The HG612 reports it as 21.9dB and the TG589vn v3 reports it at 16.9dB.
he said prior to hauwei rollout it was done some months before which suggests ECI users wont get g.inp in september also with october unlikely at this point.
Of course its possible these configs will get rolled out shortly before rollout, but I thought i would post this information.
I've just had G.INP re-enabled on my upstream this morning.
> adsl info --vendor
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 8564 Kbps, Downstream rate = 48927 Kbps
Bearer: 0, Upstream rate = 8564 Kbps, Downstream rate = 40821 Kbps
ChipSet Vendor Id: BDCM:0xa48c
ChipSet VersionNumber: 0xa48c
ChipSet SerialNumber:
> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 8564 Kbps, Downstream rate = 48943 Kbps
Bearer: 0, Upstream rate = 8564 Kbps, Downstream rate = 40821 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 5.6 5.9
Attn(dB): 22.2 0.0
Pwr(dBm): 11.9 2.8
VDSL2 framing
Bearer 0
MSGc: 18 26
B: 51 239
M: 1 1
T: 64 44
R: 12 0
S: 0.0405 0.8905
L: 12632 2156
D: 799 1
I: 64 120
N: 64 240
Hm, I wonder if there's an issue with the Billion router working/activating G.INP? What new router did you get?[On the assumption that your Router/modem supports G.INP]
Even I have come to the conclusion that the ECI cabinets won't be G.INP enabled we are now into November 2015, I just think this JDSU update is a red herring to stop ECI customers getting angry.
It's 5 months now since the huawei cabinets got this G.INP MK2 rollout my guess is if the ECI has not been enabled for G.INP by now it's never going to happen :(
I hope that support for ECI cabs is still being worked on.
DSLAM/MSAN type: IFTN:0xb204 / v0xb204 should i still be using the HG612 FTTC
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 32 min 3 sec
Resyncs: 0 (since 18 Nov 2015 22:22:09)
Downstream Upstream
Line attenuation (dB): 22.1 0.0
Signal attenuation (dB): Not monitored
Connection speed (kbps): 33685 8621
SNR margin (dB): 6.3 6.2
Power (dBm): 12.2 6.2
Interleave depth: 659 1
INP: 3.00 0
G.INP: Not enabled nope
RSCorr/RS (%): 0.0088 0.0007
RSUnCorr/RS (%): 0.0001 0.0000
ES/hour: 8.01 0
Regrettably I have to agree. Another example of Openreach doing Retail's bidding.
Does the interference that G.INP fixes comes from the copper connection in the cabinet? i.e. if it was a fibre to fibre connection then in theory there wouldnt be any need for G.INP?
I can imagine if the ECI cabinets dont support G.fast there is going to be a public backlash. Seeing adverts offering these massive speed increases then people go to order and because they are on an ECI cabinet, people arent going to take it well.
I'm sure that will hit their shares too.
My mate had Infinity installed on Wednesday and yesterday when i was turning off smart setup and splitting the SSIDs for him i couldn't believe that the engineer has given him a HH5 Type A and he is connected to a Huawei cab. It seems no one has learnt anything really.
Some others may disagree but I believe the HH5A is capable of supporting downstream G.INP
The HH5A does support downstream G.INP but not on the upstream
The HH5A does support downstream G.INP but not on the upstream
How do you know this as it doesn't show any G.INP data?
I can imagine if the ECI cabinets dont support G.fast there is going to be a public backlash. Seeing adverts offering these massive speed increases then people go to order and because they are on an ECI cabinet, people arent going to take it well.
I'm sure that will hit their shares too.
Nice theory but I doubt it - for one thing BT has a pretty thick skin and their shareholders won't really care-in the scheme of things its financially immaterial. While other members of the public will be complaining that any faster service is available to others while they are still stuck on ADSL Max etc.
However, even BT have suggested some G.Fast cabinets will be situated next too existing FTTC ones - so if there is an issue enabling an existing one, they can simply put a G.Fast box next to it.
Has it been confirmed that ECI cabs are not compatible with G.FAST????
Get a grip. Fibre to each home needs rolling out now. No distance limitations and no more marketing BS.
Rip out the copper and sell it. That would pay for the FTTP install costs.
Are you sure of that?
Hello, long time reader here :)
My mate had Infinity installed on Wednesday and yesterday when i was turning off smart setup and splitting the SSIDs for him i couldn't believe that the engineer has given him a HH5 Type A and he is connected to a Huawei cab. It seems no one has learnt anything really.
My mate had Infinity installed on Wednesday and yesterday when i was turning off smart setup and splitting the SSIDs for him i couldn't believe that the engineer has given him a HH5 Type A and he is connected to a Huawei cab. It seems no one has learnt anything really.
Some others may disagree but I believe the HH5A is capable of supporting downstream G.INP
Hello, long time reader here :)
My mate had Infinity installed on Wednesday and yesterday when i was turning off smart setup and splitting the SSIDs for him i couldn't believe that the engineer has given him a HH5 Type A and he is connected to a Huawei cab. It seems no one has learnt anything really.
Hello and welcome :)
My daughter recently moved home and had fttc installed in Oct. The Openreach engineer supplied them with an ECI modem. (She is on a Huawei cab).
She seems more than happy with her speeds which she says were better than VM at her last house. Bearing in mind she will be moving again soon, Im not bothering to say or do anything.
Whether it does or it doesn't you would have thought they would have been supplying type b as a matter of course by now.
RxQueue: 42 0
TxQueue: 14 0
G.INP Framing: 18 0
G.INP lookback: 14 0
RRC bits: 0 24
Retransmit Counters
rtx_tx: 10 0
rtx_c: 2 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 79982 0
errFreeBits: 766157 0
ChipSet Vendor Id: IFTN:0xb204
ChipSet VersionNumber: 0xb204
ChipSet SerialNumber: 5502215529
for those who it hasnt gone well please dont report a fault :p until I have been moved over incase they suspend it.Oops too late
@chrysalis I was confirmed by Plusnet today G.INP enabled as my profile states here 0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Error Protection Off
@chrysalis I was confirmed by Plusnet today G.INP enabled as my profile states here 0.128M-80M Downstream, Retransmission Low - 0.128M-20M Upstream, Error Protection Off
for those who it hasnt gone well please dont report a fault :p until I have been moved over incase they suspend it.
Bob Pullen has indicated they have
for those who it hasnt gone well please dont report a fault :p until I have been moved over incase they suspend it.
Have not seen any new G.INP Rollouts to ECI users this week could they have halted it ?
for those who it hasnt gone well please dont report a fault :p until I have been moved over incase they suspend it.
Have not seen any new G.INP Rollouts to ECI users this week could they have halted it ?
Wj66 and les-70 on 5th, plus some new users more recently who are on ECI cabs.
I seen it.
They havent told you the date you was put on g.inp, they just told you that you on g.inp. You could have been on g.inp for weeks without knowing.
yeah I understand it does seem likely, just would be nice to be sure. :)
I am going to make a suggestion (and please don't quote it in other fora as a fact) that perhaps a firmware update is to be rolled out to either the ECI B-FOCuS V-2FUb/r Rev. B modems or the ECI Hi-FOCuS M41 Mini-Shelf MSAMs. ;)You mean an ECI cab version of G.INP mk 2 - identify the devices that don't support it and turn it off for them?
In the words of Lance Corporal Jones (https://en.wikipedia.org/wiki/Lance_Corporal_Jones): "Don't panic!".
Bob Pullen has indicated they have
halted?
There is still people on MDWS getting activated, 2 have even been done this evening.
Ok they not new activations, they both lines that look like they have been down for a number of days and they triggered the alerts.
So sods law I guess I may be a victim of a halt? Where is the link to the plusnet post? I guess like newt was I could be waiting for a while now then.
yeah I understand it does seem likely, just would be nice to be sure. :)
Chrysalis even if vectoring was turned on tomorrow you would find users complaining about loss of sync rate and higher pings Openreach must take a stand here you either update your hardware or fall behind, is that not the same situation with MS or when using an old graphics card for gaming
The ECI and HG612 modems are 4-5 years old that is old technology these days yes it will work but at a slower rate.
All ISP's should be giving us at least a BCM63168 as standard or better
Openreach were turning off G.INP on some ECI lines that were already enabled even if it was working ok,
Bob Pullen has indicated they have
halted?
There is still people on MDWS getting activated, 2 have even been done this evening.
Ok they not new activations, they both lines that look like they have been down for a number of days and they triggered the alerts.
So sods law I guess I may be a victim of a halt? Where is the link to the plusnet post? I guess like newt was I could be waiting for a while now then.
Only one of those two (spotter) was ECI with G.INP and he was a NEW user so no previous stats - his last resync was 17 hours prior to first stats.
On Wednesday, xhemp registered for ECI and has G.INP but no previous stats. His last resync was 93 hours prior to registration.
But there were two new ECI/G.INP activations on Tuesday from existing users as posted elsewhere.
There are only 30 ECI users on MDWS at the moment, and only five of those don't yet have ECI with another one currently deactivated. Not sure that's a reliable basis for evaluating whether it has been delayed or stopped?
Openreach were turning off G.INP on some ECI lines that were already enabled even if it was working ok,
From what I can gather, the roll-out hasn't been completely suspended.
It appears some lines could be susceptible to a fault that looks suspiciously like the ECI modem - Issue 1 problem (http://forum.kitz.co.uk/index.php/topic,15283.msg284199.html#post_ECI_modem_issue1).
I have a bit more info, which Ive posted here:- G.INP rollout 2016 - ECI cabs (http://forum.kitz.co.uk/index.php/topic,17446.0.html)
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
or if G.INP has just been switched off. Any way to find out?1) Ask PN if they will do a GEA service test
I used dslstats
DSLAM/MSAN type: IFTN:0xb204 / v0xb204
Does anyone on an ECI cabinet still have working G.INP out of interest?
Hi Kitz,
No the internet dropped and G.INP vanished. I had the reset yesterday 11/04/15 which made matters even worse.
Looking back through my info it seems G.INP turned off at around 5am on 08/04/16.
I used dslstats on the SBG3300-N and now on the D7000, no one from OR I've ever had out can understand any of the information it gives, either that or they just don't admit it .
Mine wasnt reset or an engineer visit or ISP change. 10 days after activation a resync followed around 6:30am and it was disabled. Sky none the wiser...
Mine wasnt reset or an engineer visit or ISP change. 10 days after activation a resync followed around 6:30am and it was disabled. Sky none the wiser...
Thats because you must on one of those cabinets who are directly effectd by the ECI G.INP rollout issue
Possibly but other "206" users are still g.inp enabled with no problem it would appear.
Can't see why Sky would know anything about G.INP to be honest, it's really part of the local loop.
Does anyone on an ECI cabinet still have working G.INP out of interest?
Yes there are a fair few on mywebstats still enabled and dont appear to be losing it just yet. Considering I lost mine on the 8th I am not convinced its suspended yet as the others are still enabled which seems a bit odd to me.
yes plenty, its us with non working that are the minority, and only two of us on here who didnt have it at all.
well both of you guys raised faults whilst it was activated right?
well both of you guys raised faults whilst it was activated right?
My fault was logged 2 months before G.INP was switched on though.
Very true we are not direct clients but our ISP's are. The ISP's have a right to know what is planned and in turn so are we from our ISP's.
Utopian I know and we are talking about OR here, who let's face it aren't at all forthcoming due to the monopoly they have.
Sadly we are not their direct customers, they probably have provided information to the CP's. But the CP's are witholding the information either due to NDA or their own doing.
I agree with you its wrong but this is the situation we have now with the current market structure.
Very true we are not direct clients but our ISP's are. The ISP's have a right to know what is planned and in turn so are we from our ISP's.
Utopian I know and we are talking about OR here, who let's face it aren't at all forthcoming due to the monopoly they have.
Openreach are generally transparent with their direct customers, BTWholesale, TalkTalk, Sky, etc. Ofcom would string them up if they weren't.
You have no right to know what is planned and no right to information Openreach give their customers in confidence. You have the right to be provided the service your provider contracted to provide you.
Sadly we are not their direct customers, they probably have provided information to the CP's. But the CP's are witholding the information either due to NDA or their own doing.
I agree with you its wrong but this is the situation we have now with the current market structure.
It's not wrong at all. Virgin Media don't give updates on all their trials to the customer base either.
It's none of your, or my, business what Openreach are doing with regards to G.inp. If our services are working as contracted we've no recourse.
Should Virgin Media be notifying customers when they test new CMTS, channel plans, modulation schemes, bonding groups, etc?
I could happily tell the people in this local area how many upstream and downstream channels are in use, the equipment that sources those downstream channels and receives those upstream channels, when the architecture is planned to go full CCAP, the local network frequency ranges, subsplit, and how many homes passed per node the network was built with.
Do normal customers have a 'right' to know this? Does it matter as long as they are receiving the service as advertised?
Someone has just now kindly confirmed there is no openreach enforced NDA, meaning this is a CP decision to keep it quiet.
Does anyone on an ECI cabinet still have G.INP or has anyone actually had it turned back on yet?yes, 2 people have kept G.INP on an ECI cab on MDWS (https://www.mydslwebstats.co.uk/HG612-MultUsersLivei.htm?UO=14)
If not do any of the guru's on here know if (when) openreach are intending to get the issues some had sorted out?
I had no issues at all with G.INP on my ECI cabinet and ZyXEL SBG3300-N, I actually managed to gain a fair bit of download speed when it was on.
2017 or later probably. Best bet is to not expect it sooner, you will only be disappointed.
General G.INP questions on a fairly old thread:
I am only approx. 4 weeks on VDSL after migrating from ADSL2+, Plusnet 38/2 package.
I am definately on a Huawei FTTC cabinet, no reason to believe that G.INP is not enabled at the cabinet.
A good line, achieving practically DS profile speed, fast path DS & US, G.INP not active.
I do get DS ES errors but the daily rate is at the bottom end of the "orange" ILQ range, (speed profile) DLM not believed likely to intervene under current line conditions, should maintain fast path.
I appear to be on 6dB. target DS SNRM, ie., not yet part of the 3dB. migration process.
I easily maintained 3dB. DS SNRM when on ADSL2+ (not the same I know)
I am running DSLStats on a RPi 24/7 to MDWS so in a position to see what's happening.
My questions are:
Assuming that G.INP is available on my cabinet is it ever likely to be applied to my line, do I need it, is it applied anyway by default ?
There is a school of thought that it takes approx. 6 weeks on a new VDSL installation for G.INP to be applied, is there any factual proof of this ?
I have diligently read the excellent DLM articles produced by kitz, can not find any reference to the criteria for activation of G.INP, these documents possibly pre-dated G.INP roll out.
Any information appreciated.
in your case appears to contradict normal theories that G.Inp is only applied if requiredNo idea when this became "normal theory" but the last official word I heard from OpenReach was it's applied by default on the downstream when supported. It would be madness not to enable it by default, there's not a single line in the country it won't improve.
Downstreamhttp://www.kitz.co.uk/adsl/ginp-retransmission.htm
Initially, low interleaving is enabled by default on all retransmission lines. Once DLM has positively identified that the modem supports retransmission then retransmission is enabled. This happens after a few days. If the low level of retransmission is not good enough to correct all errors then the high level is selected by DLM. If the line remains unstable and cannot be adequately managed by DLM with retransmission profile then Interleaving is applied as normal.
Assuming something not broken openreach side
Surprised I don't have G.INP yet.
Did you get a DLM reset or changed to another ISP
Have you looked on MDWS all users currently online have never seen so many Huawei users who had G.INP and now inactive in ORANGE, I don't know if they moved ISP provider or had a DLM reset but trend point's at 1st and 2nd week of July ???
Have you looked on MDWS all users currently online have never seen so many Huawei users who had G.INP and now inactive in ORANGE, I don't know if they moved ISP provider or had a DLM reset but trend point's at 1st and 2nd week of July ???I checked on the MDWS "all active users" listing this morning:
I'am sure I checked this less than a week ago and at that time I was the only active, Huawei cab member who had never been G.Inp active.Definitely not, I've been in that bracket since February.
From memory, at that time there were no G.Inp inactive (orange) listings, certainly not 9.You must have been looking at the list wrong as there was definitely a similar figure a few weeks ago.
OK, I could well be wrong, I quite often am !Yes
Are we all talking about Huawei FTTC cabinet, active users only stat's excluding ECI cab users ?
I'm 'bkehoe' on mydslwebstats and moved home just over 2 weeks ago, still on Huawei cabinet and 8926. Spent 2 days on fastpath with 77mbit sync downstream but quite a few ES. Interleaved for over 2 weeks now with no sign of G.INP being enabled or any reduction in target SNR from 6dB. Approx 250m from cabinet.