Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
 
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 3252 times)

Bowdon

  • Content Team
  • Kitizen
  • *
  • Posts: 1547
Openreach Deploy Low Level Error Correction on New FTTC Lines
« 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

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.
Logged
BT Infinity 2 - Smart Hub 6 - ECI Cab

Ixel

  • Reg Member
  • ***
  • Posts: 957
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #1 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.
« Last Edit: February 28, 2018, 10:46:52 AM by Ixel »
Logged

ktz392837

  • Reg Member
  • ***
  • Posts: 350
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #2 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.
« Last Edit: February 28, 2018, 10:56:38 AM by ktz392837 »
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 1512
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #3 on: February 28, 2018, 11:32:56 AM »

This doesn't need trialled. They already do it on the upstream by default.
Logged
BT FTTC 55/10 ECI now Huawei cab
Zyxel VMG1312-B10A bridge mode with 1508 MTU + Asus RT-AC68U running Asuswrt-Merlin

Deathstar

  • Member
  • **
  • Posts: 96
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #4 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.
Logged

Ixel

  • Reg Member
  • ***
  • Posts: 957
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #5 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
Logged

ktz392837

  • Reg Member
  • ***
  • Posts: 350
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #6 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?
« Last Edit: February 28, 2018, 01:09:43 PM by ktz392837 »
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 1512
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #7 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.
Logged
BT FTTC 55/10 ECI now Huawei cab
Zyxel VMG1312-B10A bridge mode with 1508 MTU + Asus RT-AC68U running Asuswrt-Merlin

ktz392837

  • Reg Member
  • ***
  • Posts: 350
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #8 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.
« Last Edit: February 28, 2018, 04:02:54 PM by ktz392837 »
Logged

j0hn

  • Kitizen
  • ****
  • Posts: 1512
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #9 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.
Logged
BT FTTC 55/10 ECI now Huawei cab
Zyxel VMG1312-B10A bridge mode with 1508 MTU + Asus RT-AC68U running Asuswrt-Merlin

ktz392837

  • Reg Member
  • ***
  • Posts: 350
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #10 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.
« Last Edit: February 28, 2018, 04:24:55 PM by ktz392837 »
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 31194
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #11 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.
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

Ixel

  • Reg Member
  • ***
  • Posts: 957
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #12 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).
« Last Edit: February 28, 2018, 04:48:07 PM by Ixel »
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 31194
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #13 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.  :-\

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: 1666
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #14 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).
Logged
Pages: [1] 2 3