cancel
Showing results for 
Search instead for 
Did you mean: 

SNR varying wildly

FIXED
EmilyD
Plusnet Help Team
Plusnet Help Team
Posts: 2,032
Thanks: 357
Fixes: 117
Registered: ‎26-03-2018

Re: SNR varying wildly

Hi @summers,

 

Thank you for getting back in touch and I'm sorry to see that you're still affected by this issue. I've tested your line and the test is showing underlying performance errors but hasn't picked up the cause of this:

xDSL Status Check
Circuit ID: CBUK85041091 Service ID: BBEUXXXXXXXX
Telephone NO.: NA Test Executed On: 29-11-2018 18:48:57
xDSL Status Test Summary
Sync Status: Circuit In Sync
General Information
NTE Status:   NTE Power Status: PowerOn Bypass Status:  
 
  Upstream DSL Link Information Downstream DSL Link Information
Loop Loss: 20.8 45.3
SNR Margin: 11.0 7.6
Errored Seconds: 0 2
HEC Errors: 0  
Cell Count: 83422 155449
Speed: 888 7672
 
Maximum Stable Rate (KBPS): 7392 Fault Threshold Rate (KBPS): 5913
Mean Time Between Retrains (Seconds): 8043 Mean Time Between Errors Upstream (Seconds): 40213
Indicative Line Quality: R Mean Time Between Errors Downstream (Seconds): 314
Custom Thresholds
MTBR_RED: MTBE_RED:
MTBR_GREEN: MTBE_GREEN:

 

At this stage, I'd agree with @Gandalf that this is likely to need an engineer visit so that it can be investigated further. However, if you've not done so recently, please can you run through our troubleshooting guides here. If the issue persists after this, please report it here and let us know when you've completed it so that we can progress things further for you.

If this post resolved your issue please click the 'This fixed my problem' button
 Emily D
 Plusnet Help Team
summers
Aspiring Pro
Posts: 275
Thanks: 50
Fixes: 1
Registered: ‎01-06-2014

Re: SNR varying wildly

Thank you @EmilyD. A couple of years ago I had horrible noise on the line (the BT box on the top of a pole had the outer covering come off, so all the contacts inside got corroded ...) anyway then I jumped through the hoops of checking everything at home. So most of my connection at home would come into the A1 category:

  • Master socket has a single adsl filter on it, that splits to my single phone and router
  • The adsl filter is one of the BT faceplates - the open reach engineer when fixing the old noise problem installed this.
  • The cable from the master socket to the router is a 1m adsl nation cable, so shielded twisted pair

Now as I stated above, when the BT cable enters the property it travels on 1970s cable to the master socket. As commented above, when I get central heating installed in my house, I'll change this to shielded twisted pair.

The line is quiet. getting the router to print the snr per frequency, and you can see that the line looks like typical noise for a 2.5km line to the exchange, which is the distance and what the copper test says. Now in this time round, so last couple of months I have not seem *any* significant noise on the line, all I seen is more noise over night, and sometimes a radio station getting about 5dB loader.

The problem I seem to have is SHINE, in happens just before 4am in the morning. I never see this as noise, I see it as an increase fec for a few seconds before the line goes down, when the line comes back up again (40s or so) the noise has gone. It is very short, it takes the line down.

So as I said above, when I get the only 1970s cable replaced, if the nosie is still there - from 6 months of monitoring, then I'll call for an engineer. But it will be a hard call from him to detect the few seconds on fec just before 4am every morning - lets face it there are logistical problems here.

Anyway back to where we are right now (btw I'm mainly using this thread to store the information I collect - so we have the full story on the thread, and there is a record of it).

Line went down last night 18:31:58 29/11/18 - looks like when you tested the line above. It came back at the same speed.

Line went down 3:49:26 30/11/18  it changed for 7dB of margin to 12dB of margin. The 10s before the line went down had 16234 fec 53 cv - so a digital noise storm.

I've all of this logged - I do plots when I get back this afternoon.

Oh yes found whats takes my script down, the adsl info returns error when the line goes down - and my script wasn't picking up on the error. Think I've now corrected all those, so error gets changed to a value. Will test next time line goes down.

summers
Aspiring Pro
Posts: 275
Thanks: 50
Fixes: 1
Registered: ‎01-06-2014

Re: SNR varying wildly

Now for the graphs. the 3s SNR before the line went down this morning - so this was with huge fec.

ADSL-18-11-30_03_49_23.png

So even with the fec, there doesn't seem any noise on the line. Now although the graph above has 3 recordings of the SNR, at second intervals, until the line went down; all 3 s are identical. So its clear that the SNR per bin, isn't updated at 1s interval in the firmware. I'll dig into what the fidelity is and change the script to match ...

Now how the margin has been since the last reset:

DownMargin27-30Nov.png

Where there are gaps is where my code when down, so typically it ran until the line went down, and then was restarted by hand some time later. So the recording up to where it stops is accurate. You can see the line resetting at 4am every day. I very strongly suspect this is when the DSLAM applies changes. Can plusnet confirm when the DLM runs and does an update to rate?

Now the mean time between error on downstream (where most errors are)@

27/11/18 -  477 seconds
28/11/18 - 281 seconds
29/11/18 before the line when down - 481seconds
29/11/18 after the line came back - 835 seconds

And finally there is something wrong with the speed on my line. My sync speed is 888kbps/6634kbps, but http://speedtest.btwholesale.com/ says:

Download speedachieved during the test was - 0.81 Mbps
 For your connection, the acceptable range of speeds is 2 Mbps-7.15 Mbps.
 IP Profile for your line is - 5.85 Mbps

Upload speed achieved during the test was - 0.25Mbps
 Additional Information:
 Upstream Rate IP profile on your line is - 0.83 Mbps

Townman
Superuser
Superuser
Posts: 22,919
Thanks: 9,536
Fixes: 156
Registered: ‎22-08-2007

Re: SNR varying wildly

One thing to keep clearly in mind here - when the line drops, it will resync AT THE TARGET SNRM.  Comparing SNRM across a line drop is like comparing apples and pears.

For example, if the target SNRM is 6dB and in the wee hours of the morning, due to radio interference, the line is in operation at say 3.5dB when a blast of noise drops the sync … it will resync at 6dB again … which might well be at a lower sync speed and therefore the FEC (and other) error rates would be proportionately lower.  In such circumstances, you might well see that the SNRM goes higher than 6dB during the day.

Unless the link remains up, you can place no reliance on the measurement of SNRM in isolation from the line speed.  This is one reason for a general recommendation that if you want the best speed, resync during the middle of the day, but if you want stability, resync during the dark hours so that the TARGET SNRM is established when there is the most continental interference about.

Superusers are not staff, but they do have a direct line of communication into the business in order to raise issues, concerns and feedback from the community.

ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: SNR varying wildly

I do have various old BTWholesale documents from when you could download all sorts of interesting things from the BTWholesale website without a login.

I still think the thing to do is have Plusnet attempt to configure the DLM so that it won't change the target SNRM, with the target SNRM then fixed at 6dB. Then while the DLM is not changing anything, you would be able to see if the disconnections still happen or not. I'd guess it's more likely than not that Plusnet will make the changes, but they won't actually work and the DLM will still keep doing whatever it wants anyway. But it would appear that there's nothing to lose by trying it.

summers
Aspiring Pro
Posts: 275
Thanks: 50
Fixes: 1
Registered: ‎01-06-2014

Re: SNR varying wildly

Well at the usual time 3:58:30 the link resynced at 15dB. It was *completely* quiet when the line wen down, no fec or anything - just lost the connection. Well the total fec downstream for the seconds up to when it went down were:

3300403:3300403:3300403:3300403:3301129:3305235:3309343:3309343:0:0

So you can see 3 seconds where the fec grew rapidly before line went down.  The SNR per tone for the 3 seconds before the line went down for a minute through when it cam back up again are:

ADSL-18-12-01-03-58-27.png

 

So although there is some variation (when there is a link) There is sod all in the way of noise.If you look carefully you can see a few individual tones changed from before the line went down to after - like the pilot tones changed ... Also there is no upsteam measurement after the line came back up ....

@ejs I'm mainly working from the kitz site, but that mainly based on the RAMBo set up - and looks from news stories that at least for a time openreach stopped using RAMBo due to copyright problems. Its not clear to me if they got round the copy right and started using RAMBo again, or if they started doing something else for DLM.

@Townman At the moment I'm just leaving the line up all the time, my line only varies by 1-2dB between night and day, and thats small in comparison from the swing  from 3dB to 15dB margin. On 15dB - which is what I'm on now, the line is so quiet that there aren't any stability problems - I will probably only have a handful of CV a day ...

So having gone through another training cycle (well still have to wait for the 10 days to run) - looks like all I have learn is that the line goes down just before 4am, that its probably the DSLAM taking the line down. That I don't anymore have noise on my line, beyond what you would expect for a couple of km of copper. My problem is that the DLM wants me to have 15dB of margin, and no one as far as I am aware knows why.

Thin all I can try after this is switching to the old Thompson router ...

Anoush
Aspiring Hero
Posts: 2,568
Thanks: 572
Fixes: 139
Registered: ‎22-08-2015

Re: SNR varying wildly

Something that ejs has mentioned we could try is setting a custom threshold at 86400s for DLM to work from, which in my understanding, it should mean that DLM won’t make any positive changes to your line, like dropping the target SNR down to 3dB, unless there are absolutely no errors.
Let me know if you’d like to give that a go.
This is my personal Community Forum account to help out around these parts while I'm at home. If I'm posting from the 1st March 2020, this means I'm off-duty with no access to internal systems.
If this post resolved your issue, please click the 'This fixed my problem' button
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: SNR varying wildly

RAMBo is just an arbitrary name for some part of the DLM.

I thought the ASSIA patent infringement issues only applied to the FTTC DLM:

https://www.ispreview.co.uk/index.php/2014/11/uk-court-appeal-rules-bt-fttc-broadband-infringes-assi...

https://www.ispreview.co.uk/index.php/2015/07/bt-and-assia-settle-dispute-over-fttc-broadband-linked...

The BTWholesale ADSL2+ DLM is a different system.

 

There are a total of 4 thresholds to set. Setting the red MTBE and MTBR thresholds to 1 in theory would prevent the DLM making changes negative changes, like increasing the target SNRM, which is what the DLM keeps doing to summers line for no apparent reason. Setting the green MTBE and MTBR thresholds to 86400 would prevent the DLM making positive changes.

summers
Aspiring Pro
Posts: 275
Thanks: 50
Fixes: 1
Registered: ‎01-06-2014

Re: SNR varying wildly

@Anoush / @Gandalf thank you for the offer, which is good of you - but I'm not sure what you are offering.

Changing the timing to once a day, but saying no errors in that time? Isn't ADSL 2+ intrinsically noisy? Isn't this why we have interleaving, and CRC, Error Correction? I don't know what it means for a line to have no noise. For me, we know that the DLM wants a margin of 15dB, on that I have a *very* low error rate, but its still there. So wouldn't that mean if a single error isn't counted as good, that my rate would always go down to 15dB.

Now as far as I can tell, my line is only going down when the DSLAM takes it down. E.g. the SNR shows no noise, and the FEC rate is close to the sample rate, vs 4106/4108 fec/s shown above. With this being the case, from what is known the DLM only works from Error Seconds.

Now my line stays up at all margins, from 3dB through to 15dB. It works reasonably at all settings. Always has interleaving on, but IIRC it was up at 96 when at 3dB. Now at 15dB interleaving is 32. But returning to time between ES, at 3dB I'm getting a steady stream of fec, so the ES are fairly common. I think we can agree that this is not desirable.

But from 6dB upward, the mean ES rate drops, the line gets more and more stable. I'll do plots of what we get for each, when training finishes, but its clear that I am well inside what the information in the public says is an acceptable rate.

So I think that no one understands why the DLM wants my margin to be 15dB. None of us understand what is wrong with the line. I have no noise, the ADSL SNR per tone, shows no unexpected noise, the fec rate shows no unexpected noise, the DLM believes the line is unacceptable. So what can we do? I think I'm probably between a rock and a hard place - how can one argue with the DLM?

So I'll probably have to live with 15dB, at least that gives me close to a 6Mbps downstream sync. I suppose I could set my router to lie, and report false margin, but what does this achieve?

All else I can think of is trying the Thompson router - once this learning period is finished ... That is a hassle for me, I have things set up on my current router that are convenient, e.g. it knows that 192.168.7.* is routed via my NAS, which has a beagle farm hanging off it on a 192.168.7.* sub net ... Can this be done with the Thompson router?

ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: SNR varying wildly

The DLM has 3 main classifications, red, amber and green. By setting the red threshold to the lowest possible value, and setting the green threshold to the highest possible value, the line should always be amber. It would never be below the red threshold, nor above the green threshold. Amber was an unfortunate choice of colour that makes it sound bad, when it's supposed to be classed as performing within expectations.

summers
Aspiring Pro
Posts: 275
Thanks: 50
Fixes: 1
Registered: ‎01-06-2014

Re: SNR varying wildly

@ejs thanks for your knowledge. Is this on your documents you downloaded, or is it on the kitz site? If the documents have more information than the kitz site, can you email to me? If so, let me know and I'll pm you my email.

Me, I process information available, in this case whatever stats I can get - by training I read deep into the measurements, and look for effects. Like the fec at 4kHz, the same as the sample rate - too much of a coincidence to miss.

Why the DLM says my classification is red at 6dB margin, I struggle with right now. I see no pattern, so documentation is the old way to go ...

ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: SNR varying wildly

Fix

There's more information on the kitz website and it's more up to date. I've just looked at the MTBE red threshold for the Super Stable profile. In these old PowerPoint slides from 2009 when BT's ADSL2+ was new, it was 6000. According to kitz the MTBE red threshold for Super Stable is 3600 (since April 2014). Now it has occurred to me that according to your RRT data, and I think most of your stats, your line's MTBE is generally lower than 3600.

Now I am considering which of these two explanations for what's been going on here is the more likely:

1. The DLM is somehow malfunctioning and keeps raising your target SNRM for no reason, or it's somehow mysteriously picking up on some fault that rather strangely there's no trace of in any of the stats.

2. The DLM has somehow been set to Super Stable, and is doing exactly what you'd expect it would do on this setting and your line's performance data.

 

Basically, if the premise that the DLM is operating on the Super Stable profile is true, then everything else makes sense and there's nothing wrong with anything. It seems to be the simpler explanation.

Gandalf
Community Gaffer
Community Gaffer
Posts: 26,563
Thanks: 10,265
Fixes: 1,599
Registered: ‎21-04-2017

Re: SNR varying wildly

Checking the DLM threshold, it is indeed currently set at Super Stable. When setting custom thresholds, I normally choose 0 for the red MTBE and MTBR, and 86400 for the green MTBE/MTBR.

This should stop DLM from decreasing the target SNR to 3dB which may be the cause of the issue as when the SNR goes down to 3dB it could be that the line is panicking and increasing to 15dB soon after.

Happy to set the threshold for the red MTBE/MTBR at 1 as ejs has suggested as well as the green values to 86400 to try to prevent negative changes too like increasing the SNR target if you want to give that a go?

From 31st October 2022, I no longer have a regular presence here as I’ve moved on to a new role.
Anoush Mortazavi
Plusnet
ejs
Aspiring Hero
Posts: 5,442
Thanks: 631
Fixes: 25
Registered: ‎10-06-2010

Re: SNR varying wildly

All that needs to be done is set it to Standard stability!

Gandalf
Community Gaffer
Community Gaffer
Posts: 26,563
Thanks: 10,265
Fixes: 1,599
Registered: ‎21-04-2017

Re: SNR varying wildly

Happy to try that if @summers wants?

From 31st October 2022, I no longer have a regular presence here as I’ve moved on to a new role.
Anoush Mortazavi
Plusnet