SNR varying wildly
FIXED- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Help with my Plusnet services
- :
- Broadband
- :
- Re: SNR varying wildly
Re: SNR varying wildly
29-11-2018 6:47 PM - edited 29-11-2018 6:49 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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.
Re: SNR varying wildly
30-11-2018 11:02 AM - edited 30-11-2018 11:09 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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.
Re: SNR varying wildly
30-11-2018 2:55 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Now for the graphs. the 3s SNR before the line went down this morning - so this was with huge fec.
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:
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 MbpsUpload speed achieved during the test was - 0.25Mbps
Additional Information:
Upstream Rate IP profile on your line is - 0.83 Mbps
Re: SNR varying wildly
30-11-2018 5:35 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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.
In another browser tab, login into the Plusnet user portal BEFORE clicking the fault & ticket links
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.
If this post helped, please click the Thumbs Up and if it fixed your issue, please click the This fixed my problem green button below.
Re: SNR varying wildly
30-11-2018 6:16 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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.
Re: SNR varying wildly
01-12-2018 7:18 AM - edited 01-12-2018 7:38 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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:
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 ...
Re: SNR varying wildly
01-12-2018 8:12 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Let me know if you’d like to give that a go.
If this post resolved your issue, please click the 'This fixed my problem' button
Re: SNR varying wildly
01-12-2018 10:28 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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:
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.
Re: SNR varying wildly
01-12-2018 5:25 PM - edited 01-12-2018 7:38 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
@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?
Re: SNR varying wildly
01-12-2018 7:01 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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.
Re: SNR varying wildly
01-12-2018 7:44 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
@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 ...
01-12-2018 8:44 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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.
Re: SNR varying wildly
02-12-2018 8:02 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
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?
Re: SNR varying wildly
02-12-2018 9:27 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
All that needs to be done is set it to Standard stability!
Re: SNR varying wildly
02-12-2018 9:40 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Happy to try that if @summers wants?
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page