SNR varying wildly

[#1]

@Gandalf,

Where is this going?

There is good evidence here that resetting the SNRM gives better speeds until an event happens and then the DLM whacks it back to 15bB.

There is some indication of a transient event happening in the early hours of the morning.

Do the CLT results indicate anything which might point to this circuit being more susceptible to REIN rather than rejecting it?  If the trigger event is in the wee hours of the morning, there is zero chance of BTOR REIN engineers getting out of bed to investigate … so where does this case go, beyond being blighted with a high SNRM or a locked down lower SNRM with the acceptance that the line might well disconnect occasionally and then just keep on trucking?

[#2]

Thanks @Gandalf, suspect what happened is you could see the graphics as you were logged onto bt wholesale with your user account that showed the graphics, but we here aren't on with your account!

Yeah I suspect that's what has happened. Sorry about that.

Reset the SNR - yes I think that would be helpful. 

I've done that for you now. Could you reboot your router in about 4 hours time letting us know how things go over the next few days?

@Townman wrote:

Where is this going?

Likely towards an engineering investigation.

Do the CLT results indicate anything which might point to this circuit being more susceptible to REIN rather than rejecting it?  If the trigger event is in the wee hours of the morning, there is zero chance of BTOR REIN engineers getting out of bed to investigate … so where does this case go, beyond being blighted with a high SNRM or a locked down lower SNRM with the acceptance that the line might well disconnect occasionally and then just keep on trucking?

Line tests don't show any issues.

Copper Line Test
Circuit ID:	CBUK00000000	Service ID:	BBEU00000000
Telephone NO.:	NA	Test Executed On:	26-11-2018 12:38:57

Status:	Pass	MFL:	OK	OR Test ID:	dys00556dat01:140915303
Test Outcome:	CIDT LINE TEST OK - END USER EQUIPMENT DETECTED			DTR:	T300

Copper Test Details
	A to E	B to E
Capacitance:	248 NanoFarad	250 NanoFarad
DP Line Length Estimate:	2475 Metres	DN Line Length Estimate:	2543 Metres
Celerity:		Line Loss:	38.3 dB
Line Stability:	Stable
Fault Report Advised:	N
Service Level:	2
BRAGOutcome:	Good
Faceplate:	Not Detected

Ultimately I think the next step is for an engineer to go out and investigate further as it sounds like everything that can be done so far has been done.

[#3]

Personally I'd skip the needless router reboot, especially if @summers can see when the SNRM change has happened.

The only evidence of a problem appears to be the DLM's behaviour, it's not even clear that the disconnect in the early hours of the morning isn't merely when the DLM is increasing the target SNRM. One way to clarify that would be to stop the DLM increasing the target SNRM and see what happens.

Does summers get to use the "but the engineer was Plusnet's idea" reasoning for not having to pay any no fault found engineer charge?

[#4]

---

@ejs wrote:

Personally I'd skip the needless router reboot, especially if @summers can see when the SNRM change has happened.

---

When I get home (am still at work). I'll check if the connection has been reset during today. If its reset, I won't need to reboot the router; but if it hasn't I'll unplug the phone line for 30 minutes or so whilst I eat food - that way it shouldn't be classed as a disconnect.

Then see what logs I get. Am half wondering what to do if I see FEC and CV again, but no signs of anything in the margin. To me that would seem to mean these is a digital problem somewhere, either in the DSLAM, or more likely in my router. I know that some German routers use the same chipset, and are on version 5.9 of the firmware driver - if so and I can manage to unpack it, I should be able to update from 5.8.

[#5]

Netgear started off with a 5.8 in their initial firmware for their DM200 modem, but then went back to 5.7 versions in all later DM200 firmwares.

The .bin files in FritzBox firmware are customized - you don't find any "AVM" strings in ones from elsewhere.

[#6]

Yes, I think your right, its the Fritzbox is where I've seen 5.9 firmware code. OK - so if tried need to take care with it. Seems a pity that the assembly code for the DSP hasn't been published that I can find ...

Anyway when I got home, the connection had reset to the new margin of 3dB. But errors are huge, it will take the line down soon. My guess is that the average fec per second is about 100! Mean time between error seconds can only be ~100s at tops, maybe fair bit lower ...

Its generating logs at a huge rate - probably more than I can convert. But I'll do some. Also my code *still* crashes when the line goes down, its the error code that the firmware interface generates - need to work out how to catch it ....

[#7]

@ejs wrote:

Does summers get to use the "but the engineer was Plusnet's idea" reasoning for not having to pay any no fault found engineer charge?

As we can see there's a fault somewhere I'd be surprised if we'd pass on a charge if an engineer found no fault, but other aspects of the charge like if it lay with internal equipment would apply.

@summers, just a thought and sorry if you've tried this already, but do you experience the same problem using a different router?

[#8]

I've an old Thomson 585  router that plusnet supplied when I first signed up - could try that if you think it may help. Let me know - to my mind the quality of the TP link router was better, but @ejs may disagree.

Re: the engineer. I'll be having work done on my house, probably in the next 6 months, to install central heating - so all floor boards taken up. As pat of this planning to change the wire in the house that is *nominally* owned by BT. Its quite old now - must have gone in the the 1980s or so or earlier. So I'd like to change it to shielded CW1308 when I get the work done on my house. That would be the natural time to get an engineer out, if the problem still exists.

Much to my surprise the line stay up last night with 9k downstream speed, and oddly enough at 4:54 this morning the margin improved to 5dB with no change in speed. This has lower the error rate significantly. I'll see if it stays up (as well as working on how to cope with the code crashing when the line returns an error). I've only seen jumps in margin like this when under training, so not sure what training is being tried ...

[#9]

A 2dB shift in margin as dawn approaches (loss of continental FM radio interference) is not untypical - it could though be your potential source of REIN dissipating!

[#10]

---

@Townman wrote:

A 2dB shift in margin as dawn approaches (loss of continental FM radio interference) is not untypical - it could though be your potential source of REIN dissipating!

---

OOps forgot to say that the 2dB shift happened over a 10s period. It was still dark for just over an hour after the jump, so I'd expect the ionosphere still to be active ...

[#11]

Are you rural near a dairy farm perchance?

Or near an electric rail line?

[#12]

I live in a fold of the landscape in Bath. So the immediate area is rural, a farm opposite - different direction from the phone line, and probably 500m away.

I'm end of the line from the cabinet. So line from my house go overhead up to the next road/ It goes over the top of an electricity sub station on that road. At the road level it goes underground, and probably has about 1km to go to the cabinet. The cabinet is probably just over 1km from the exchange.

So sum of those  two is the 2.5km in the copper line test.

So no my line doesn't go near a venture that is active at 4am, like a farm. When I've looked at the electricity sub station in the past, its putting out noise on MW, but wasn't correlating to any time structure that I have. If I confirm the 4am structure - the sub station is the first think I'll check at that time.

Oh yes - the route from the cabinet to the exchange does pass a electrified rail line. But if that was the problem it would affect all of the south of Bath ...

[#13]

---

@summers wrote:
Much to my surprise the line stay up last night with 9k downstream speed, and oddly enough at 4:54 this morning the margin improved to 5dB with no change in speed. This has lower the error rate significantly. I'll see if it stays up (as well as working on how to cope with the code crashing when the line returns an error). I've only seen jumps in margin like this when under training, so not sure what training is being tried ...

---

Perhaps it's actually that you only see jumps like that when you've got a lower target SNRM. There aren't really 10 days of training. All that really happens is that the lowest speed in those 10 days gets used to calculate the Fault Threshold Rate. Maybe the DLM will be slightly more active during those first 10 days, but it doesn't stop doing anything after the 10th day.

[#14]

---

@ejs wrote:

Perhaps it's actually that you only see jumps like that when you've got a lower target SNRM. There aren't really 10 days of training. All that really happens is that the lowest speed in those 10 days gets used to calculate the Fault Threshold Rate. Maybe the DLM will be slightly more active during those first 10 days, but it doesn't stop doing anything after the 10th day.

---

Hi, why do you say that the behavior isn't really different in the 10 days of training? E.g. where did you get this information?

So for me, line was reset on the 10th, the graphs through to the 19th showed jumps - see post on page 3. But once the 20th was reached the line was more stable. So without the line being reset, of there a being change in in downstream rate, the behavior of the margin changed markedly before and after the 10th day after the reset.

After last reset - my line has actually stayed up at the initial rate of 9Mbps downstream - errors are there at a higher rate (i'll process in a few days) - but line is staying up. Haven't yet seen any of the fec/cv storm that took the line down before!

[#15]

Since the line was reset on the 26-11-18, the line dropped for the first time this morning, at the familiar time 3:53. Alas it took the script down, wish "ash" gave some better errors, I think a commend like "dfecd=$((${fecd}-${fecdl}))" is failing - probable something like the "${fecd}" expands to include a "))" which completes the arithmetic expression early ...

Anyway it was recording the noise per tone when it went down, so I have the last recorded signal before it went down, so within a second of it going down it is:

Now there is clearly a bit of noise on there - which given it was night and the ionosphere was active is maybe not a surprise. Anyway nothing huge. Its a bit strange that the noise floor beyond bin 430 or so rises towards 512, usually it flat all the way out.

So anyway the logs before the line went down didn't show any excess errors of any kind.

If I was a guessing man, I'd say probably the DSLAM took the connection down so it could add in 3dB of margin. Which is what happened. Now the margin is about 8dB ...

Just a thought https://community.plus.net/t5/Library/Dynamic-Line-Management-DLM-on-ADSL2/ba-p/1322344 says that in training lines are typically reviewed daily. Could it be that and change that the DLM decides to make just affects my line at just before 4am each day? How could I test this? Maybe following interleaving, as e.g. can that be modified without taking the line down?

Hmm, BT nolonger uses RAMBo https://www.telecomstechnews.com/news/2014/dec/09/bt-rambo-patent-infringement-could-reduce-service/ so this probably applies to plusnet as well? if so what DLM system does BT/Plusnet/openreach use?