Downstream SNR varying wildly

[#1]

No problem. I escalated the ticket back to you when I made the change, it will close itself automatically in 14 days providing you don't respond. Obviously please do respond to it if there are any further problems in the meantime.

[#2]

Thanks harry. After initally connecting at 6db margin, with the decreased SNR overnight, this dropped to about 3db margin. Connection was stable overnight. So looks like problem solved.
I'll upload some graphs, of before and after, then probably close this thread (well stop posting).
I'll leave the router monitor running, probably backed off to 10s, to see in the REIN returns.

[#3]

Looks decent from our side of things. The drops around 3pm will have been changing the SNR target and testing the line
<img src="http://community.plus.net/visualradius/generated/image14550185634563.png"/>

[#4]

Odd you saw a disconnect at ~11pm, that didn't show up here:
And this was with 1s recording, where I'd see any disconnect, as it takes more than 1s to reconnect. I show the reconnect at 3pm. Both graphs are DS noise margin btw

[#5]

The caption on the top graph says 10pm  is it a GMT /UTC /BST problem  have you the graph from 11pm to 12pm

[#6]

The visual radius shows when the PPP session disconnects and re-connects, it's quite common for there to be a PPP drop while the ADSL link remains connected. It could have been the Plusnet Current Line Speed updating in this instance.

[#7]

My graph was GMT, as I'm pretty sure the radius log was as well. As both show the disconnect at 3pm when the noise margin was changed from 14dB to 6dB. Kept the line down for almost a minute.
So the Radius log showed a disconnect and rapid reconnect between 10pm and 11pm - and so thats what my graph shows.
ejs has a good point, that yes I havn't thought about. ADSL sets up a uart (of kinds) that establishes a serial connection across multiple frequencies. Now I guess much of the frequency split, and multiplex, I would guess would be done in a specific hardware implimentation, leaving a uart exposed to the router OS. Router OS then takes the serial connection, and builds a ppp connection on top. So taking down the ppp conection is interesting - that would take an explecit ppp  instruction, probably lcp - as between the ppp connection on each end is the hardware doing the frequency split and uart.
Hmmm - must be in logs, lets look:
1 2016-02-08 22:47:15 PPP Warning ppp0 LCP down
2 2016-02-08 22:47:15 PPP Error ppp0 LCP down
3 2016-02-08 22:46:51 PPP Error ppp0
4 2016-02-08 22:46:51 PPP Error ppp0 User request
5 2016-02-08 22:46:43 PPP Warning ppp0 LCP down
6 2016-02-08 22:46:43 PPP Error ppp0 LCP down
Bingo, ejs - yes ppp was taken down. Hmmm wonder now if I can switch on LCP debugging and see what command was sent. Alas thats setting ppp into debug mode. Simple config file, but will take a hack of the router ...
FInd below the noise margin for the relevent time. Indeed no drop of the ADSL connection. How intersting.
Other intersting thing, is even though recording the modem parameters every second, it shows the modem only updates it figures every 2s ...

[#8]

Since reset, had first genuine drop today at 9:59. Noise margin was at 3.9dB when it disconnected, and reconnected at 9dB noise margin. Wonder what caused the reconnect. (More tempted to hack the router and switch on ppp debugging so I see the LCP messages)
Actually maybe I'm just wondering too much at the moment, broadband is up more stably that it has been for the last two years, so I shouldn't complain ...

[#9]

Can you post the SNRM and Sync graphs showing the drop? I'm wondering if DLM has taken a dislike to possible high errors?
An xDSL Status check by someone from CRT may give us a clue. Also have a look at your xDSL error stats.

[#10]

xDSL Status check:

Quote

Downstream Link Info Loop Loss: 45.3 SNR Margin: 6.6 Errored Seconds: 1 Hec Errors: N/A Cell Count: 189740 Speed: 8053

On a side note, the upload is capped at 440. I'll get an order placed to get that uncapped while I'm on it. That should be complete by tomorrow

[#11]

Thanks harry. Yes I'd noted that upload was limited to 440 - but that never given me a problem, so I didn't worry about it. Looks like it will only go up to 888 anyway, but looking at the bits per frequency  - I should have no problem with ~888.
Errors - well not recoreded. But currently http says 0 pkts error - which I take to mean none that weren't corrected, how many corrected - well not avaiable on http. It may be avaible via telnet - but I'll need to take down current logging (as it locks the single telnet connection), and rewrite the logging code. Won't get time for that till sunday.
So we just have Harrys numbers.
Find attached the downstream noise margin for today. You can see the reconnect at 10am. Before 10am, it had previously synced at 6dB, so is down 2dB since then. After reataching it initially connected at 9dB, but quickly climbed until 9.5dB, until night fall.
Oh yes, had another ppp disconnect at 19:35, when adsl stayed up.

[#12]

Uncap of upstream speed worked fine, and sync at 888.
Whats not enoucharging though, had another drop of line. It dropped out at 1:45am this morning. Line looked stable before the drop - no signs of noise, and good noise margin (6.6dB). So seems clear that something is causing the line to drop, but alas there is no indication of what in the current logs.
[Edit: Strike that, found the cause of the 1:45drop - it was the resyncing of the upsteram from 444 to 888, so it makes sense as a remote resync.]
[reEdit: Oh just noticed a nice side effect of the upsteam sync being at 888 vs 444; my ping time has gone down from 60ms to 40ms! This is just to the first machine outsite (gateway in ptn)]
So looks like I'll have to switch on more logging on the TP-Link. Alas quick google on info thats avaiable on the telnet cli, and TP-Link doesn't sound good for error logs. So its sounding more like I'll need to hack the router, at least its openwrt inside - which I have experience with, so should be able to switch on more logs (well hopefully find a way of rejigging the lantiq firmware for the ADSL for more diagnostic info)

[#13]

This could be DLM testing different conditions during the 10 day training since your snr reset. I'll need to look at this again  I've only glanced quickly. Harry might have more info from PLusnet's side.

[#14]

And yesterday it resynced to ~16db Noise margin. See attached graph.
Have no idea whats causing it, looks like during the training period, that the exchange isn't happy with my line. But connection looks fine on myside. Now during training, I've disconnected twice myself (24 hours appart) to put in ejs changes to acess full telnet on the router. Other than that on my side its been up all the time, but I can see there have been a few ppp dropped sessions.
Anyway I'll look at enablng more logging on the tp-link, its a bit of a hassle, as the root file system is read only, so its not really viable to make configuration changes.
On yes, on the attached graphs also plotted upsteam margin, you can see something odd on the disconnect. Speed stayed at 888bps before and after - but the upsteam power changed. Not sure I'm reading the logs correctly, but looks like it chnaged from 12.4 dBm to 8.1dBm. Now granted that isn't a problem, as I have plenty of noise margin for 888bps - but anyone know whats going on there.
Anyway I'll keep adding logging details. So I can see what if anything is behind the resyncs.

[#15]

There is a dsl stats logging program that can run on linux http://www.s446074245.websitehome.co.uk/downloads.html not sure if your router is suported...but the source code is there as well.
If your router(s) are not supported try buying, of finding on freecycle, a hg612 (opernreach FTTC modem) these can be unlocked and provide lots of stats
Have a browse on kitz.co.uk about the DLM process http://www.kitz.co.uk/adsl/DLM_system.htm
I think DLM does not like error seconds and severe error seconds so these need to be monitored.
Ian