Downstream SNR varying wildly

[#1]

Thanks for that. Taking account of the stretched y-axis on your graph, the amount of peak-peak variation is similar to the attached, but the frequency of occurrence is greater than one might hope to see on a good day. It could just be the current propagation conditions your way (which will vary a bit because of weather systems - that doesn't mean raining or otherwise, it's more complex).
If you are capturing the data on a laptop, you could try running the laptop on it's battery for a couple of hours in the daytime and apart from the TP-Link make sure all other equipment is turned off and power supplies unplugged from the mains - other Computers, Monitors, TV sets, Sky boxes, cordless phones, mobile phones, fluorescent lights including CFLs, other low voltage lights and equipment, anything that may have a Switch Mode PSU etc.
See if it makes any difference to the SNRM. If it does, switching things back on one at a time and watching the effect might identify any noisy equipment.

[#2]

Went down at 5:30am on 5/3/16, for no obvious reason:

Quote

888 5688 888 5992 7.6 13.5 24.3 45.3 81 204 05:28:45 888 5688 888 5960 7.6 13.4 24.3 45.3 81 204 05:28:55 888 5688 888 5956 7.6 13.3 24.3 45.3 81 204 05:29:05 888 5688 888 5976 7.6 13.4 24.3 45.3 81 204 05:29:15 888 5688 888 5980 7.6 13.4 24.3 45.3 81 204 05:29:25 888 5688 888 5844 7.6 13.0 24.3 45.3 81 204 05:29:35 888 5688 888 5816 7.6 13.1 24.3 45.3 81 204 05:29:45 0 0 0 0 .0 .0 .0 .0 0 0 05:29:58 0 0 0 0 .0 .0 .0 .0 0 0 05:30:08 0 0 0 0 .0 .0 .0 .0 0 0 05:30:18 0 0 0 0 .0 .0 .0 .0 0 0 05:30:28 632 5664 888 5664 20.1 15.1 24.3 45.3 126 203 05:30:38 632 5664 888 5664 20.1 15.2 24.3 45.3 126 203 05:30:48 632 5664 888 5648 20.1 15.0 24.3 45.3 126 203 05:30:59 632 5664 888 5704 20.1 15.2 24.3 45.3 126 203 05:31:09 632 5664 888 5752 20.1 15.4 24.3 45.3 126 203 05:31:19

and the noise seconds etc:

Quote

~ # /firmware/dsl_cpe_pipe.sh pmcctg 0 0 nReturn=0 nChannel=0 nDirection=0 nElapsedTime=2086618 bValid=1 nCodeViolations=1150 nFEC=203624 ~ # /firmware/dsl_cpe_pipe.sh pmlsctg 0 nReturn=0 nDirection=0 nElapsedTime=2086623 bValid=1 nES=59 nSES=2 nLOSS=1 nUAS=204 nLOFS=0

so since last time

Quote

~ # /firmware/dsl_cpe_pipe.sh pmcctg 0 0 nReturn=0 nChannel=0 nDirection=0 nElapsedTime=577981 bValid=1 nCodeViolations=478 nFEC=86479 ~ # /firmware/dsl_cpe_pipe.sh pmlsctg 0 nReturn=0 nDirection=0 nElapsedTime=577998 bValid=1 nES=104 nSES=2 nLOSS=2 nUAS=152 nLOFS=0

so can nES go backward? I thought it was number of errored seconds.
ANyway no idea why it went down, and came back up with slower upstream. I have yet to switch on 10s logging of the error seconds, and noise per tone. Hopefully get the chance to write the code soon.

[#3]

That suggests some noise affecting the upstream at the time of resync, try a daytime resync if that's US SNRM that is 20.1 and it remains at that sort of figure.

[#4]

Finally got round to plotting the SNR per tone. Downstream is attached - to my eyes looks reasonably heathty, with some frequencies with bad noise on.
The upstream data makes no sense:

Quote

~ # /firmware/dsl_cpe_pipe.sh g997sansg 0 nReturn=0 nDirection=0 nNumData=32 nFormat=nSnr(hex) nData=" 00 00 00 00 00 00 00 00 00 00 00 00 D0 0D D0 0D D0 0D D0 0D D0 0D D0 0D D0 0D 50 16 70 12 00 11

E.g. what is going on with the D0 0D  bits?
Edit: I've added bits per tone taken at the same time

[#5]

Oh yes, to explain last graph a bit more. The reason I multipled the bits per tone by 3, is that 3dB gives a doubling in power, which doubles the S/R, which by the Shannon-Hartley  theorom gives one more bit. So if this logic is correct, multiplying bits per tone by 3dB should mean you can compare bits per tone with the S/R per tone. Whats interesting is it shows how much margin I have on my line, e.g. that I am ~14dB below maximal rate - and this is true across the whole band. Does mean I really need to get to the bottom of what is causing the problem, so really do need to find time to enable the auto logging of errors.
Bit anyoying that I can't interpret the upstream SNR, oh well - c'est la vie.

[#6]

Did you try a resync as per reply #107 ?

[#7]

No - alas been far to busy last few days. However I note that the line went down by itself on 08:44:06 on 10/3/16; and came back at 888 upstream -  which is my maximum. So yes I do have the occasional disconnect. I had hoped to switch on lcp logging, so I could check what was taking me down, but alas havn't managed to get that to work yet ....
Oh , just checked the logs:

Quote

632 5664 888 6200 20.1 14.0 24.3 45.3 126 203 08:43:56 632 0 888 0 20.1 .0 24.3 .0 126 0 08:44:06 0 0 0 0 .0 .0 .0 .0 0 0 08:44:16 0 0 0 0 .0 .0 .0 .0 0 0 08:44:26 0 0 0 0 .0 .0 .0 .0 0 0 08:44:39 0 0 0 0 .0 .0 .0 .0 0 0 08:44:49 888 5976 888 5976 7.7 15.1 24.3 45.2 74 204 08:44:59

So looks like it was a change in the noise margin, that went up to 15db. So definitly something not happy with my line.

[#8]

I suggest you get the line reset to a 6 dB target snrm, then monitor the errors that DLM monitor
1, Re-trains
2. Severe error seconds
3. Error Seconds
Also good to monitor
4 Snr
1 sample/min is sufficient

[#9]

Correct me if I'm wrong (I haven't read over the entire thread since I last commented on it) but isn't that what summers has been doing since Reply #58 

[#10]

Yes, thats the plan. But first I need to set up the logging of error seconds and snr (per tone). I'm aiming for 10s resolution, as that is enough to cover most disconnects.
Harry: Currently logging US/DS current rate/maximum rate/SNR/attenuation and power - need to enable errors ..

[#11]

Yes, 1 minute samples may miss loss of sync events. 10 seconds usually works well (at least that's what we've generally found using RS on the TG582n & others).

[#12]

Another 15 minutes of digging - need to make sure I'm on top of all commands, so I log the right stuff.
Whats interesting now, is ppp goes down at times, while the ADSL2+ stays up! e.g:

Quote

8 2016-03-09 03:00:53 PPP Warning ppp0 LCP down 9 2016-03-09 03:00:53 PPP Error ppp0 LCP down 10 2016-03-09 03:00:34 PPP Error ppp0 11 2016-03-09 03:00:29 PPP Error ppp0 User request 12 2016-03-09 03:00:21 PPP Warning ppp0 LCP down 13 2016-03-09 03:00:21 PPP Error ppp0 LCP down

Quote

632 5664 888 5888 20.1 13.2 24.3 45.3 126 203 03:00:03 632 5664 888 5792 20.1 13.0 24.3 45.3 126 203 03:00:14 632 5664 888 5860 20.1 13.2 24.3 45.3 126 203 03:00:24 632 5664 888 5864 20.1 13.2 24.3 45.3 126 203 03:00:35 632 5664 888 5880 20.1 13.3 24.3 45.3 126 203 03:00:45 632 5664 888 5812 20.1 13.0 24.3 45.3 126 203 03:00:56 632 5664 888 5824 20.1 13.1 24.3 45.3 126 203 03:01:06

Now the ppp details I can only see through the log on http, need to see how to access ppp info from telnet.

[#13]

Sigh, went down again this morning:

Quote

1 2016-03-12 04:59:07 PPP Warning ppp0 LCP down 2 2016-03-12 04:59:07 PPP Error ppp0 LCP down 3 2016-03-12 04:58:19 PPP Error ppp0 4 2016-03-12 04:58:19 PPP Error ppp0 User request 5 2016-03-12 04:58:08 PPP Warning ppp0 LCP down 6 2016-03-12 04:58:08 PPP Error ppp0 LCP down 7 2016-03-12 04:58:08 PPP Error ppp0 User request

And this one did an adsl resyn as downsteam rate dropped to 632. I really am going to have to find time to write the code that processes error. A good hour last night poking round the telnet interface, and failed to find a way to log the ppp lcp messages...

[#14]

Hi,
Just to confirm, you are aware that PPP can drop without a loss of synch?
It is losses of synch that you really need to be concerned about here.  Note also that a loss of synch, which resynchs at a different speed will lead to a drop of PPP at a later time when PlusNet updates their line profile.  You might have seen posts around here of people being aware of an improvement in synch speed, but seeing no improvement is data speed tests - this is why, either the profile has not been updated, or the PPP session has not been refreshed to "adopt" the new profile.
Are you no closer to identifying the source of the REIN?
As Harry suggests (without reviewing the whole of the thread) has the line balance etc. been checked recently by faults?

[#15]

Also don't forget that the PPP may drop during the early hours due to BT Network or Plusnet Network maintenance. 0200/0300 is not uncommon. Often reconnection is immediate but it depends on exactly where the maintenance is. Keep any eye of Service Status reports, next weeks - http://usertools.plus.net/status/archive/1457709100.htm