cancel
Showing results for 
Search instead for 
Did you mean: 

SNR varying wildly

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

SNR varying wildly

Hi - this is restarting and old thread of mine: https://community.plus.net/t5/Broadband/Downstream-SNR-varying-wildly/td-p/1303785

In that thread I noted a problem with noise on my ADSL line. Through the tread other @Townman and @ejs were both very helpful, and we came up with a way on tracking noise in the frequency bins.

I intended to write a script to automatically pick up on noise, and take a log of the noise - so I could see the time structure. Alas I got busy. But fast forward 2 years - and I updated my router to OpenWrt. This gave me the ability to do scripting on the router itself. I did this a week or so ago, and have been tuning the parameters on the code. It does a rolling average of the SNR, and then looks for instantaneous changes. So the code is sensitive to noise that switches on rapidly. This gives plots like the attached:

AdslNoise-17_15-2-11-18.png

So you can see a minor drop out between bins 210-290.

Anyway its clear that my upsteam rate, due to noise has been band limited to 635kbps. Can @plusnet reset my ADSL line, then hopefully my script will log the noise that causes it to become rate limited. I can then hopefully find a pattern and trace down who is causing it ...

Thanks,

David.

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

Re: SNR varying wildly

Hi David,

Nice work!

As a first step it could be worth while looking up the frequency values for those bins and see if these belong to a radio station, possibly on a local infil mast.

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.

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

Re: SNR varying wildly

@Townman  Yes you can see the frequency content by looking at the difference:AdslNoise-17_15-2-11-18-diff.png

You can see its largely a single in the 254 bin, this was present in the signal before - so you can see its an RF signal with modulation that increased in strength by 8dB or so. Its frequency is about 1092kHz.

This isn't enough to take the line down, you can see that my margin is 15-20dB at the mo, so it needs something worse than this to take it down.

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

Re: SNR varying wildly

Here is a plot taken from 11:03 this morning (Sunday). Increased Noise from bin 250 upwards. Interesting block at bin 340 or so where 15 bins or so have been knocked down 5dB or so. Quite odd.AdslNoise-11_03_21-4-11-18.png

Oh yes - one thing need to change in my script is how the bits per bin, are changed into data - in particular what the sample rate is. I did the calculation according to Shannon-Hartley theorem, that says that the maximum sample rate is the bandwidth, in this case 4.3125kHz. But using that and I get upsteam ~ 1.7Mbps and Downsteam 16Mbps - and I'm not getting anywhere near that. So it looks like the sample rate is about half that , e.g. 2kHz. This must be in the adsl spec somewhere - but I can't find it ...

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

Re: SNR varying wildly

I think graphs that record SNRM and errors over time would be more useful. I think the problem with all this SNR per tone data may be that you'll log lots of changes, many of which may have nothing to do with whatever the overall problem is.

 

Anyway its clear that my upsteam rate, due to noise has been band limited to 635kbps.

I think the upstream cannot be rate capped, and these SNR per tone graphs don't seem to show any problem with the upstream.

 

If the problem is really due to there being something wrong with your line, making it more susceptible to interference than it should be, then I don't think there's much point searching for sources of interference.

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

Re: SNR varying wildly

@ejs good thought - I'll add the error seconds etc to my script.

Current snapshot of my DSL stats:

DSL Status
Line State: UP [0x0]
Line Mode: G.992.5 (ADSL2+)
Line Uptime: 8d 20h 38m 26s
Annex: A
Profile: -
Data Rate: 5.752 Mb/s / 635 Kb/s
Max. Attainable Data Rate (ATTNDR): 6.288 Mb/s / 888 Kb/s
Latency: 8.0 ms / 8.0 ms
Line Attenuation (LATN): 45.8 dB / 21.0 dB
Signal Attenuation (SATN): 43.9 dB / 21.5 dB
Noise Margin (SNR): 14.2 dB / 20.0 dB
Aggregate Transmit Power(ACTATP): 20.3 dB / 12.6 dB
Forward Error Correction Seconds (FECS): 64813 / 5909
Errored seconds (ES): 127 / 7
Severely Errored Seconds (SES): 4 / 0
Loss of Signal Seconds (LOSS): 0 / 1
Unavailable Seconds (UAS): 46 / 46
Header Error Code Errors (HEC): 1010 / 22
Non Pre-emtive CRC errors (CRC_P): 0 / 0
Pre-emtive CRC errors (CRCP_P): 0 / 0
ATU-C System Vendor ID: Infineon 113.200
Power Management Mode: L0 - Synchronized

You can see the upsteam rate set to 635kbps, with a maximum of 888kbps, and a 20dB margin. This number has been stuck on 635kbps - rebooting makes no change. That to my mind indicates it has been banded. What do plusnet think?

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

Re: SNR varying wildly

@ejs Oh yes - what I forgot to say is that I'm triggering the recording SNR per tone, by a change in the sum of the SNR across all 512 bins. This should be similar to the change in Noise Margin. But I'll add that anyway. Current code can be seen on OpenWrt link

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

Re: SNR varying wildly

20180727.png

Which plot shows the thunderstorm better, SNRM or CRCs?

You are simply starting from the wrong data. However you process it is not going to make a difference.

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

Re: SNR varying wildly

yes point made, although a flash of lightening can just take out a single time slice of 232us, but take out many of the bins, and cause an error. Not much noise is that short time extent.

Difficulty for me, with 20/14 dB margin is that I get very few error seconds a day, the only error rate that has any rate to it is FCES, and there I have 7000 a day - or two hours worth.

Anyway I'll switch on logging for that, route should have enough memory to record a day at a time, before emailing ...

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

Re: SNR varying wildly

Oh yes -impressed at how flat you noise margin is, you must live on top of the cabinet or something. I get much more variation at dawn/dusk ...

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

Re: SNR varying wildly

OK - am now also logging most of the ADSL stats. Reminding myself the the TP-Link only updates some parameters on initial connection - and doesn't update them. So I can't give useful variations in attenuation. Noise margin is updated, so am recording that.

I'm guessing its worth recording FECS and ES as well as FEC and CV, as plusnet works from the ES on setting the link? Anyway so far all of these are fairly benign - no thunderstorms here last night.

Looking at the noise per bin, when noise occurs - bad noise is always broad band, and usually seems better coupling between the line and the noise (e.g. whole curve drops, including the part taken out by an RF transmission - so better coupling to everything including the RF noise).

For the noise margin, below is this morning on downstream. Upstream varies between  19.3dB and 20.3dB.

adslstats-18-11-9-dnm.png

This looks fine to me, so I'll put in a ticket to have the line reset.

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

Re: SNR varying wildly

Is the relationship between bits and data flow known?

E.g. my line has been reset. In the upstream  direction I have 273 bits active, at 4.3125kHz sample rate this gives a data rate of 1150kbps. The link is currently running at 888kbps. So this suggests that of data sent, only 77% is read data, the rest is going on CRC checks etc.

So is this overhead known/described anywhere? Would be useful for my scripts ....

Oh yes - line was reset earlier - so now have 11.4dB Margin upsteam, and 6dB downstream.

And getting FEC maybe 5% of the time. Think I have had 1ES so far. Anyway this is in daylight - when the connection is easy - so I'll see how the connection goes tonight ...

Jubby
All Star
Posts: 626
Thanks: 111
Fixes: 31
Registered: ‎06-08-2018

Re: SNR varying wildly

Hi @summers,

After testing the line, it appears stable and is operating above the estimated speed.

I cannot see any banding on the upstream or downstream however, as per your request the line has now been reset. Please reboot your router 4 hours from now.

Feel free to get back in touch if we can be of further assistance.

Thank you.

If this post resolved your issue please click the 'This fixed my problem' button
 Lewis G
 Infrastructure Operations Professional
summers
Aspiring Pro
Posts: 275
Thanks: 50
Fixes: 1
Registered: ‎01-06-2014

Re: SNR varying wildly

Thanks @Jubby ,

Yes this morning Shane Russel reset my line, put it in a learning loop and removed the banding.

As it was reset at 11am, came up in day at low noise @ 6dB downstream. As dusk marging dropped to about 4pm, and line went down and came back at 6dB. Its been stable at that since.

AdslStatsSNRDown18-11-9.png

During the time it was up the Mean time between error seconds was 563s down stream and 2926s up steam.

Now that it has reset at 6dB during night - am hopeful it will stay stable. I'll keep monitoring.

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

Re: SNR varying wildly

And tracing where it went from 7pm to midnight. The downstream margin stayed at about  4.5-5dB. The meant time between error seconds was 368s downstream.

Then from midnight to now, 4pm the downstream margin improved from 4db to between 5-5.5dB. The mean time (downstream) between error seconds was 389s.

So its been stable so far.