Kitz Forum

Announcements => News Articles => Topic started by: Bowdon on February 28, 2018, 10:29:04 AM

Title: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Bowdon on February 28, 2018, 10:29:04 AM
https://www.ispreview.co.uk/index.php/2018/02/openreach-deploy-low-level-error-correction-new-fttc-lines.html (https://www.ispreview.co.uk/index.php/2018/02/openreach-deploy-low-level-error-correction-new-fttc-lines.html)

Quote
After last year’s Proof of Concept (PoC) test Openreach has now decided to start applying “low level error correction” on all new UK Fibre-to-the-Cabinet (FTTC / VDSL2) superfast broadband lines, which they hope will result in fewer fault reports being made by customers during the initial provision phase.

At present the Dynamic Line Management (DLM) system is used to control the speed and stability of related lines, although after first provision (new installation) it usually takes about 48 hours before this is introduced (your speed may go up or down depending upon how stable DLM thinks the line is). The error correction involved, if enabled, may also increase the line’s latency.

I liked what I was reading here until the bit about increased latency. Hopefully it won't be too much.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Ixel on February 28, 2018, 10:35:19 AM
This is worrying, I hope they aren't meaning that they will apply traditional interleaving to all lines instead of fastpath.

Given the 'low level error correction' term, I was assuming it might be reed solomon coding on the downstream for fastpath (which the upstream already has). The only time I've seen reed solomon coding on fastpath is when I've used a modem with a Lantiq/Infineon chipset. If it is traditional interleaving then I hope it's something like a few milliseconds delay instead of 8ms. Assuming it's ready by the 6th March I will be able to see what it is, since I have a new line being activated on the 6th. Also if it is reed solomon coding then the downstream sync rate may be slightly lower from now on.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ktz392837 on February 28, 2018, 10:54:24 AM
How about getting Ginp working on ECI cabinets before making these changes?  Sometimes I just don't understand surely Ginp would be much more beneficial than doing this?  Have their multiple year trial period for Ginp included this new change?  Unbelievable.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: j0hn on February 28, 2018, 11:32:56 AM
This doesn't need trialled. They already do it on the upstream by default.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Deathstar on February 28, 2018, 11:45:46 AM
Maybe it will be applied as default to begin with, then backed off as the DLM learns how the line performs?

If that is the process, it makes perfect sense to me and probably some common sense too.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Ixel on February 28, 2018, 11:48:14 AM
Maybe it will be applied as default to begin with, then backed off as the DLM learns how the line performs?

If that is the process, it makes perfect sense to me and probably some common sense too.

That's what MrSaffron said on TBB forum when I posted about it on there.

http://forums.thinkbroadband.com/fibre/t/4585147-re-openreach-deploy-low-level-error-correction-new-fttc-l.html
Quote
It just covers the period before the DLM has decided what to do, i.e. that period when its just collecting its initial dataset to decide what to do, so if a line is totally clean and error free within limits then returning a line to no error protection seems possible.

DLM usually makes initial decision with 48 to 72 hours
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ktz392837 on February 28, 2018, 12:58:18 PM
If DLM can decide to switch on / off this error correction why can't it be programmed to try ginp out on eci cabs? 

Eci ginp has been working for some users for over a year probably longer so why does eci ginp yet again get ignored?

Re: trialing, it irks me that the reason ginp is delayed is due to testing but this can just be added without what appears little concern for compatibility with the user base  - wasnt this the reason Ginp was delayed some modems did not work correctly even after a decent test period?
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: j0hn on February 28, 2018, 01:33:18 PM
Quote
the reason ginp is delayed is due to testing but this can just be added without what appears little concern for compatibility with the user base

You can't compare the 2.
Openreach are simply adding a liitle FEC overhead by default. It doesn't need testing.

Quote
If DLM can decide to switch on / off this error correction why can't it be programmed to try ginp out on eci cabs?

It cant just be enabled and reversed if it doesn't work.
Last time round applying G.INP caused all the White Openreach ECI modems to lose sync.
It caused other modems to considerably lower sync speeds and add huge latency.

G.INP is a relatively new tech, which ECI had problems with.
They had to completely reverse the rollout because of numerous problems with numerous modems.
They've had to back to ECI a number of times after abandoning roll-outs and trials.

I don't blame Openreach for taking their time with G.INP and doing extensive testing.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ktz392837 on February 28, 2018, 03:38:47 PM
You can't compare the 2.
Openreach are simply adding a liitle FEC overhead by default. It doesn't need testing.
Yes I guess it is not quite comparing like with like but why does it always seem there is one rule for some changes (eg will not make ginp changes for months/years as they don't make changes at this time of year or need further testing) but this change seems to go through with little fuss?

I guess it doesn't need testing just as they thought the eci ginp didn't need better testing.  They can't have it both ways.

They are applying a change for everyone, the risk of a problem from the change may be low but the impact if there is a problem would be high.  To me this would mean do some testing.
Quote
I don't blame Openreach for taking their time with G.INP and doing extensive testing.
I do think they deserve a damn good portion of blame as they should have done it correctly in the first place.

Edit: I do not hate OR as it happens I had three separate engineers solve a problem with my line recently and I am well pleased with the final result but getting there was a chore due to OR rules, poor communication and they haven't followed through with a permanent fix as promised so I suspect I may have problems in the future.  Things are getting better in some areas (at least in my recent experience) but further improvement is needed.  Ofcom are not helping in my opinion.

Anyway I am keeping my fingers crossed we may see positive eci ginp news in the coming month.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: j0hn on February 28, 2018, 03:53:53 PM
They did it right in the 1st place. It's the vendors (ECI) kit that had issues.

Quote
They are applying a change for everyone, the risk of a problem from the change may be low but the impact if there is a problem would be high.  To me this would mean do some testing.

There is no risk of problems. They are simply applying a small amount of FEC. You just can't compare the 2.
They don't run a test everytime DLM applies interleaving+INP+FEC to a line. No need to test something basic like FEC.

I've seen a couple lines with downstream fastpath and a small amount of FEC in the past. So it's not something they haven't done before.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ktz392837 on February 28, 2018, 04:21:21 PM
They did it right in the 1st place. It's the vendors (ECI) kit that had issues.

I may concede somewhat on this new low level error default but regarding the first round of eci ginp it should have been never rolled out to the wider audience as they certainly did a limited rollout and found no problems that is why they rolled it out to everyone.

Didn't it even work poorly on some BT supplied modems which means the so called testing possibly never happened.

OR can blame ECI and ECI can blame someone else and eventually it is the fault of the apprentice tea maker who didn't make the tea correctly this does not work for me it is OR responsibility and fault.  Why else do they say they are testing and trialing changes.

I look forward to replies but to bring the discussion to the end I will not post again as we both have different opinions I guess in this regarded.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: kitz on February 28, 2018, 04:33:18 PM
I'm sure I pointed this out a month or so ago in another post whilst it was in the trial stage and said I wasnt sure if I liked the sound of this.   
It wasn't clear what they meant by Low Level Error Correction but at that time I assumed it was INP3 rather than just FEC without interleaving like what they currently use on the upstream.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Ixel on February 28, 2018, 04:40:33 PM
I'm sure I pointed this out a month or so ago in another post whilst it was in the trial stage and said I wasnt sure if I liked the sound of this.   
It wasn't clear what they meant by Low Level Error Correction but at that time I assumed it was INP3 rather than just FEC without interleaving like what they currently use on the upstream.

Indeed, I really hope it's not INP 3 delay 8ms. I'm against a connection using interleaving by default on provision because if there is a problem then it's going to be harder to report a problem. Fastpath is useful for highlighting a problem, if that makes sense.

Assuming the deployment is completed by March 6th, I will know what's different about my new connection hopefully (at the new house).
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: kitz on February 28, 2018, 04:43:28 PM
I thought I'd seen something about it, just a bit longer ago than I remembered:-

btw whilst at the OR site also saw this...  which Im not sure if I like the look of.

https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga03817.do

Could be an end to the Open Profile and straight to Interleave for all.   Not so much of a problem for Huawei's who then move on to G.INP.
However ECI cabs in some respects are currently immune to the Interleave by default.  It can be a PITA getting rid of INP as it is, so I can forsee that a lot of lines that normally would run quite well on ILQ amber without INP, having problems getting INP removed.

I'm not sure whether I do like it, because if a new line was behaving pretty badly DLM could (and would) immediately over-ride open profile.   Supposedly its because of complaints during the Open phase..  but seriously???  Most of the large ISPs resort to telling the EU it will settle in 10 days and still use the 'training phase' even though its not strictly true.   The line is at most on Open for 48hrs so someone would have to be pretty quick off the mark to think that an engineer would be there before DLM has kicked in on its own anyhow.  :-\

Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ejs on February 28, 2018, 06:12:52 PM
I'd like to see a full set of VDSL2 stats from an initial provision with whatever this new profile is before commenting much further on it, but anyway:

From all the line profile definitions I've seen, they don't actually contain any specific value for the FEC level or interleaving depth, the profile contains a minimum INP value and a maximum delay value, and then the specific framing parameters like D and R are worked out to meet those constraints.

I assumed that the small amount of FEC with no interleaving might have been there to optimize the bandwidth from the coding gain. I'm not sure how far a small amount of FEC with zero interleaving and INP would go at reducing the faults reported that end up being counted as FTTC (Fibre to the Cabinet), Self-Install, ELFs (Early Life Failures).
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Ixel on February 28, 2018, 07:11:03 PM
I'd like to see a full set of VDSL2 stats from an initial provision with whatever this new profile is before commenting much further on it, but anyway:

From all the line profile definitions I've seen, they don't actually contain any specific value for the FEC level or interleaving depth, the profile contains a minimum INP value and a maximum delay value, and then the specific framing parameters like D and R are worked out to meet those constraints.

I assumed that the small amount of FEC with no interleaving might have been there to optimize the bandwidth from the coding gain. I'm not sure how far a small amount of FEC with zero interleaving and INP would go at reducing the faults reported that end up being counted as FTTC (Fibre to the Cabinet), Self-Install, ELFs (Early Life Failures).

I'll post mine from the new line on the 6th, hopefully it will be done by then and also easy to notice the difference.

Reed solomon coding (R: or 'a small amount of FEC with zero interleaving') I'm pretty sure actually reduces the attainable sync rate by a small amount, since it needs the overhead to perform a small amount of error correction. As such I don't feel it's something that optimises the bandwidth (assuming you mean it increases the attainable sync rate, apologies if I misunderstood what you meant.

Time will tell, hopefully by the 6th it will be deployed and my line will get this 'low level error correction' initially for the first few days.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ejs on February 28, 2018, 07:46:54 PM
I'm pretty sure actually reduces the attainable sync rate by a small amount, since it needs the overhead to perform a small amount of error correction. As such I don't feel it's something that optimises the bandwidth

I keep trying to explain this coding gain thing but no-one seems to take the slightest bit of interest. I'll try again anyway.

I really don't think it's the case that say the modem connects at 62Mb fast path with no error correction, and then if you add 5% FEC overheads, you end up at 95% of 62Mb = 58.90Mb.

Instead, the modem connects at the best speed it can manage subject to meeting the required bit error rate (1 in 107 bits). If you add error correction, that will be factored into working out what speed the modem can connect at. That 1 in 107 error rate will be after any FEC has been applied. Yes the FEC data does use some of the bandwidth, but that's not its only effect.

The trouble is that the R value in bytes can be seen in the stats and used to calculate the percentage of bandwidth being used to carry the FEC data, but the effect of the coding gain is not really visible. You could work out the "gross data rate" and see if it's higher than the fast path no error correction rate.

I get more bandwidth on ADSL2 with FEC+interleaving than without, and that's without even working out the "gross data rate" including the FEC data. I don't think VDSL2 should be fundamentally different regarding what's possible, although in practice I think it tends to be operated differently, so FTTC tends to be slower with the levels of FEC+interleaving it uses than without. That huge max attainable rate you see with FEC+interleaving may be what bandwidth would be possible if the FEC+interleaving levels were being used to optimize bandwidth rather than provide INP.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Ixel on February 28, 2018, 08:20:29 PM
I keep trying to explain this coding gain thing but no-one seems to take the slightest bit of interest. I'll try again anyway.

I really don't think it's the case that say the modem connects at 62Mb fast path with no error correction, and then if you add 5% FEC overheads, you end up at 95% of 62Mb = 58.90Mb.

Instead, the modem connects at the best speed it can manage subject to meeting the required bit error rate (1 in 107 bits). If you add error correction, that will be factored into working out what speed the modem can connect at. That 1 in 107 error rate will be after any FEC has been applied. Yes the FEC data does use some of the bandwidth, but that's not its only effect.

The trouble is that the R value in bytes can be seen in the stats and used to calculate the percentage of bandwidth being used to carry the FEC data, but the effect of the coding gain is not really visible. You could work out the "gross data rate" and see if it's higher than the fast path no error correction rate.

I get more bandwidth on ADSL2 with FEC+interleaving than without, and that's without even working out the "gross data rate" including the FEC data. I don't think VDSL2 should be fundamentally different regarding what's possible, although in practice I think it tends to be operated differently, so FTTC tends to be slower with the levels of FEC+interleaving it uses than without. That huge max attainable rate you see with FEC+interleaving may be what bandwidth would be possible if the FEC+interleaving levels were being used to optimize bandwidth rather than provide INP.

I see, what you say makes sense. Hopefully I'll have the opportunity to see DLM initially use it (assuming it is actually what Openreach define as 'low level error correction') and then take it away if my new connection is performing adequately after 48-72 hours. Finally one more thing, it's not that I ignored what you said intentionally regarding what you've said about coding gain and the above, I've just not seen it before. Thanks for the explanation though, what you say does make sense regarding the bit error rate and such. Hopefully this can be compared once my new line is live on March 6th and then a few days later if DLM decides to remove the low level error correction after the initial 48-72 hours, assuming it's reed solomon coding that is.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ejs on February 28, 2018, 08:56:00 PM
If I'm understanding the ITU-T G.993.2 document correctly, from section 12.3.5, then the R value for the upstream comes from the DSLAM (the VTU-O, in the O-PMS message), and the R value for the downstream comes from the modem (the VTU-R, in the R-PMS message). This is consistent with Broadcom modems putting R=0 on fastpath downstream, and Lantiq modems putting say R=16 on fastpath downstream, and presumably the R value used on the upstream not changing between different modems (because the DSLAM controls R for the upstream).

I've not yet spotted a way for the DSLAM to directly set the R value for the downstream, but the ITU-T documents are vast and complex so I may just not have found it yet.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: kitz on February 28, 2018, 09:27:28 PM
I think it may be a moot point anyhow.   
Even though a small amount of RS encoding may be applied on the upstream, the DLM profile is still classed as "Error Protection Off"

That's why I think its more likely to be INP3.   This is similar to what currently happens on Huawei cabs in that after a DLM reset it will go INP3 then G.INP.
Unfortunately at the moment there is no such option for ECI cabs..  and we all know how hard it can sometimes be to clear INP3 especially if your ISP doesnt use Speed profile.

It also seems to make a bit of a mockery of the recent DLM reset option.    If someone wants to reset DLM to get rid of INP, then the reset will just put it back into INP=3  ???
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ejs on March 01, 2018, 10:31:09 AM
Yes I was explaining why I think it's more likely to be the "Interleaving Low" profile (INP=3), although @john who appears to be in the know and has probably read the full briefing says it's just FEC.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Ixel on March 01, 2018, 10:46:01 AM
I really hope it's not 'traditional interleaving low', as it's an unfortunate but smart way to mask possible underlying problems unless they become more serious.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Ixel on March 07, 2018, 08:53:53 AM
New line is fastpath, but I don't know if 'R' (reed solomon coding) is now forced on the downstream or whether this could be because the change hasn't been rolled out here yet.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ejs on April 14, 2018, 03:28:48 PM
NGA011/18 Proof of Concept to apply low level error protection on new 80/20 lines
https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga01118.do

The latest briefing seems to imply that previously this wasn't for 80/20 lines.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Ixel on April 14, 2018, 03:31:33 PM
That would explain why I never had any form of error correction on my new second line.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Chrysalis on April 14, 2018, 10:53:32 PM
You can't compare the 2.
Openreach are simply adding a liitle FEC overhead by default. It doesn't need testing.

It cant just be enabled and reversed if it doesn't work.
Last time round applying G.INP caused all the White Openreach ECI modems to lose sync.
It caused other modems to considerably lower sync speeds and add huge latency.

G.INP is a relatively new tech, which ECI had problems with.
They had to completely reverse the rollout because of numerous problems with numerous modems.
They've had to back to ECI a number of times after abandoning roll-outs and trials.

I don't blame Openreach for taking their time with G.INP and doing extensive testing.

Just want to say I think g.inp is "not" a new tech, its been used by broadcom on some adsl providers for about a decade now.

Now what do I think about this new default profile and the bodged g.inp rollout?

On the new profile, I think its ok providing there is still a fast path profile for lines with good behaviour to switch to.  For some of us its not just about the "bandwidth" but also the latency.  Although like kitz I am baffled as to why they even have decided to do this because problematic lines tend to be DLM'd within 48 hours and isp's have a script that fobs people off with "10 days training".  I expect this has came about for the same reason as ECI g.inp got rolled back, because CPs are trying to minimise support calls and they prefer to not have the calls at all instead of the fob off "10 days", probably so they can reduce the manning levels in their call centres to save some pennies.

On ECI g.inp I dont think openreach are blameless, especially as openreach modems have been identified as broken, these are not some 3rd party devices that openreach had no control over, they are "openreach issued" devices, to abandon a rollout because of your "own devices" is pretty shambolic, only highlights there was no forward thinking/planning by openreach during the vdsl2 rollout.  Generally speaking a proper rollout would be using the latest chipset available (ECI did not, was V41s at time of rollout), and some kind of forward planning, I think its not unreasonable to expect both vectoring and g.inp to have been part of rollout plans, especially as BT have been involved in vectoring trials.   Mistakes were clearly made as  the rollout clearly was done with a remit of "minimum cost".  I was also going to say they should have carried on issuing devices, and using a whitelist approved devices only, although given their own devices have caused problems we know that would not have solved this particular issue.

Now here is another question, does anyone remember the hg612 modem recall for overheating modems? if openreach did one modem recall why cant they do another for the ECI modems.  I expect the answer is it wont be approved because of ££.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Ronski on April 15, 2018, 08:22:27 AM
Now here is another question, does anyone remember the hg612 modem recall for overheating modems? if openreach did one modem recall why cant they do another for the ECI modems.  I expect the answer is it wont be approved because of ££.

Yes, one was a safety issue, so they had no choice to change them, the other, well they had a cheaper option.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Chrysalis on April 15, 2018, 03:39:33 PM
But it did prove it could be done.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: NewtronStar on April 15, 2018, 07:57:30 PM
Had that low level error correction applied on my line in Feb 2017, instead of going straight to fastpath INP was set to 3 DELAY 0 and a Interleaving Depth of 19 which I found very odd and posted these findings on the Kitz forum somewhere.

Anyway after 11 days on low level error correction G.INP raised it's head again, going from fastpath to being interleaved in a few days and then to G.INP is not the best solution.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ejs on April 15, 2018, 09:03:00 PM
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
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: NewtronStar 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
 >
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: kitz 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 -


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



G.INP is done by the transceiver. (https://en.wikipedia.org/wiki/Talk%3ADSL_modem#Debate_about_use_of_%22ATU-R%22,_%22ADSL_Transeiver_Unit%22_Vs._%22DSL_Modem%22,_%22DSL_Router%22)



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.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: kitz 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 (https://www.eetimes.com/document.asp?doc_id=1279706) on System Level Vectoring -v- Linecard (board) Vectoring.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Chrysalis 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.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: kitz 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.  :(
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Chrysalis 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.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Ixel 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.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ejs 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.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: kitz 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 (http://www.kitz.co.uk/adsl/images/Lantiq_Vinax_V3.pdf)


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
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ejs 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 (https://www.prnewswire.com/news-releases/300-mbps-vdsl-right-now---lantiq-introduces-new-fiber-to-the-distribution-point-solution-277568561.html) 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!
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: kitz 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(+)
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: Chrysalis 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.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: ejs 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.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: HeroNero 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.
Title: Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
Post by: burakkucat 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.)