Print

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

[burakkucat]

. . . maybe it was the L&S that caused the removal of INP ??

Thinking about the L&S, surely it would be regarded as identical to the provision of a new circuit, as far as the DLM is concerned? 

I imagine that the DCoE would have been able to interrogate the circuit, to note its current operating parameters and then transfer the essential settings to the new circuit . . . but that would have meant more work on their behalf. 

[Chrysalis]

ok thanks BS for confirming a pair swap was done, as 3 hours seemed too long just for a lift and shift.

It does indeed at the moment sound like its just really and I mean really bad crosstalk, the lower speed of the normal estimate is the 20th percentile meaning the line is slower than at least 80% of lines connected to DP.  Even if the line is interleaved it wouldnt knock off circa 20mbit.

My line is 350m with pretty bad crosstalk and still is managing to sync above 70mbit. The crosstalk on this line must be really insane if its not a fault.

The removal of DLM actually should have aided the engineer as DLM can mask problems, he would then see true ES, CRC etc. without excessive protection filtering them out.

[Black Sheep]

I'm also wondering if there's an element of REIN affecting the circuit somewhere along its length ?? Something that wasn't touched upon during the phone call.

[kitz]

Thinking about the L&S, surely it would be regarded as identical to the provision of a new circuit, as far as the DLM is concerned?

You would think so, but as I observed several months ago, there really does appear to be 2 types of reset.
Anything automatic, ie migration to an ISP with a different profile, change of product doesnt seem to trigger a reset back to open.  Instead it appears to go to the interleave by default.. which is what Ian Lawrence said would be the default after G.INP mk2.

The only times we appear to see a full reset back to 'Open' now is on a first time VDSL provision or DLM reset performed by the engineer.

I imagine that the DCoE would have been able to interrogate the circuit, to note its current operating parameters and then transfer the essential settings to the new circuit . . . but that would have meant more work on their behalf.

I dont think thats possible with NGA DLM there seems to be no configurable params at all.  Unlike 20CN or 21CN ADSL DLM there's no way of requesting interleave off or setting a target SNRm.   The only option is a reset.

My line is 350m with pretty bad crosstalk and still is managing to sync above 70mbit. The crosstalk on this line must be really insane if its not a fault.

My line is 300m, no ali, decent grade copper and look where I am now.  Last crosstalker took 9Mb so thats a total of ~34Mbps headline for me and I wasnt even first on the cab. I thought most of mine was done but obviously not.

As mentioned by BS ali lines are more susceptible to crosstalk, but I agree 57Mbps does seem low.  If that 57Mbps includes interleave (impossible to tell from the limited stats) then you can perhaps add another 10Mbps on top.   

One of the reasons I'm hesitant about who I migrate to is I dont really want to move to an ISP that has Standard rather than Speed profile.  I'm still getting that CRC spike everyday at 10.30 am, add in thunderstorm season or some other event and I could now find myself interleaved and it being extremely difficult to get rid of... and being stuck at ~ 65Mb.  The NGA DLM really does seem borked right now.  At least those on a Huawei cab have G.INP available to give back some of the speed.   I'm not sure if NGA DLM being borked to do with ASSIA or if its G.INP mk2.  All we know is that because of the ASSIA case they had to change NGA DLM but since these changes were within months of G.INP problems then its impossible to tell which it was and Openreach are remaining extremely tight lipped about NGA DLM.

[kitz]

I'm also wondering if there's an element of REIN affecting the circuit somewhere along its length ?? Something that wasn't touched upon during the phone call.

A GEA service test will sometimes pull up REIN and this should be flagged to the attending engineer?   Presumably Sky will have run a GEA test prior to putting in a request for engineers visit?

However that info is pulled from the equivalent of h-log and QLN.  As we all know, both of those are snapshots in time and REIN is an unreliable beast which 99 times out of 100 decides to behave when an Openreach engineer is visiting.   No disrespect to Openreach but I still maintain that the likes of DSLstats is one of the best tools available for spotting EMI/RFI as its impossible for an engineer to monitor a line 24/7.  Once diagnosed then it can be passed to Openreach with proof of its existence.

I dont know which modem the OP is using.  Would they be willing to purchase a modem that is compatible with DSLstats?   

[Chrysalis]

yeah kitz just remember tho the estimates, the estimates are derived from what neighbouring lines are getting.

So regardless if the line is ali, copper or paper, neighbouring lines are getting significantly higher speeds.

[kitz]

>>  neighbouring lines are getting significantly higher speeds.

Good point and really why we need to see proper stats. Just thought though with it being Sky, things could be a little bit trickier for the op than with most other ISPs.. but as you yourself know.. its not impossible.

[Chrysalis]

well yeah sky may just say tough luck we tried.

[skyeci]

Very much if open reach say its fine they dont bother to take it any further...dont ask about the cabinet tails..