cancel
Showing results for 
Search instead for 
Did you mean: 

SNR varying wildly

FIXED
summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

Now I'm running at lower margin, its interesting looking at some of the effects. What surprises me is the occasion second that has huge fec, like a count over 1000! When the count goes over 2000 - seems associated with a CV and hence ES.

So wonder, is it worth tracking these. E.g. if i get a fec over 1000, is it worth recording the spectrum to see where the noise is coming in?

summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

So now have had the first full day of the line being monitored since the margins were reset. The margins measured over 10/11/18 where:

ADSLStats18-11-10-margin.png

So upstream fairly constant on 12dB. Downstream about 5dB. And oddity happened at ~7pm, the downstream margin jumped from 4dB to about 6dB. As far as I can see the line wasn't reset there. So all I can guess is that the power output was changed - not much else makes much sense.

There error seconds, well none upstream. Downstream I had 250, which give a mean time of 346s. From what I can see of training, that counts as *just* about acceptable.

So far, no real sign of the bad noise I had two years ago, and what led to the line being limited ...

Community Veteran
Posts: 5,217
Thanks: 493
Fixes: 22
Registered: ‎10-06-2010

Re: SNR varying wildly


@summers wrote:

So upstream fairly constant on 12dB. Downstream about 5dB. And oddity happened at ~7pm, the downstream margin jumped from 4dB to about 6dB. As far as I can see the line wasn't reset there. So all I can guess is that the power output was changed - not much else makes much sense.


I'm not sure how you have reached that conclusion, the ADSL power output isn't going to change. More likely to have been a reduction in the noise level - probably something somewhere was switched off.

summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

Well from the frequency response, I can see the event - it wasn't enough to trigger it being recorded. At least one frequency bin changed by 32dB, and across several frequency bins there was a total of 250dB change. It was just below the threshold where I record.

Anyway if it was that, whatever it was on for at least 19hours, and been off for the next 19 hours. So not something that is switched all that often.

I've a frequency plot from 6:30pm last night - and have done one now So to compare:

Last Night @ 18:33: AdslNoise-18_33_08-10-11-18.png

And just now:

AdslNoise-14_41_15-11-11-18.png

summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

And here is comparing the 10minute rolling average of those times.

AdslNoise-Diff-10-11.png

ANd given that then 18:33 was when the ionsopehere was cutting in - is there really that much difference?

summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

On sunday 11/11 had very few errors, only 137ES downtream all day. So thats 631s mean time between ES.

Alas though the line went down at 4am this morning, and ressynced to a lower speed. Just trying to get hold of the logs now, lost some of the interesting ones - as they are sent via email, which doesn't work well when the line is down ....

Margin on the 11/11 between 5-7dB down stream all day. 12dB upstream

ADSLStatsMargin-18-11-11.png

summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

What took the line down was 3 seconds:

Those three seconds had 21414 FEC Downstream, and 142 CV.

So for 3 seconds the line just went bizare. Now whats hard is how do I do a script that would pick up on the start - and try and capture the frequency content? That seems hard without monitoring every second.

Anyone any other ideas?

summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

Sigh and it went down 3:47 last nigh as well - so looks like the same time. So question is who switches something on at 4am.

Alas this time it took down my code -I'll have to check why.

Speed has dropped again I'm probably down the 12dB now. So whatever happens its enough to change the speed. Alas the last numbers I had before code went down make no sense - everthing is -ve when should be +ve ....

summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

Here is noise margin, as it kept resetting at 4am. You can see it getting worse and worse.

 

Seems strange that 3 seconds is enough to take the line down, but seems to be.

 

Think I worked out why all numbers when -ve, I look at the difference between most counts - so I see how many counts in the last 10 seconds. Well looks like when the line went down, all counts where reset. Seems very odd.

ADSLStatsMargin-18-11-11-14.png

Plusnet Help Team
Plusnet Help Team
Posts: 10,032
Thanks: 3,180
Fixes: 506
Registered: ‎21-04-2017

Re: SNR varying wildly

Hi @summers

I'm sorry to see you're still experiencing issues.

While we're not finding a definitive cause for the problem and that your connection is stable, something doesn't seem right somewhere as the SNR target is currently at 12dB, so the DLM looks to be trying to sacrifice speed for stability.

I'd recommend reporting a fault to us at http://faults.plus.net letting us know over here when you've completed it so we can pass this on to our suppliers for further investigation and potentially arrange an engineer visit.

If this post resolved your issue please click the 'This fixed my problem' button
 Anoush Mortazavi
 Plusnet Help Team
summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

Thanks @Gandalf,

Well I did half expect problems, because in the past whenever plus.net reset the line, in a few days it has gone back to a large noise margin. Its why I have so much code looking at the line - so I can see whats causing the problem.

Line went down again today at 14:17:19 - same problem as last time, in 2 seconds I had 5646 fec and 77 cv - that looks like it took the line down at once.

Whats strange is again after about a minute  it caused the all the counts to reset - which gave negative differences, and caused my code to crash - at least I have an idea what is making it crash now ... so can hopefully cure that. Also now having a better idea what is taking the line down, I can start looking at that in more detail - e.g. if I see more than 1000fec in a second, then I know the line is close to going down, and so any data then is useful.

Seems a pity, expect for an occasional second with high fec and cv, the line seems  quiet - with a reasonable mean time between faults ...

summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

And went down again at 3:46:08 this morning - and I'm now at 14dB margin. At least the time is consistent - so now need to find something switching at that time in the morning.

Took the line down the same way as before, huge fec and cv. In this case 3s, 10897 fec and 150 cv.

I'll write a script that explicit checks that condition, and runs every second. Problem is these events are short - so it needs to be tight monitoring if I'm to see it.

Also need to work out how to get data of the router via scp, at the moment it does email - and that fails when the line goes down. scp - and i can keep the traffic internal to my network; problem is havn't yet got it working without a password - dropbear does its authentication somewhat different from open-ssh ...

 

summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

Find below the downstream margin. plotted the time period just before 4am. You can see on 12,13,16-11-18 it went down between 3:46 and 3:49 (So Monday, Tuesday, Friday). This is due to between 2-3 s of huge fec (>1000) and associated cv (~100) in a second. That takes the line down and gives a resync. Now apart from this the fecs and cvs aren't too bad on the line. So I'll set up a close loop to see if I can see whats happening - but git feeling is must be fairly broadband noise to cause so many fec and cv.

ADSLStatsDownMargin10-16-11-18.png

Community Veteran
Posts: 5,217
Thanks: 493
Fixes: 22
Registered: ‎10-06-2010

Re: SNR varying wildly

I'm not sure what you're expecting to find apart from the fact that the connection dropped. The connection dropping once a day shouldn't be enough to bother the DLM anyway.

Have you tried a different modem?

summers
Rising Star
Posts: 198
Thanks: 17
Registered: ‎01-06-2014

Re: SNR varying wildly

@ejs well there is far more info on the connection, take it as a whole:

First consider error seconds a day:

10/11/18: Up: 0 Down: 250 mean time between ES: 346s
11/11/18: Up: 0 Down: 137 mean time between ES: 631s
12/11/18: Up: 50 mean time 1728s Down: 162 mean time 537s
13/11/18: Up: 25 mean time 1070s Down: 59 mean time 453s
14/11/18: Up: 0 Down: 20 mean time 4320s
15/11/18: Up: 33 mean time 1949s Down: 35 mean time 1837s
16/11/18: Up: 1 mean time 86400s Down: 31 mean time 2787s

So you can see that the noise on my line measured by ES isn't all that bad, and this includes the line going down ES. [Note have modified the 14/11/18 number for an obvious mistake]

Then look at the events that took the line down and gave a speed change:

12/11/18: 3seconds: 21414fec and 142cv
13/11/18: Modem reset - so no stats
16/11/18: 3 seconds: 10897 fec and 150 cv

Now how do you read this data. To me it says that the events that took the connection down were quite extreme. What would give rise to the change in margin, to me all I can see is the extreme seconds that took down the line. So how do the Plus net DSLAM react during learning, what are there decisions based on. reading the above and my guess would be that either a 50cv in 1 second, or 3000fec in a second has an effect - but only plus net can confirm.

Then the fec and cv are on down link only - so now you can see that although the noise must be taking out  a far few frequencies, it isn't going down to the uplink frequency. So hence it would be worth getting a plot - as then you know what to tune the MW radio to; as lets face it the stats say you are only going to get a 3s slot on some days just before 4am to detect this. So as I'm looking at having to get up a 3:30am for many days, and standing outside possible causes with a radio - maybe you can see why its a plan to get as much info as possible first.

So what in this approach do you see as wrong? How could it be done better?

Different modem - well the thomson that came with the broadband - its a fairly naff basic router - the TP-link is better quality. And given that I'd have to redo my scripts with the thomson, maybe you can see why I'm a tad hesitant to do so. Have you ever heard of a modem going down at 4am every morning? That sounds like a conspiracy to me, and i don't believe in those ...