Downstream SNR varying wildly

[#1]

Ian, I'm digging a fair bit deeper than most router stats go, if you read the rest of the thread.
I am using bespoke logging, but records all useful info that is simply avaiable on the TP_Link router.
Things like switching on PPP LCP logging goes well beyond what most routers would ever allow you to do using cli or http.
Bits per tone on a tp-link is only avaiable trough a hack, but that doesn't seem my issue at the moment.
Effectivly I'm looking at learning what can be done of the DSL training period, from a remote modem - this is way outside most peoples comfort zone, but I don't see any other way of seeing what my line is doing.

[#2]

I have been following the thread but have not seen you post any error (and SES) counts...have you this information?
You can then work out the MTBE upstream and downstream and MTBR (mean time between errors and mean time between retrains) these stats are what causes DLM to raise the snrm.

[#3]

As Ian mentions, looking at ES and CRC counts could be key here. The Target SNRM having gone to 15dB, as you've deduced, clearly DLM is not happy with your line. What's happened isn't the usual DLM trying different settings for shortish periods. The fact that DLM has limited your upstream to 888kbps also indicates things aren't too good.
Are your SNRM graphs still showing a similar pattern to those in reply #54?
As far as some of the PPP drops are concerned, don't forget you will (should) get one every time your Current Line speed updates which may be some time after a DSL drop and change of sync speed. I wouldn't get too concerned with PPP drops (obviously note them) it's ADSL drops and errors that are significant.
I'm wondering if there is some continuous strong background interference rather than the pattern at defined times that you saw previously (did you ever identify anything that fitted those time slots?). This could even be severe cross-talk from another line.
Another daytime bits/tone plot when the SNRM is nice and stable would be good, along with the SNRM plot. I would hope you might be seeing some pretty flat daytime SNRM plots for some periods of the day when we have fairly stable weather patterns. I wasn't overly convinced all was well looking at the daytime plots previously, but you can get days like that from time to time if daytime propagation is affected by the weather patterns, but it's not like that day after day after day.
I'd also be inclined to get a bit OCD with doing random Quiet Line Tests (17070 option 2) to see if you ever hear any noise on the line.

[#4]

Yes, the general shape to noise margin has been as in #54, e.g. havn't seen REIN in a few weeks. with just day night variation of about 2dB in downstream noise margin.
TP-Link is bad at showing error reports in cli/http - but ejs has put alot of work into getting inside the TP-Link OS, and access low level DSL info.
I'm just looking into those, and LCP, so will hopefully be able too add those to the logs, but it will take a fair bit of script rewriting.
So not yet logging low level errors, but its on the way ...

[#5]

Good luck with it then, look forward to an update. If you can post an SNRM graph sometime when convenient.

[#6]

OK, using ejs commands, through the full telnet access, here is the interesting data:
/firmware # /firmware/dsl_cpe_pipe.sh g997lsg 1 1
nReturn=0 nDirection=1 nDeltDataType=1 LATN=453 SATN=436 SNR=131 ATTNDR=5860000 ACTPS=0 ACTATP=204
/firmware # /firmware/dsl_cpe_pipe.sh pmcctg 0 0
nReturn=0 nChannel=0 nDirection=0 nElapsedTime=355143 bValid=1 nCodeViolations=433 nFEC=74636
/firmware # /firmware/dsl_cpe_pipe.sh g997fpsg 0 0
nReturn=0 nChannel=0 nDirection=0 nNFEC=16 nRFEC=16 nLSYMB=256 nINTLVDEPTH=8 nINTLVBLOCK=16 nLPATH=0
/firmware # /firmware/dsl_cpe_pipe.sh g997fpsg 0 1
nReturn=0 nChannel=0 nDirection=1 nNFEC=12 nRFEC=12 nLSYMB=1520 nINTLVDEPTH=32 nINTLVBLOCK=12 nLPATH=0
So if reading correctly - a fair bit of interleaving switched on. There is a FEC about every 5 seconds. Is that bad? Need to dig a bit more to understand these numbers.

[#7]

And as about to leave it tonight, here are the latest FEC
/firmware # /firmware/dsl_cpe_pipe.sh pmcctg 0 0
nReturn=0 nChannel=0 nDirection=0 nElapsedTime=360436 bValid=1 nCodeViolations=433 nFEC=75113
So time and FEC increasing - so this is a useful channel to look at.
As ejs noted, many fields in TP-Link routers, even when hacked, are zero. Looks like a limitation of the ADSL driver, which is a pity as the lantiq hardware seems good, and capable of VDSL. So I'll probably look at migrating to a more upto date openwrt at some stage ...

[#8]

On ADSL interleaving is usually the first DLM intervention, you can expect latency to increase dramatically

Quote

ElapsedTime=355143

= about 98 hours

Quote

nCodeViolations=433

error seconds
MTBE = 355143/433 = 820 now not a problem

Quote

FEC=74636

not a problem fec's are corrected errors

Ignore FEC's keep an eye on the code violations...probably the high SNRM is doing it's job and has reduced the error seconds.
Off to bed now....post  more stats  or log the error seconds and draw a graph against time.
Ian
edit Typo

[#9]

I have attached my FEC and error second graphs just for information

[#10]

My attenuation is the same as yours and I am on a 6 dB SNRM

[#11]

Ta thanks for the explainations and graphs. So seems like my connection isn't that bad. Notice that I can only access the errors in one direction, its probably download (but tp-link settings seem a  bit confused). Will take a few days for me to write scripts, I'd like to change the total errors, into the erros in the last 10s - then I can see exactly when errors arrive, as well as calciate error seconds.

[#12]

and today
nReturn=0 nChannel=0 nDirection=0 nElapsedTime=429907 bValid=1 nCodeViolations=446 nFEC=79281
So its been 13 error in 20 or so hours.

[#13]

There are commands to get the Errored Seconds count, you can't really calculate it yourself:

~ # /firmware/dsl_cpe_pipe.sh pmlsctg 0
nReturn=0 nDirection=0 nElapsedTime=85607 bValid=1 nES=412 nSES=0 nLOSS=0 nUAS=58 nLOFS=0

[#14]

13 error seconds in nearly a day...that is low.
Get your script and graphing working, then see if plusnet can reset your snrm back to 6 dB again then see if there is a pattern with the errors.

[#15]

Quote from: summers

So seems like my connection isn't that bad.

Don't forget that because your SNRM is now at a much higher level this will reduce the number of errors - that's precisely why DLM does that.

Quote from: summers

Have no idea whats causing it, looks like during the training period, that the exchange isn't happy with my line

Are you able to plot the Upstream SNRM? We've seen cases where DLM has changed Downstream parameters apparently because it hasn't liked what it saw on the Upstream!
I have a suspicion that the current situation may be due to the fact that you now have some continuous interference present rather than just the "timed" periods you saw previously. Did you ever associate those time periods with anything specific? This might be critical to pinning down possible causes of your problem.
What is the Thomson modem/router that you have, is it the TG582n? If so, although it has some other irritating features, it is able to deliver good diagnostics and error information. It might be worth trying.