Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[kitz]

                              Upstream   Downstream
Current Rate (kbps)   14156   47901
Max Rate (kbps)   14085   64083
SNR Margin (dB)   6.2           6.1
Line Attenuation (dB)   4.9           13.9
Errors (pkts)           24            0

The max rate being quite a lot more than the sync at 6.1 dB indicates that the line is Interleaved. 

The change of ISP has likely reset the DLM and it is going through a new stabilisation period.  Depending on the cab type there are still changes that can be made (such as G.inp & x.dB) which should improve your sync speed.

[j0hn]

Interleaving pretty much means ECI now.
All new provisions/DLM resets on Huawei cabinets have G.INP enabled by default. There's no more waiting for it to be enabled.
Provided the modem supports it obviously.

There might be the odd one in a blue moon Huawei line with Interleaving but it's been a couple years since I've seen it.

ECI lines default to Interleaving.

[Chrysalis]

I think DLM resets can still default to fast path, didnt kitz mentined before was two types of reset?

AAISP requested a reset on my line last week and it removed the banding but stayed on fast path, engineer did another reset today, and its still fast path.  I was actually hoping for interleaving.

[kitz]

There were indeed two different types of DLM reset.   

A hard reset that completely clears any profiles and the line enters an open profile without any DLM restrictions including interleaving, g.inp or banding.  Within 24hrs it then goes to default of interleaving, then g.inp for the Huaweis and FAST for the ECI's (if stable).    The soft reset (usually) doesnt clear any banding and g.inp for Huawei. 

Any requests for reset that are ISP or BTw or Openreach OSS are a soft reset.  A hard reset can be performed by an Openreach engineer - the idea being he can test the line and check line performance without any DLM configs such as interleaving which may mask a fault.  It will only remain open profile for the remainder of the day, or will apply interleaving if the line is really bad by triggering "Scarlet".

I was under the impression that all new provisions (which can include ISP change) went through the Open profile,  however I am not up to date with whats happening atm and you are in a far better position than me when it comes to whats happening in the real world right now and I bow to your observations.

I just noticed the max rate discrepancy indicating the line is probably interleaved ...  and the possibility of a better line rate if the line is stable.   

[Chrysalis]

Thanks for that info kitz, so thinking on what you described perhaps if my line was interleaved the AAISP soft reset would not have cleared it, it just merely kept what was there, but did remove the banding.

Then engineer did a hard reset, which makes it open profile and because errors were low it stayed on fast path.  If I understand you right that is perhaps what happened.

[j0hn]

There were indeed two different types of DLM reset.   

A hard reset that completely clears any profiles and the line enters an open profile without any DLM restrictions including interleaving, g.inp or banding.  Within 24hrs it then goes to default of interleaving, then g.inp for the Huaweis and FAST for the ECI's (if stable).    The soft reset (usually) doesnt clear any banding and g.inp for Huawei.

That was indeed the case from the initial G.INP rollout.
Openreach must have resolved the issue of the DLM having to work out if a modem supported G.INP or they now just don't care about modems that don't support it.

Huawei lines now start with G.INP and retain it on a DLM reset or migration.
That only changed a couple years ago after an initial trial then an extended trial.

This briefing is to inform CPs that we'll be deploying a change to apply ReTransmission to lines on day 0 where supported.

Dynamic Line Management-ReTransmission on day 0

I was under the impression that all new provisions (which can include ISP change) went through the Open profile,  however I am not up to date with whats happening atm and you are in a far better position than me when it comes to whats happening in the real world right now and I bow to your observations.

Interleaving is definitely the default on ECI lines for new provisions.
That started in Feb 2018 for some tiers and was extended to the 80/20 package in August 2018.

https://www.ispreview.co.uk/index.php/2018/08/openreach-extend-low-level-error-correction-to-new-80mbps-fttc-lines.html

DLM resets are a bit of a dark art now, which I assume includes some migrations.
Provider initiated resets usually keep the current profile while engineer resets tend to put lines on interleaved. That's clearly not always the case though, as seen from Chrysalis' line.

I've never understood the whole hard reset/soft reset thing either or how some engineer resets have different outcomes to other engineer resets.

There have been no recent changes to the DLM this year but in 2020/21 Openreach put out a lot of DLM related briefings with lots of trials and changes.

They made changes to the "Standard" DLM policy, they held trials on retaining the current DLM profile for product moves, introduced Retx on day 0, added/trialled a new stability policy, trialled MTBR changes, trialled higher levels of Retx and started/stopped half a dozen ISP DLM reset schemes.

If you can keep up with all that you're doing better than me

Nothing regarding G.INP on ECI for a long time either.
I don't think that's ever going to happen now.

[adslmax]

I thought G.INP already sorted out on ECI cabinets by now? Has Openreach giving up now because of rolling out FTTP.

[burakkucat]

I thought G.INP already sorted out on ECI cabinets by now?

No, it has not been resolved. ECI hardware in the Openreach access network has, basically, become a bit of an embarrassment.   

Has Openreach giving up now because of rolling out FTTP.

Your guess is as good as mine. 

[adslmax]

Oh dear me poor all of those have to suffers with crappy ECI cabinets. Never understand why Openreach installed more Huawei cabinets than ECI cabinets. Should have 100% of all Huawei cabinets.

I guessed I am very very lucky indeed to have my healthy FTTC line with the closer distance to the Huawei cabinet. Still on stable 80/20 for 5 months now since migrated from G.fast to FTTC. 

Anyway everyone can look forward to FTTP soon. 

[kitz]

Thanks j0hn for all the additional info appreciated.

As an aside I was looking at the new SIN 498 dated Nov 2022 for something else and happened to spot this. 

"At provision, the line is put on "wide open".  VDSL2 line profiles allowing  the upstream and downstream line speeds to run at the upper limit of the product option selected.

On the first day of operation, DLM will intervene if severe instability is detected.  Otherwsie DLM will wait until the day after provision before deciding ......

I know its been like that for a while, but you'd think they would update it if its no longer true :/

[Alex Atkin UK]

Oh dear me poor all of those have to suffers with crappy ECI cabinets. Never understand why Openreach installed more Huawei cabinets than ECI cabinets. Should have 100% of all Huawei cabinets.

They used both because it could have just as easily been Huawei that had the problem, so by having two vendors it was unlikely a problem would happen on both, so they had a backup solution.

Its also a way to avoid supply issues or issues like the government deciding Huawei aren't trustworthy.  If you put all your eggs in one basket, these problems can be far more costly.  Plus the sheer scale they were rolling out cabinets, one supplier likely could not have supplied enough hardware to work that fast.

The ECI situation sucks, but by the time the scope of the problem was identified, it was too late to do anything about it and it could have been much worse.  ECI were probably promising a firmware fix for years before realising it wasn't possible.

eg When I was on Digital Region their line cards topped out at 60Mbit due to a hardware issue and they had to swap out the entire card to unlock the full 100Mbit.  One of many issues they had due to going with a one-supplier solution.

[kitz]

@ Max

As Alex says, they've always used at least 2 different suppliers - theres several different MSANs and the old adsl DSLAMs. For FTTC, at one time the ECI's were considered superior & more advanced than Huawei.  It's only really when g.inp rolled out that  the problems started occurring.  I#m still not convinced the g.inp problems are entirely ECI, but rather certain modems dont play nice with ECI g.inp.   Some of the modems we saw potential issues with were the BT HomeHub 5A, Openreach ECI modem and Draytech Vigor 2850 series.  When g.inp first rolled out a high proportion of users had the first 2 of those modems

One of the ECI M41's selling points was the small cab size which at the time could hold as many lines than the substantially larger Huawei MA5603T.   Unfortunately the small size was problematic because there wasnt enough room inside to add a vectoring module.    ECI led the way with vectoring but for this you needed the ECI E41.  I dont think the E41's were in general production when Openreach pre-ordered thousands of the M41's which they began installing in 2012.   There were a few other ISPs who had ECI cabs - for example Deutsche Telekom.  I believe they swapped out some of their M41s for E41s or replaced with other kit.

In the grand scheme of things the lack of g.inp on the ECI's probably isn't that great.   The average user wouldnt have a clue that the Huawei cabs have full g.inp.  They probably don't even know their sync speed and don't care that users on a different cab are now able to get better error protection.   It doesnt make a vast difference to sync.... the main advantage is g.inp v interleaving so potential for better latency.    However that's a moot point when you have gamers using wifi to hook up their console.   

[Alex Atkin UK]

Some of the modems we saw potential issues with were the BT HomeHub 5A, Openreach ECI modem and Draytech Vigor 2850 series.  When g.inp first rolled out a high proportion of users had the first 2 of those modems

Plus AFAIK at least the first two were fixed with modem firmware updates, as used both on G.INP myself on OpenWRT.  I mean not sure I needed G.INP once my drop wire was replaced, but it was stable, so stable I didn't realise the drop wire was damaged until it failed completely which would suggest it was doing its job.

[adslmax]

As an aside I was looking at the new SIN 498 dated Nov 2022 for something else and happened to spot this. 
I know its been like that for a while, but you'd think they would update it if its no longer true :/

I did noticed that. From G.fast changed over to SoGEA 80/20 last June my isp thought it will be a few days later for G.INP and INP to be applied on the downstream but it went straight away 80/20 with G.INP enabled with INP of 48 with interleave dept of 16 from minute of activated and remain there the same for nearly 124 days now with no change.

Stats recorded 23 Nov 2022 16:21:06

DSLAM type / SW version:   BDCM:0xc190 (193.144) / v0xc190
Modem/router firmware:     AnnexA version - A2pvfbH043q.d26u
DSL mode:                  VDSL2 Profile 17a
Status:                    Showtime
Uptime:                    123 days 18 hours 47 min 26 sec
Resyncs:                   0 (since 23 Nov 2022 16:19:05)
         
            Downstream   Upstream
Line attenuation (dB):     12.2      0.0
Signal attenuation (dB):   Not available on VDSL2      
Connection speed (kbps):   79999      20000
SNR margin (dB):           7.6      10.7
Power (dBm):               12.5      -0.2
Interleave depth:          16      1
INP:                       48.00      0
G.INP:                     Enabled      Not enabled
Vectoring status:          5 (VECT_UNCONFIGURED)      

RSCorr/RS (%):             0.0009      0.0000
RSUnCorr/RS (%):           0.0000      0.0000
ES/hour:                   0      0

Since Link time = 123 days 18 hours 49 min 56 sec
FEC:            20606           0
CRC:            3               6064
ES:             2               5278
SES:            0               1
UAS:            0               0
LOS:            0               0
LOF:            0               0
LOM:            0               0
Retr:           0
HostInitRetr:   0
FastRetr:       0
FailedRetr:     0
FailedFastRetr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
ZySH>