SNR/Connection speed wobble.

[#1]

Thanks @NickyM, I'm sorry to see that there has been a lack of support from us here since the 13th August. I've reviewed this and I've arranged for feedback to be passed on regarding this.

Do I recall correctly that your line has been fixed to a 12dB SNRM in an attempt to maintain a stable connection? 

Yeah we've tried pinning the SNR target at 12dB on the 28th June but it looks like it's dropped back down to 3dB regardless

Profile Info:

WBC 160K - 24M Medium delay (INP 1) 3dB Downstream, UC Medium delay (INP 2) 6dB Upstream (ADSL2+)

Although the actual SNR margin is currently at 13.9dB:

xDSL Status Check
Circuit ID:	[redacted]	Service ID:	[redacted]
Telephone NO.:	NA	Test Executed On:	27-08-2019 10:40:45

xDSL Status Test Summary
Sync Status:		Circuit In Sync
General Information
NTE Status:		NTE Power Status:	Unknown	Bypass Status:

	Upstream DSL Link Information	Downstream DSL Link Information
Loop Loss:	17.5	33.0
SNR Margin:	6.0	13.9
Errored Seconds:	0	0
HEC Errors:	0
Cell Count:	9104	25496
Speed:	828	8944

Maximum Stable Rate (KBPS):	11360	Fault Threshold Rate (KBPS):	9088
Mean Time Between Retrains (Seconds):	86400	Mean Time Between Errors Upstream (Seconds):	5400
Indicative Line Quality:	G	Mean Time Between Errors Downstream (Seconds):	86400

Is it banded?  This would explain most of the reconnections being at 12dB.

There's no banding on the line.

Can you tell from the DLM logs the reasons for these drops, particularly those around 05:30 where the reconnections attempted 6dB?

Do DSLAM logs provide any information on the reasons for xDSL drops?

I've checked the historic DLM data and they're not showing the cause for the drops however they are showing the drops are definitely sync as opposed to PPP as the line is retraining.

What does the line balance look like?

Copper Line Test
Circuit ID:	[redacted]	Service ID:	[redacted]
Telephone NO.:	NA	Test Executed On:	27-08-2019 10:45:41

Status:	Pass	MFL:	OK	OR Test ID:	[redacted]
Test Outcome:	CIDT LINE TEST OK - ALL SOCKETS UNPLUGGED			DTR:	T302

Copper Test Details
	A to E	B to E
Capacitance:	158 NanoFarad	159 NanoFarad
DP Line Length Estimate:	2378 Metres	DN Line Length Estimate:	2446 Metres
Celerity:	35.9 dB	Line Loss:	40.64 dB
Line Stability:	Stable
Fault Report Advised:	N
Service Level:	2
BRAGOutcome:	Very Good
Faceplate:	Not Detected

What has already been tried on this line?

Based on the engineer notes we've received, just a tie pair modification(TPM) at the exchange.

Having said that it appears that more work has been done that what engineers have documented:

@jab1 wrote: Re: Your questions to CS in Post 56. I have had a Lift & Shift, pairs have been swapped (twice) and the Frames Unit at the exchange has been replaced. Unfortunately, I can't answer any of the other queries from memory.

Are there other customers nearby who's line performance might be examined for correlated drops?

Unfortunately that's not something I'd be able to check.

Though the TG582n router will now be of some age, it is arguably the best of ADSL routers supplied by PN and is the last one which works with any performance monitoring capability.

Sorry if I've missed something here, it's a long topic with a lot of detail but have you (@jab1) tried a different router? I'd be happy to arrange to send you a replacement router if you want? Although it'd be a Hub Zero not another Technicolor.

@jab1 wrote: Can you please 'undo' whatever it was your CSC analyst did Saturday morning 17/08/19 at around 0920.

Whatever it was has upped my SNR to 15 and reduced my connection speed to 7.8 Mbps.
He did this without confirming with me it was OK - not good practice!
Unfortunately, nor did he create a ticket on my account to explain his actions (more bad practice), so you will have to listen to the phonecall, which started around 0915, and his callback to me around 0927?

The above SNR margin and connection speed was maintained flawlessly until the event in the graphs below, so his action has obviously undone the pinning of my margin - not happy, again.

I can see the adviser on the 17th August made a change to your SNR target and documented this on a closed contact ticket here: https://www.plus.net/wizard/?p=view_question&id=193238186 While I'm not sure as to what value they set it at, I suspect it was to counter-act the drops we were seeing prior to the 17th.

As the SNR target is currently 3dB and the margin is way higher I'm not confident that another DLM change is the right call. I'd recommend raising a new fault ticket at http://faults.plus.net for us to arrange another engineer making sure this is escalated directly with Openreach before the engineer visit.

If you can nudge us once you've reported the fault we'll get it picked up and make sure it's progressed.

[#2]

@Gandalf - thank you for the comprehensive reply - you’ve been missed whilst on holiday!!

The target being 3dB and the line always syncing at 12dB is why I asked about the line being banded. If it’s not banded then something odd is happening.

A fault report seems like a sensible approach, if it’s possible to engage ‘higher level’ BTOR support from the off rather that it being approached by first line staff. It would be helpful if these graphs could be passed on to the escalation team. I know that in my case a few years ago they helped prove to BTOR that there was a problem on the line (as @ejs refers to) giving rise to increased susceptibility to REIN.

@jab1 - it’s worth assembling a collection of SNRM graphs showing the two distinct characteristics - on set to 3dB and the slow recovery not dropping sync and the sharp events dropping sync and immediately recovering.

Add to that a simple log of such disconnects (not to be confused with anything your doing).

Just to be sure nothing has been missed - when these disconnects occur, have you confirmed that there is no break in the log time stamps - that is elimination of the possibly of a power brown-out on the router?

How are things progressing with the power co?

[#3]

@Townman , @Gandalf  Thank you both for your perseverance on this matter.

I'm a little busy this afternoon and away tomorrow, so will re-read and respond on Thursday, if that's OK.

Just to answer the last two points on your post, Kevin - No log breaks that I can see, and this is a 'new' router, the swap date of which I think is documented somewhere in this copy of 'War & Peace'

Northern Powergrid have said 'give us until the end of August, and then call us if you haven't heard anything' - I have a reminder set for 03/09/19.

[#4]

@Townman No problem. When we raise an escalation with Openreach we'll have to follow the escalation process which is Team Member > Team Manager > Operations Manager giving them an opportunity at each level to resolve the issue before requesting it is escalated to the next level. 

Escalations nowadays being done directly through Openreach are via email so we should be able to provide graphs etc. I've found that this new escalation process to be really effective in the past so I hope it helps here.

@jab1 That's cool, no problem let us know how you'd want to go ahead.

[#5]

I'm surprised no-one else has mentioned this, but looking at that latest visual radius chart, it looks like whatever the problem was, it's been gone for the last 10 days.

[#6]

@ejs The connection's stable but it's at a sacrifice of speed as the SNR is far too high, having said that there is always a possibility that the line is simply really poor/can't be fixed so the SNR may need to stay like that.

[#7]

The resulting slower speed never seemed to be much of a problem with the target SNRM fixed at 12dB for however many months/years.

[#8]

@ejs that's a fair comment, hopefully the speeds stay stable moving forward but time will tell

[#9]

Re post #106 - @Gandalf 's comprehensive reply, much appreciated.

I suspect the drop to 3dB was a result of whatever the agent did on the 17th - I can't prove it, but it does seem somewhat coincidental. To also add about that agents action and the closed ticket, I was not aware of it until @Gandalf brought it to my attention, surely if one is raised, I should at least have been made aware and it should have contained a little more detail. As it stands, it is of no use whatsoever.

I thought I had some saved notes regarding the last SFI visits, but unfortunately that is a false memory (or I've filed them in the wrong place), but I can assure you that the extra actions I detailed such as the L&S were carried out, the engineer was scrupulous in keeping me informed of all actions he carried out.

I swapped the original TG582n router for a spare, which I had been sent sometime ago, during the period April-June, I assume PN logs should be able to reveal the exact date?

The offer of a 2704n is appreciated, but no thanks, it is too 'locked down' for someone like me who likes to try and solve things myself, and is also incompatible with useful monitoring programs.

With regard to the sync drops shown on the RADIUS  log, the great majority are during the period 2200-0600, when I am nowhere near the machine, never mind actively using it.

I can understand the reluctance for instigating another DLM  change, but currently my 'normal' SNR is a little raised, and throughput lowered from that obtained when the SNR was pegged at 12dB.

I am unsure as to what 'fault' I can report - the connection is stable during the majority of the time, and speeds are within estimates, although they are a little below optimum due to the high SNR. Going through the raise a fault wizard will just return a 'no fault' response.

I assume the disconnection at ~1040 on the 27th was due to @Gandalf 's testing, and the one at ~1148 was DLM objecting to the result..

If I've missed anything, please shout.

[#10]

---

@ejs wrote:

I'm surprised no-one else has mentioned this, but looking at that latest visual radius chart, it looks like whatever the problem was, it's been gone for the last 10 days.

---

Me too, @ejs. I wonder what happened to suddenly stabilise/eliminate the conditions which had previously been an almost daily (nightly?) feature?

[#11]

Re post #106 - @Gandalf 's comprehensive reply, much appreciated.

No problem.

I suspect the drop to 3dB was a result of whatever the agent did on the 17th -

It's difficult advise what SNR target the adviser moved you to however I would not expect it to be to 3dB as your line was already dropping heavily and that would've made things a lot worse, I suspect it was to 9dB or 12dB. It's possible that the drop to the target of 3dB happened since then by the DLM software.

I can't prove it, but it does seem somewhat coincidental. To also add about that agents action and the closed ticket, I was not aware of it until@Gandalfbrought it to my attention, surely if one is raised, I should at least have been made aware and it should have contained a little more detail. As it stands, it is of no use whatsoever.

The closed ticket was just an internal note to briefly log on your account what was discussed over the phone. Sorry if the content of the ticket didn't reflect what was actually discussed I'll ensure feedback is passed on if that's the case.

I thought I had some saved notes regarding the last SFI visits, but unfortunately that is a false memory (or I've filed them in the wrong place), but I can assure you that the extra actions I detailed such as the L&S were carried out, the engineer was scrupulous in keeping me informed of all actions he carried out.

Yeah I'm not disputing what you're saying, I just can't find any record of the engineer advising us of this.

I swapped the original TG582n router for a spare, which I had been sent sometime ago, during the period April-June, I assume PN logs should be able to reveal the exact date?

Unfortunately our logs don't show what router you were using. 

The offer of a 2704n is appreciated, but no thanks, it is too 'locked down' for someone like me who likes to try and solve things myself, and is also incompatible with useful monitoring programs.

No problem that's cool.

I am unsure as to what 'fault' I can report - the connection is stable during the majority of the time, and speeds are within estimates, although they are a little below optimum due to the high SNR. Going through the raise a fault wizard will just return a 'no fault' response.

At this stage I'd monitor things and if your connection continues to drop out if you just click through at faults.plus.net it will allow you to report a fault regardless of whether the testing finds no fault as we can definitely see something isn't right somewhere so I'd be happy to arrange another engineer to investigate further. Having said that when the time comes if it's easier I'd be happy to raise a ticket for you on your behalf so you don't need to go through the wizard?

I assume the disconnection at ~1040 on the 27th was due to @Gandalf 's testing

Yup

[#12]

Yep - a little more detail on the ticket would have been very helpful, and would have probably stopped me making wild assumptions, but it still looks a bit coincidental to me - I'll probably review graphs and logs around that time over the weekend, just for my own curiosity.

As regards the engineer notes I appreciate you're not disputing what I'm saying, I'm just peeved I can't find my records.

Pity your logs don't show when I swapped routers, but no big problem - it would just be nice to know.

My connection appears to be fairly stable - I don't see any drops during the time I'm actually using the laptop, but as RouterStats has an annoying habit of 'losing it' when I'm not physically here, I can't easily spot what is happening between about 2200 and 0600/0700. I know it's a faff, but is there any chance of a  weekly RADIUS log for a little while?

I will continue to monitor, and if things start to go pear-shaped, I'll take you up on your offer of raising the ticket - you'd probably be able to word it better than me.

Thanks again.

[#13]

No problem and thanks for the feedback.

Feel free to nudge us and we'll be happy to provide you with a RADIUS log. Let us know how things go. 

[#14]

@Townman Update - Northern Powergrid have been back to me. They said they discovered a couple of insulation breaks which may have been causing the errors and have repaired them. I must admit things seem to have settled down, but I am still not convinced - I still suspect there are errors somewhere which the upping of my SNR to 15dB is masking. To be honest, I'm not too bothered, although the resulting drop in speed is a little disappointing, but I'll live with that for the moment

The better logging of the telnet facility is proving useful, although as there have been no 'funnies' since I installed it, it is difficult to make any .meaningful comments or deductions.

[#15]

That’s good news from the power co. The rectification of anything which might contribute to problems has to be beneficial. The only thing the 15dB SNRM is ‘covering up’ are those events you’ve seen during which sync is not lost.

Million dollar question - what do the SNRM plots look like now? Are there still transients of the ilk you’ve seen before occurring? If not I would recommend asking for a SNRM reset, for aside from the longer -9dB transient with the slow decay (of which you see only a few) the high SNRM is not delivering any benefit. The more frequent drops are not being addressed at 15dB so you might just as well run at 6dB.