Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 2 [3]

Author Topic: Openreach Deploy Low Level Error Correction on New FTTC Lines  (Read 4069 times)

NewtronStar

  • Kitizen
  • ****
  • Posts: 4812
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #30 on: April 15, 2018, 09:21:36 PM »

Well done EJS you found my post that was when I using vodafone after a DLM reset yet still after a EE reset/change of ISP showed the same results no fastpath just very low level interleaving depths

Code: [Select]
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    0
Last initialization procedure status:   0
Max:    Upstream rate = 6225 Kbps, Downstream rate = 43970 Kbps
Bearer: 0, Upstream rate = 6225 Kbps, Downstream rate = 39999 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):        4.4             6.0
Attn(dB):        24.7            0.0
Pwr(dBm):        11.2           -0.9

                        VDSL2 framing
                        Bearer 0
MSGc:           -6              26
B:              162             191
M:              1               1
T:              0               39
R:              8               12
S:              0.1295          0.9790
L:              10564           1667
D:              4               1
I:              171             102
N:              171             204
Q:              4               0
V:              0               0
RxQueue:                136             0
TxQueue:                34              0
G.INP Framing:          18              0
G.INP lookback:         31              0
RRC bits:               0               24
                        Bearer 1
MSGc:           90              -6
B:              0               0
M:              2               0
T:              2               0
R:              16              0
S:              10.6667         0.0000
L:              24              0
D:              1               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               984658
OHFErr:         519             426
RS:             1873995080              2834055
RSCorr:         70694630                761
RSUnCorr:       0               0
                        Bearer 1
OHF:            55934007                0
OHFErr:         29              0
RS:             335603673               0
RSCorr:         1849            0
RSUnCorr:       93              0

                        Retransmit Counters
rtx_tx:         7470033         0
rtx_c:          509006          0
rtx_uc:         55948           0

                        G.INP Counters
LEFTRS:         29              0
minEFTR:        39995           0
errFreeBits:    548019650               0

                        Bearer 0
HEC:            0               0
OCD:            0               0
LCD:            0               0
Total Cells:    384193351               0
Data Cells:     190354426               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:             34              308
SES:            11              0
UAS:            18              18
AS:             898586

                        Bearer 0
INP:            52.00           0.00
INPRein:        1.00            0.00
delay:          0               0
PER:            0.00            9.58
OR:             0.01            26.71
AgR:            40122.38        6251.34

                        Bearer 1
INP:            2.50            0.00
INPRein:        2.50            0.00
delay:          0               0
PER:            16.06           0.01
OR:             47.81           0.01
AgR:            47.81   0.01

Bitswap:        509253/509347           4215/4228

Total time = 10 days 9 hours 36 min 49 sec
FEC:            70694630                761
CRC:            519             426
ES:             34              308
SES:            11              0
UAS:            18              18
LOS:            0               0
LOF:            0               0
LOM:            0               0
Latest 15 minutes time = 6 min 49 sec
FEC:            21548           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:            71583           0
CRC:            0               0
ES:             0               0
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Latest 1 day time = 9 hours 36 min 49 sec
FEC:            1810601         68
CRC:            0               33
ES:             0               22
SES:            0               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Previous 1 day time = 24 hours 0 sec
FEC:            7406605         42
CRC:            304             28
ES:             10              24
SES:            7               0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Since Link time = 10 days 9 hours 36 min 29 sec
FEC:            70694630                761
CRC:            519             426
ES:             34              308
SES:            11              0
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
 >
« Last Edit: April 15, 2018, 09:27:13 PM by NewtronStar »
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 31602
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #31 on: April 15, 2018, 11:36:27 PM »

Quote
Generally speaking a proper rollout would be using the latest chipset available (ECI did not, was V41s at time of rollout),

I agree that the V41's would have been a far better choice.  Why they didn't deploy V41's I've no idea other than cost.    Back in 2012 on face value the ECI's were seen as the better option.   They were more compact and took up less room on the pavement.  BT were not the only ISP's who during the same period rolled out VDSL using ECI M41's.  It was also at the same time that there was concern over the use of Huawei DSLAMs/MSANs and possible backdoors.



However I do need to point out a couple of things -
  • Openreach use VTU-C64P linecards which contain the latest Vinax V3 chipset.
  • The VTU-C64s are capable of both G.INP and Vectoring.


People often vastly under estimate how very important the line card is.   

  • The DSLAM's main purpose is a Multiplexor (MUX).
  • The DSLAM may contain other componets such as Splitter cards, Fans, power, switches... and of course line cards.
  • The Linecard does all the DMT stuff.
  • The linecard is multiple modems on one large circuit board.


G.INP is done by the transceiver.

  • ATU = ADSL Transceiver Unit.  VTU = VDSL Transceiver Unit.
  • ATU-R = Remote ATU = DSL modem.   
  • ATU-C = Central Office ATU = Transceiver in the DSLAM  = linecard.


I've never been able to understand why the M41's can't do upstream G.INP when all the indications are that it should be able to.  Downstream G.INP is done by the ATU-C.  Upstream G.INP is done by the ATU-R.   But I've been through that debate before years ago and I'm sure Openreach isn't telling everything as I've long suspected the issue is with the ECI modems rather than the DSLAM.

Openreach thought they were home and dry with G.INP on the Huawei's - until roll out and they suddenly realised there were a hell of a lot more ECI modems in use with Huawei cabs than what they thought.    G.INP mk2 is where they had to turn off upstream G.INP on the Huawei's because of all the Lantiq VRX268 based modems in use.   
I still suspect if it wasn't for those Lantiq VRX268 modems then they may not have had to disable upstream G.INP for the ECI's either.   
Those of us on ECI cabs using BCM based devices had no issues with G.INP.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 31602
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #32 on: April 15, 2018, 11:44:30 PM »

... and last but not least..  You do realise what the issue with the M41's is?   
There was no room on the backplane to add in a vectoring module.

For those who don't understand what I mean its like the equivalent of say sticking a sound card into a PCI slot into a PC, but if the motherboard on your PC only has 2 PCI slots and you already have 1x Network card &  1x modem card in it, then there's no room to add the sound card.

At one time ECI had detailed specs on their site of the M41 & V41 which has now gone, but from memory the 2 DSLAMs were almost identical except they jiggled things around a bit to make room.   Its a long time ago since I saw the photo's and my memory could be wrong but they seemed to have turned some of the internal parts sideways on the left to make more space to add in another slot which could take the Vectoring Engine card.

The Huawei's have a spare slot so that inserting a Vectoring engine module is no big deal.  Bang in the Vectoring card, configure it and away you go.

The ECI-M41's could actually do Linecard based vectoring because of the VTU-C64's,  but line card vectoring isn't as efficient as system level because you can end up with wasted ports on the linecard.    The Vectoring engine card which is slotted in controls vectoring on all the ports.

There's a discussion here on System Level Vectoring -v- Linecard (board) Vectoring.
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5436
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #33 on: April 15, 2018, 11:50:04 PM »

given johns reply your thoery of it been the eci modems seems sound

but it seems openreach and the CPs between them didnt have the desire to recall/deactivate them to solve the problem.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 31602
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #34 on: April 16, 2018, 12:10:19 AM »

Quote
if openreach did one modem recall why cant they do another for the ECI modems.

I agree.   TBH I wish they would just ditch them.   
Three years ago there were a heck of a lot of ECI modems out there.   These days comparatively few as most ISP's now issue all-in-one boxes. 
Unfortunately there is no record who still has ECI's, so you could end up with some people who suddenly find their broadband connection no longer works.  :(
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5436
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #35 on: April 16, 2018, 08:46:22 AM »

I understand that, and I did think about that when I posted.

The way I guess to approach it would be for the CP's to send out their device when someone loses sync on the change.  As well as issuing it to those who had an engineer install prior to the date the devices stopped been issued.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

Ixel

  • Kitizen
  • ****
  • Posts: 1072
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #36 on: April 16, 2018, 11:18:56 AM »

I don't think we actually know what this "low level error correction" is yet.

@NewtronStar
INP 0 in http://forum.kitz.co.uk/index.php/topic,19234.msg341901.html#msg341901

Interesting.

Code: [Select]
R:              10              16
S:              0.2099          1.0437
L:              9680            1947
D:              19              8

While the interleaving depth of 19 and 8 is unusual for INP 0, there's a distinct thing I notice which might be 'low level error correction'. Similar to something I did when I was playing with the DSL-AC68U a long time ago.

Reed solomon coding (R) is 10 on the downstream, it's usually 0 unless interleaved, G.INP or if using a Lantiq/Infineon chipset modem. But, the big difference I feel is that the delay (look at the linked post's stats) is 1ms, not 0ms. If I recall correctly it's normally 0ms on fastpath, not 1ms. If this is truly what 'low level error correction' is then it's a welcome move, as even 2ms made a noticeable difference to errors when I experimented with the DSL-AC68U a long time ago.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 1761
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #37 on: April 16, 2018, 07:08:25 PM »

However I do need to point out a couple of things -
  • Openreach use VTU-C64P linecards which contain the latest Vinax V3 chipset.
Are we certain about this?

I still suspect if it wasn't for those Lantiq VRX268 modems then they may not have had to disable upstream G.INP for the ECI's either.   

Sorry but I think you've got this backwards. The VRX268 modems are perfectly capable of doing upstream G.INP with sufficiently recent firmware. The line cards in the ECI DSLAMs may not be. It's only when you get to the Lantiq/Intel Vinax FTTdp chipset (later than the Vinax v3) that the Lantiq/Intel PDFs start explicitly talking about both downstream and upstream retransmission.
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 31602
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #38 on: April 16, 2018, 08:09:22 PM »

Think it was BS who confirmed that they were V3's several months ago from OR documentation.

Quote
It's only when you get to the Lantiq/Intel Vinax FTTdp chipset

G.993.4 G.998.4 being the earlier technology is automatically encompassed in G.994.5 G.993.5..   but here you go V3 Key Standards


Code: [Select]
•VDSL2 (G.993.2)
•ADSL/2/2+ (G.992.1, G.992.3, G.992.5)
•G.HS, G.PLOAM (G.994.1, G.997.1)
•EFM (IEEE 802.3 ah)
•SELT & MELT - G.LT (G.996.2)
•Retransmission - G.INP (G.998.4)
•G.BOND (G.998.1/2)
•G.VECTOR (G.993.5)

I'm not certain, but it may possibly be the addition of  'P' to VTU-C64 which externally indicates the V3 chipset.

---
fixed typos
« Last Edit: April 16, 2018, 10:47:26 PM by kitz »
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

ejs

  • Kitizen
  • ****
  • Posts: 1761
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #39 on: April 16, 2018, 08:58:17 PM »

According to NICC ND1436, and perhaps also that Openreach ECI NGAE 8.00.3.2 release notes document, there are two different ECI line cards, only identified as v2 and v3. Nothing mentions anything about the chipset in either type of ECI line card. Coincidentally, there exists the Lantiq vinax v2 and vinax v3 chipsets. I don't think there's anything to confirm that the ECI v3 line card contains Vinax v3 chips.

Quote
G.993.4 being the earlier technology is automatically encompassed in G.994.5
This doesn't seem to make any sense?

Yes I know the Lantiq vinax v2 and v3 PDFs just say G.998.4 and/or "retransmission" - they don't specify downstream or upstream. Yet with the later FTTdp chipset, they are explicitly stating upstream and downstream retransmission. Unfortunately I can no longer find any URLs for either the Lantiq FTTdp white paper or a short Intel FTTdp PDF I found.

VTU-C64P - the "64P" could just as easily indicate 64 ports!
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 31602
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #40 on: April 16, 2018, 10:43:20 PM »

Quote
This doesn't seem to make any sense?

Typo's - fingers not working - corrected the numbers
G.inp is always recommended with g.vector.

Quote
they don't specify downstream or upstream

Do any other manufacturers ever specify upstream and downstream when they state G.998.4?

So many questions
Why is it that the VRX-268 HH5A, TD-W9980, and ECI modems all have had issues with Upstream G.INP?
Why did Openreach have to halt G.INP Mk1 on the Huawei cabs and then turn off upstream by default because of the VRX-268 HH5A & ECI modem.
Why does the VRX268 chipset not specify G.993.4 as an actual standard when it does for all the other standards and just says Re-transmission rather than the full standard name.
Why won't Openreach update the ECI modem software to at least work with the Huaweis.
Come to that, even if there are some non v3 line-cards why not swap those out - it would be relatively cheap to do so rather than fannying around for 3yrs   

From memory downstream only was a limitation of adsl2(+)
« Last Edit: April 17, 2018, 06:23:31 PM by kitz »
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5436
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #41 on: April 17, 2018, 02:44:47 PM »

My speculation is that there is an issue preventing remote firmware upgrades on the ECI units, or there is no support contract meaning in turn openreach cannot request a new firmware for these modems.

Which brings me to another point.

A while back openreach said both the ECI and HG612 modems are EOL for support, so basically they will no longer support these devices, I Cannot remember the exact date but we have now passed that date.

So given openreach no longer support these devices, they should actually be within right to just say to the CPs "tough luck they cannot sync, send your customer a device that can, we only support devices on our MCT list".

It just seems openreach are unwilling to enforce anything on the modem side, I dont know if this is due to threats from CP's, ofcom or something else, combined with the lack of willingness to swap out cabinet hardware we have this situation where they trying to get a firmware to work on a chipset that was possibly not designed to support a feature and across a wide range of modems creating a compatibility nightmare.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

ejs

  • Kitizen
  • ****
  • Posts: 1761
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #42 on: April 17, 2018, 07:42:40 PM »

G.993.4 G.998.4 being the earlier technology is automatically encompassed in G.994.5 G.993.5
Even with the correct numbers, it's still nonsense! Vectoring (G.993.5) and retransmission (G.998.4, G.INP) have nothing much to do with each other, support for one does not imply support for the other. Also the first G.993.5 PDF (2010/04) was earlier than the first G.998.4 PDF (2010/06).

Why is it that the VRX-268 HH5A, TD-W9980, and ECI modems all have had issues with Upstream G.INP?
Old firmware that didn't do upstream G.INP, and/or it was not enabled by default on the modem.

Why did Openreach have to halt G.INP Mk1 on the Huawei cabs and then turn off upstream by default because of the VRX-268 HH5A & ECI modem.
I suppose it would take a long time to get firmware updates for those devices built, tested and then installed into the live devices.

Why does the VRX268 chipset not specify G.998.4 as an actual standard when it does for all the other standards and just says Re-transmission rather than the full standard name.
Maybe because that PDF was first written in 2009, pre-dating the G.998.4 standard being approved.

Why won't Openreach update the ECI modem software to at least work with the Huaweis.
Good question, but perhaps it's like asking why TP-Link won't release any more firmware updates for the 9980 - they've decided not to.

Come to that, even if there are some non v3 line-cards why not swap those out - it would be relatively cheap to do so rather than fannying around for 3yrs   
Cheaper to do nothing for 3 years.
Logged

HeroNero

  • Just arrived
  • *
  • Posts: 1
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #43 on: April 30, 2018, 10:27:16 PM »

I may be completely off the mark here but could say, if BT enabled this yesterday on a FTTC line that may have electrical interference but otherwise was performing fine until now would it adversely impact the connection?
We have an MPLS connection from a different provider running over a BT line and after a couple of suspicious looking admin-resets yesterday at 7.30am then 10pm the connection has all but died on us. Not in terms of packet loss, that's fine, but there seems to be something impacted the quality of packets if that makes sense. We deployed a replacement router today and it hasn't fixed the issue. It did give us a chance to check the vdsl controller on the router and saw an immediate high amount of FEC and Reed-Solomon errors in the thousands. Googling these brought me to this forum and the linked article and hence this post. Is it now trying to be too clever with the errors on the line and messing it up?
When I say the connection is fine in terms of successful packets, we have no loss in packets to the site but all real traffic is failing and the site is effectively down. We can SSH to the router and sometimes you get on for a few seconds and it kicks you out, other times it fails with incorrect mac received or SSH errors. Same goes for VNC connections to clients there, connects but kicks out almost immediately after establish connection.
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 23944
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #44 on: April 30, 2018, 11:32:45 PM »

Welcome to the Kitz forum.  :)

. . . if BT enabled this yesterday on a FTTC line that may have electrical interference but otherwise was performing fine until now would it adversely impact the connection?

An interesting question. I would not go as far as saying "yes" to "would it adversely impact the connection?" but would give a guarded "yes" to "could it . . ." (or "might it . . .").

Quote
We have an MPLS connection from a different provider running over a BT line and after a couple of suspicious looking admin-resets yesterday at 7.30am then 10pm the connection has all but died on us.

Would you be able to provide a little more detail on the infrastructure, please? (Specifically the CPE being used.)
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.
Pages: 1 2 [3]