Kitz Forum

Announcements => News Articles => Topic started by: ejs on November 16, 2017, 12:12:45 PM

Title: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on November 16, 2017, 12:12:45 PM
https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga04217.do

Quote
This briefing is to inform CPs that we have a number of DSLAMs in the live network that are not properly reporting to the Openreach Dynamic Line Management (DLM) System

A specific modem/firmware combination on end customer devices which have not been approved for use on our network and have not been through our Modem Conformance Tests (MCT) is or appears to be causing an issue in the DSLAMs that means they do not correctly format the data transmitted from the DSLAM to our DLM systems. The DLM system then cannot interpret the data for all lines on that DSLAM.

Of course it doesn't publicly give the type of DSLAM or the modem/firmware combination. But it suggests that one person using a bad device can mess up the DLM data for everyone on that cabinet.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: Ixel on November 16, 2017, 02:15:59 PM
Interesting, I wonder what devices are causing this. I imagine DSL-AC68U is one for sure.

Better question is also how long this may have been going on for. If it has been like this for quite some time but only noticed until recently then it might explain why some lines/circuits appear to get stuck for a while without positive DLM intervention (especially banding?).
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: WWWombat on November 16, 2017, 03:48:41 PM
Terrible behaviour for the DSLAM software if it allows the data reporting on one line to impact on an entirely separate piece of functionality.

Sounds like some escape character getting misplaced - like an apostrophe in an SQL command, or an angle bracket in XML or html.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: broadstairs on November 16, 2017, 04:07:56 PM
I wonder if this could be something to do with DLM not seeing my line correctly as ILQ green and removing interleaving? Also wonder if this is more likely on ECI cabinets rather than Huawei since their software seems more flaky.

Stuart
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: j0hn on November 16, 2017, 04:28:10 PM
I wonder if this could be something to do with DLM not seeing my line correctly as ILQ green and removing interleaving?
I very much doubt it.
Have you tried capping your line yet? ILQ green isn't always enough to drop interleaving. It seems to require a much lower ES rate than just ILQ green to remove interleaving.
Capping your DS to about 50-55Mb should see it return to fastpath within a few days.

Interesting, I wonder what devices are causing this. I imagine DSL-AC68U is one for sure.
That was my thoughts exactly. Might also be related to DLM removing G.INP on these devices.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on November 16, 2017, 04:32:28 PM
There are a few more details in the ISPReview article and its comments:
https://www.ispreview.co.uk/index.php/2017/11/calling-clarity-openreachs-broadband-modem-conformance-testing.html

According to that, it affects both Huawei and ECI cabinets.

I assume that the DLM having no data for a line would mean that the DLM would make no changes, positive or negative. Banding neither being removed nor applied.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: broadstairs on November 16, 2017, 04:40:29 PM
Have you tried capping your line yet? ILQ green isn't always enough to drop interleaving. It seems to require a much lower ES rate than just ILQ green to remove interleaving.
Capping your DS to about 50-55Mb should see it return to fastpath within a few days.
That was my thoughts exactly. Might also be related to DLM removing G.INP on these devices.

How low does one have to go as my line currently runs at less than 50 ES per 24 hours often less than 20! I would have thought that was way low enough!

Stuart
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: Chrysalis on November 16, 2017, 06:30:19 PM
I wonder this could explain why lines like kevin's have broken UPBO.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on November 16, 2017, 07:55:33 PM
I didn't think UPBO was anything to do with the DLM, I thought it was mostly based on the length of your own line.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: gt94sss2 on November 16, 2017, 08:14:19 PM
I wonder if this is why DLM has not acted on my line yet.. it's been 32 days since I fixed my master socket wiring..
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on November 16, 2017, 09:28:16 PM
You could try unplugging your modem and plugging it back in again many times in a short space of time, and then see if the DLM does nothing the next day!
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: nivek1612 on November 17, 2017, 08:58:50 AM
I do hope that BTO start to stop these 'suspect' modems

my US is limited by some factor that no-one can understand and I'm convinced its a Asus or similar using UPBO 
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: stevebrass on November 17, 2017, 11:18:21 AM
I do hope that BTO start to stop these 'suspect' modems


I was pondering the "mechanics" of this. BTO would have to identify which modems were not compliant. What would they do then? If BTO blocked that modem (either each individual or as an installed  group) end users would need to be told something. Would BTO first tell BTW who then tell ISP's who then tell the end users? And would this communication be before or after blocking the modem.

I imagine however it is done it would result in a lot of unhappy end users contacting a lot of unhappy ISP's contacting......and so on.

Good stuff for the tabloids as well. Big Brother BT is watching what you do in your house!

If the ECI G.Inp issue was/is to do with non compliant modems then BTO might have considered blocking the errant devices.

Without enforcement then the MCT seems only of use when end users report a problem and get told to use something else - that is BTO/BTW/ISP's being reactive and not proactive.

Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: Deathstar on November 17, 2017, 12:59:49 PM
Pffft, users like me using an ASUS modem and specifically DSL-68U.... ;)....

But you may not be too far away from the truth. About 6 months ago, I had a fault and whenever my ISP completed a line test they were unable to report my sync rates both up and down would report as zero. However they could determine that the link was up.

I have an option of getting hold of a new HH6 for £25 so could be tempted with that.
I am with PN FYI.

Sent from my SM-G930F using Tapatalk

Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: broadstairs on November 17, 2017, 02:43:02 PM
In my view BT shot themselves in the foot by not requiring all modems being used to be compliant right from the word go. If they had  done this then it would be a non-issue since they could block any non-compliant modem immediately. Now they have a much bigger issue. Plus I guess many more modems/routers would have been tested by the manufacturers to protect their marketplace.

Stuart
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: licquorice on November 17, 2017, 03:06:08 PM
Any equipment attached to the network has always had to be compliant and approved. However, it has never been enforced.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: Chrysalis on November 17, 2017, 07:11:56 PM
I didn't think UPBO was anything to do with the DLM, I thought it was mostly based on the length of your own line.

DLM also controls power masking I believe.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: WWWombat on November 17, 2017, 08:20:17 PM
DLM also controls power masking I believe.

The ANFP allows for a dynamic UPBO, as well as a static option. As far as I can make out, the static one is in use, and is dependent on the electrical line length estimations made by the modems as they sync.

Downstream appears to have no dynamic option. Just a static option, based on electrical distance from the exchange.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: Chrysalis on November 17, 2017, 08:34:06 PM
Well I see my own UPBO vary from sync to sync, so on my own line its shifting between different profiles, even changing the modem can make it act different, as proven when I switched to zyxel.

I also have seen lines matching my electrical distance using different UPBO profiles to my own line.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on November 18, 2017, 07:24:16 AM
How do you know the UPBO values are changing? Is it just that you've seen the transmit power figure change, and have concluded it must be that it's the DLM fiddling with the power setting? It could be that conditions change, which result in the amount of power being used varying.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: Chrysalis on November 18, 2017, 12:51:42 PM
The SNRM changes significantly (not a small variance) and the ES count jumps up when it reduces which is what one would expect with a lower SNRM, there is several posts made by me (and others) on here about it.

If you check my MDWS history, you will see on some resync events I have changes in my US characteristics.

skyeci had the same also when he switched to a zyxel modem.

I believe what it is, its the newer broadcom chipset drivers that negotiates a higher UPBO.  Because the newest chipset driver also does it on the 8800nl and its why I am not using the latest driver on my 8800nl, my new zyxel devices which have newer drivers than the older 8800nl also do it, but my older zyxel 8324 didnt used to do it but that had an older chipset driver.  However even on the older driver, occasionally UPBO intensity changes on a new sync event.

You can tell the power masking in use simply by looking at the SNR and bitloading patterns across the US tone ranges.  Those people like kev who have low US speeds for their attenuation are stuck on the wrong UPBO profile, they have the back off applied on the U2 range instead of U1.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on November 18, 2017, 01:44:30 PM
And what does different modem/firmware combinations giving different results have to do with the DLM causing the difference?
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: kitz on November 18, 2017, 04:52:31 PM
Quote
The DLM system then cannot interpret the data for all lines on that DSLAM.

Woah, thats pretty bad. Not being able to interpret data for the bad device is kinda fair enough, but to mess up everyone else's figures on the DSLAM is not good :(

I'd take a stab at Asus too, but there also have been problems with a few of the older Drayteks which do not appear to play nice on Openreach's cabs.

Even so...  how can it be allowed to screw up the data for everyone else on the cab.  Surely there must be some code they could put in to properly escape individuals set of data.   Thus they can use ILQ Grey for the offending line.

I'm not quite sure what they can do about the existing rogue modems..  no doubt they should be able to track back and identify which line it belongs to.   They should be able (in time) to be able identify the modem type and contact the manufacturer... who will hopefully be able to provide new firmware.   The problem then is.. would all users update the firmware?

------

I didn't think UPBO was anything to do with the DLM, I thought it was mostly based on the length of your own line.

You are correct.  Spectral Power Management is completely separate to DLM management.
I have also seen mine vary between resyncs - even using the same modem, but its not DLM related. 

Spectral Management (UPBO & PSD masks) are used to lessen the effects of crosstalk. eg:
On ADSL/ADSL2+ to stop shorter lines drowning out longer ones.
On VDSL to stop VDSL lines drowning out ADSL/ADSL2+

Sometimes your modem can give you a little bit of a power boost (AGC) if there has been a lot of bitswap in an attempt to keep the line in sync...  but there is still supposed to be a max figure. Not sure what it is on VDSL because of all the different profiles, but it was 20dBm for ADSL2+

Thats one of the reasons why there is the huge possibility for some of the ASUS modems to cause havoc on some DSLAMs as they are about the only modem I know of whereby it allows you to completelely turn off UPBO and adjust the AGC GAIN... thus affecting every other connected line. :'(
There was quite a long thread on here a few years ago about it. These ASUS modems totally over-ride DSLAM spectral management which is a DSL standard and not really supposed to be tweaked by the EU at all. 
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: kitz on November 18, 2017, 05:09:04 PM
Is this the sort of thing you mean?

Same modem... same sync speed but look how atm my line is having one of its oscillating fits.    Note how the power is now ramped up - probably AGC GAIN.

I need to do a full power down really and see if I can clear it.


---
ETA...  also note that despite my SNRm oscillating and its now below 6dB, my err/secs are far lower than what they usually are.   
Its exceedingly rare that I have all green traffic lights at this time of day, yet my line conditions are actually worse, so you'd expect the reverse to happen.   But when you look at power and see that Ive been given a power boost, which is attempting to keep the line stable.   

AGC GAIN doesnt always kick in, sometimes the line will go down first.   Next time I resync it may well take it away again.

Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on November 18, 2017, 05:52:44 PM
I thought that with ECI cabinets, reporting identical power figures for both downstream and upstream - one of the power figures is incorrect?

--

Apparently Origin Broadband have been supplying Asus DSL modem/routers to their customers, with the DSL-N16 (https://www.originbroadband.com/support/knowledge-base/router/asus-n16) as their basic model. Of course we don't actually know that the offending modem/firmware combination is an Asus.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: kitz on November 18, 2017, 06:21:55 PM
Yes.   Downstream is also reporting the upstream figure, thats why they mirror each other :/
But it does show that Ive had a power boost.   It will at some point take it back off me when I reboot :(


---
ETA

Attaching full years power so you can see it being applied and then when things are nice and stable (like it was before a few days ago) I get it taken back off me.
I think this is the effect what Chrys means about power being reduced.    Mine will possibly now stay high...  until I power down for a while. 

Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: jelv on November 18, 2017, 08:42:08 PM
I'm not quite sure what they can do about the existing rogue modems..  no doubt they should be able to track back and identify which line it belongs to.   They should be able (in time) to be able identify the modem type and contact the manufacturer... who will hopefully be able to provide new firmware.   The problem then is.. would all users update the firmware?

Cap the speed at some artificially low figure? That would push users towards contacting their ISP and providing the ISP could tell that the user had plugged in a rogue modem from information provided by OpenReach they should be able to sort it.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: skyeci on November 18, 2017, 09:38:06 PM
When openreach identified the line/modem (including model/brand & what firmware it was on) that was causing huge issues to my and possibly neighbouring lines I was told even though they knew it needed to be either replaced or removed they said they had no authority to intefer with that service even though it was their network. After several weeks of not getting anywhere Openreach then informed me they had asked the ISP of the offending modem to request it's replacement but that was as far as it would go and would not be followed up further. Due to them telling me the details of the modem and being on good terms with my neighbours I found it myself in the end .
 I am interested to see if they will  now be changing their approach.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: burakkucat on November 19, 2017, 12:13:10 AM
Due to them telling me the details of the modem and being on good terms with my neighbours I found it myself in the end.

It would not be appropriate for you to mention the device's make & model in the public view but would you send a pm to kitz, roseway and myself with the details, please?
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: Chrysalis on November 19, 2017, 09:03:34 AM
seems the view has changed,  a couple of years back it was either kitz or wombat who said DSM was part of DLM.

anyway there is dynamic power masks they not static, and no it doesnt oscillate "during" a sync, what i am talking about is the DSM been adjusted on the dslam on a new sync event to adapt to other lines, a system somewhere will be setting these parameters aka some form of line management and DLM stands for dynamic line management.

I also perhaps should clarify openreach themselves have told me this. You welcome to pm me kitz about it but I wont post more about the openreach source in the thread.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: kitz on November 19, 2017, 10:01:17 AM
Not me.  As above, Spectral Power Management is completely separate to DLM management.

DLM is the RAMBO system.

Spectral Power Management is a DSL standard, done at the DSLAM.  With VDSL, the masks are kind of dynamic, in that they depend on 2 criteria:
1) The distance of the cab from exchange
2) The distance of the EU from cab

So therefore you may have 2 people, both of whose line length from that cab is 300m, but they can have different mask profiles because user 1 is 500m from the exchange and user 2 is 2km from the exchange.   It's done like this to protect lines which are still on ADSL/ADSL2+ which could easily be drowned out by VDSL otherwise. The further your FTTC cab is from the exchange, the harsher the cut back, because the neighbouring ADSL signals will be weaker at this distance.

Quote
a system somewhere will be setting these parameters aka some form of line management and DLM stands for dynamic line management.
Yes you are correct, but they are 2 separate and independent systems -  DLM and SPM.   
SPM can be dynamic in that masks can change based upon line length estimations (attn) when the line syncs up.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: kitz on November 19, 2017, 10:30:36 AM
Just to add something further after I'd walked away from PC to go put the kettle on.

The masks are very complex, there are lots of them.... so to clarify when I said the further away from the exchange, the harsher the cut back, may not always be strictly true.   

It will be in U1 & D1, but I think there is some allowance made on the most distant cabs.. in that it assumes ADSL tones after 'x'kHz wont be in use by neighbouring ADSL lines therefore the VDSL users on that cab can have more power after 'x'kHz.   It really does depend upon the type of lines in your neighbouring area that are attached to both the cab and what ADSL conditions are like.   

You may also have a cab where the line with the cab with the max distance has to be taken into account.  As I said its complex and no 2 cabs are going to be alike.   Around here we have a cluster of cabs that spread out like a star from the exchange, but because I live on a penisula, then on 3 sides no property is ever far from a cab, yet on one side there are some very long (copper) lines.   Cabs in that one direction will be using very different base profiles than those on the other sides.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: kitz on November 19, 2017, 07:03:52 PM
Whilst I was away from the PC, this topic was still niggling at me. 

I've been thinking about Spectral Management, yet Chrys said "I also perhaps should clarify openreach themselves have told me this. "
Whilst I don't have this info, I was mulling it over whilst supposed to be doing something else, because I also have no reason to disbelieve why Chrys would say that when I  know he has a pretty reliable source, yet it conflicts with how DSL is supposed to work. 

Whilst traditionally Spectral Management profiles are set on the DSLAM and kind of hardwired into a profile - although complex, the base figure (Distance of cab to exchange) is straight forward, so then the DSLAM can make a fairly simple calculation for the later part.   ie  IF (atten = 'x' DB)  THEN (set profile 'A');.
This is totally separate from DLM.

Anyhow this is how the rest of my rambling thoughts went.

-----

Now they are using vectoring on some Huawei cabs, Spectral management will become a lot more complex for something which is already complicated.   Although I havent seen any signs of dynamic SPM on the downstream for ECIs...  thats not to say that they dont have something in place to cover the Huaweis cabs with Vectoring.   Those cabs with vectoring would greatly benefit from DSM even non vectored lines in the area.

So back to DSM and DLM being separate.   They will be separate parts of the system but it is possible that the RAMBO boxes could be used to calculate DSM.   In a similar way that the RAMBO boxes also control RAP.   Yet RAP is the bRAS control and different from DLM.   

Trying to think of an easy way to explain it - try the following.


2 completely separate programs but all running on one box.  DLM is nothing to do with RAP..  but both are part of BTs DLM system because it's RAMBO doing the calculations based on the current sync speed to send over to the bRAS.

Got me so far?

(http://www.kitz.co.uk/adsl/images/DLM_system.png)



--------------------

Now if Openreach are using DSM because of vectoring, then there could be some very intricate calculations to be made.   Something will have to calculate the best Spectral profiles for all the lines in the area.  Because we still have the legacy DSL systems in place this task becomes even more arduous.   The DSLAM is relatively dumb, it mostly does what its told..  its basically a fancy modem handling a few hundred lines.
 
Something else will have to be calculating which DSM profiles to use... each and every cab will be different based on line lengths of all the users in that area.  You'd need something which can access line stat data (such as atten) from the DSLAMs. 
Why not use the RAMBO boxes to do the number crunching, it can already communicate with the DSLAM, it will already have access to line stat data.   So now you just install another program which can take this data and calculate the relevant mask for each line which then sends that info back to the DSLAM.   

Using my example above lets say its the equivalent of MS Word on that PC that already has Excel and Access.
All 3 are totally different programs that do their own thing, but they are all part of the MS Office suite running on one box.

----

The more I think about it the more it makes sense.  I'm certain I wrote on this very forum several months ago that BT was updating its RAMBO boxes.

It would explain why Openreach may call it part of the DLM system (http://www.kitz.co.uk/adsl/DLM_system.htm)...  and yet why it is not part of DLM profiling which we see as things like INP, G.INP, target SNRM, Interleaving.   Its just another program running on the RAMBO boxes which does its own thing separate to DLM.

Others thoughts are more than welcome :)
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on November 19, 2017, 07:36:11 PM
According to NICC document (http://www.niccstandards.org.uk/publications/reports.cfm) ND1513:

DSM Level 1 is DLM, setting INP levels, rate caps etc.
DSM Level 2 is adjusting transmit power levels to reduce crosstalk and optimize performance
DSM Level 3 is vectoring
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: Chrysalis on November 20, 2017, 02:24:10 PM
i get you kitz and what you said is plausible
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on January 09, 2018, 10:52:35 AM
Now we have a similar briefing title:

NGA001/18 GEA-FTTC - Modem firmware issue impacting certain DSLAMs (https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga00118.do)

Which as usual the public can't read to find out what modem firmware and which DSLAMs are involved. I'm sure ISPReview will be able to spin it out into an entire article with no actual additional information beyond the briefing title.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: kitz on January 09, 2018, 11:29:33 AM
Cheers ejs.
We can only speculate.  I doubt they will publicly name and shame until they have worked with the modem manufacturer to get them to roll out a fix :(

Quote
a modem firmware issue


Whilst we may suspect which modem it is, even if the manufacturers do provide an updated f/w version..  who is to say all the EU's will apply it.
Joe public seldom thinks to update modem f/w.  So if its something they bought from PCWorld, they just take it home and plug it in expecting to do little more than add their SP login details.

Quote
on some of our DSLAMs

More speculation from me, but if view of the g.INP & xdB delays with the ECI's... and the upgrade of wording from "a number of DSLAMs" to "some of our DSLAMs"  could indicate that its DSLAM manufacturer specific.

Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: broadstairs on January 09, 2018, 11:41:35 AM
I am more and more convinced this applies to ECI equipment. I am on an ECI cabinet and DLM seems to never handle my line correctly. It looks impossible for it to manage to remove interleaving despite my ES rate being in single figures per 24 hours. It has been months again with nothing being done to remove this. I believe that BT should name and shame the equipment manufacturers as the current situation is intolerable.

Stuart
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: kitz on January 09, 2018, 12:05:59 PM
It is possible that it could be a source of your issues.   I think most of us here suspect which modem and which DSLAM type.
All I can say is that DLM removed INP on my line after 14 days..  so therefore at least on some ECI's its working as intended.   It seems to work ok on Huaweis..  so it could be likely that there is someone on your cab with one of the duff modems.

Too much speculation and not enough facts right now though. I strongly suspect that even if they have named the modem in the briefing, the SPs will have been told its confidential.   There's perhaps only one ISP that might have the guts to spill, but that would depend upon what inpact they may have in getting access to future briefings.
 
If Openreach have managed to get the manufacturer to release new f/w I agree they need to make this public.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on January 09, 2018, 12:19:03 PM
There was an Asus firmware update for some models in late November 2017, but not for the DSL-AC68U.

https://www.asus.com/uk/Networking/DSLAC68U/HelpDesk_BIOS/ latest 2017/08/11
https://www.asus.com/uk/Networking/DSL-N16/HelpDesk_BIOS/ latest 2017/11/28

The update for the DSL-N16 appeared to be security related with the DSL parts unchanged. I've been watching firmware updates for clues but there's not really been any firmware updates, or at least nothing downloadable.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: kitz on January 09, 2018, 12:19:18 PM
Mind you, that said.   
There is some issue with the ASUS DSL-AC68U with G.INP on the Huawei cabs.... whereby Openreach has been actively disabling G.INP for those ASUS users on the Huawei's.   link (http://whatsyourrouter.com/mybb/showthread.php?tid=160&page=8).

Quote
the fix ASUS had for the BT issue is not supported via the chipset manufacturer, but they are looking at alternative approaches, so nothing in the short term I am sorry to say (as far as I know)


---
ETA
My post crossed with ejs's
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: gt94sss2 on January 09, 2018, 01:12:12 PM

Yes, I suspect (almost hope!) that my Hauwei cabinet is one of those affected - as i have been on INP value of 57 for quite a while now - when I think it should be in the 40's instead.. (stats online in MDWS under gt94sss2)

Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: skyeci on January 09, 2018, 09:54:12 PM
hazard a guess....maybe ECI?? ;D

https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga00118.do
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: j0hn on January 09, 2018, 11:03:32 PM
There's nothing that suggests it affects a single DSLAM vendor. My guess would be it affects both ECI and Huawei DSLAMs. We have a fair guess which modems are causing this. OpenReach have also removed G.INP on these on Huawei cabinets which may or may not be related.

It sounds like they are unable to fix the G.INP issues. Mediatek are saying they can't get it to work the way OpenReach want.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: skyeci on January 09, 2018, 11:17:22 PM
ok
 cheers.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: Chrysalis on January 10, 2018, 01:52:48 PM
It is possible that it could be a source of your issues.   I think most of us here suspect which modem and which DSLAM type.
All I can say is that DLM removed INP on my line after 14 days..  so therefore at least on some ECI's its working as intended.   It seems to work ok on Huaweis..  so it could be likely that there is someone on your cab with one of the duff modems.

Too much speculation and not enough facts right now though. I strongly suspect that even if they have named the modem in the briefing, the SPs will have been told its confidential.   There's perhaps only one ISP that might have the guts to spill, but that would depend upon what inpact they may have in getting access to future briefings.
 
If Openreach have managed to get the manufacturer to release new f/w I agree they need to make this public.

Likewise I have never had stuck interleaving on an ECI cabinet.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: andyfitter on April 11, 2018, 11:29:52 AM
Just wondering if the original issue reported here was ever resolved (And if it might be related to why I haven’t yet got g.inp back nearly 4 months after DLM reset)?
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on April 11, 2018, 09:57:11 PM
There was this:
https://www.openreach.co.uk/orpg/home/updates/briefings/super-fastfibreaccessbriefings/super-fastfibreaccessbriefingsarticles/nga00518.do
Quote
NGA005/18 GEA-FTTC - Removal of Dynamic Line Management (DLM) issue on Long Lines

23/02/2018      For Information

This briefing is to inform all CPs that we've identified and fixed a minor DLM impact on our very long GEA-FTTC lines on a small subset of our DSLAMs.

But we can't be sure it's referring to this issue or something else.

I'm not even sure it was the MediaTek Asus modems that we suspected were the problem. Because there was this (https://community.netgear.com/t5/DSL-Modems-Routers/BT-Openreach-customers-using-D7800-Modems/td-p/1411403) at a similar time, and the D7800 uses the relatively uncommon Lantiq VRX318 VDSL2 chip. And the briefing stated it was a modem/firmware combination that was the problem, and although the D7800 has now passed MCT, it's possible that not all its firmwares did.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: ejs on April 30, 2018, 08:28:37 PM
There has been a possibly related update to the BT SIN 498 requirements:
Quote from: BT SIN 498 v7.5
R.VDSL2.16
The modem shall support the correct reporting of Vendor ID, Version Number and Serial Number as described in section 11.2.3.6 of G.993.2. In addition non-printable ASCII characters (e.g. CR, LF, FF), delete (DEL) and comma (,) shall not be used.
Title: Re: Issues with DSLAMs correctly reporting to DLM
Post by: andyfitter on April 30, 2018, 10:02:10 PM
Ouch. Maybe the Dslams are currently sending this data back to the DLM servers as unescaped comma separated fields.  An embedded comma would break it horribly. Yuck.

Surely it would be wrapped inside XML or JSON or one of the many other options.