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 9538 times)

Ixel

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

ejs

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

Ixel

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

ejs

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

kitz

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

Ixel

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

Ixel

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

ejs

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

Ixel

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

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #25 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 ££.
« Last Edit: April 14, 2018, 11:08:43 PM by Chrysalis »
Logged

Ronski

  • Helpful
  • Kitizen
  • *
  • Posts: 4300
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #26 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.
Logged
Formerly restrained by ECI and ali,  now surfing along at 390/36  ;D

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #27 on: April 15, 2018, 03:39:33 PM »

But it did prove it could be done.
Logged

NewtronStar

  • Kitizen
  • ****
  • Posts: 4898
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #28 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.
« Last Edit: April 15, 2018, 08:03:19 PM by NewtronStar »
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: Openreach Deploy Low Level Error Correction on New FTTC Lines
« Reply #29 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
Logged
Pages: 1 [2] 3