Downstream SNR varying wildly
I'm fairly sure the bandwidth is the same for all the stations, it will be more dependent on the strength of the signal picked up. The way your tones are affected is quite common.The SNR variation for your line suggests it's picking up a fair bit of propagation between dusk to after dawn which is not uncommon for lines of that length if they have sections that are overhead. That in turn means it can also be more vulnerable to spurious interference.
As a further thought on this, and having had a quick re-read of the thread, I see no mention has been made of the your master socket and any internal wiring, so a few things to check.
Do you have a Master Socket similar to the one on the left ie an NTE5a? Is the drop-wire (BT incoming) to the socket twisted pair - it should be black, round x-section about 5.3mm diameter.
Do you have any hard-wired extension sockets? The wiring to any should be twisted pair (CW1308) with no bell wire connected (terminal 3) ie only 2 & 5 connected whose colours should be Blue+white trace & White+blue trace. Thought I'd better check as I haven't seen it mentioned.
And two days later, line went down several times. The data arround the the interesting one:
/firmware/dsl_cpe_pipe.sh g997lsg 0 1 nReturn=0 nDirection=0 nDeltDataType=1 LATN=245 SATN=250 SNR=103 ATTNDR=888000 ACTPS=0 ACTATP=119 ~ # /firmware/dsl_cpe_pipe.sh g997lsg 1 1 nReturn=0 nDirection=1 nDeltDataType=1 LATN=455 SATN=436 SNR=83 ATTNDR=8384000 ACTPS=0 ACTATP=204 ~ # /firmware/dsl_cpe_pipe.sh pmcctg 0 0 nReturn=0 nChannel=0 nDirection=0 nElapsedTime=342648 bValid=1 nCodeViolations=5262 nFEC=1451196 ~ # /firmware/dsl_cpe_pipe.sh pmlsctg 0 nReturn=0 nDirection=0 nElapsedTime=342648 bValid=1 nES=133 nSES=4294967288 nLOSS=4294967289 nUAS=561 nLOFS=0 TS=10:37:07
/firmware/dsl_cpe_pipe.sh g997lsg 0 1 nReturn=-21 ~ # /firmware/dsl_cpe_pipe.sh g997lsg 1 1 nReturn=-21 ~ # /firmware/dsl_cpe_pipe.sh pmcctg 0 0 nReturn=0 nChannel=0 nDirection=0 nElapsedTime=342659 bValid=1 nCodeViolations=5363 nFEC=1458414 ~ # /firmware/dsl_cpe_pipe.sh pmlsctg 0 nReturn=0 nDirection=0 nElapsedTime=342659 bValid=1 nES=134 nSES=4294967289 nLOSS=4294967290 nUAS=569 nLOFS=0 TS=10:37:17
So in this case 1 single error second took the line down. That one second had 101 code violations.
FEC in the period 7218!
However the last set of graphs recorded were more interesting
Clearly fequencies 321 - 347 have gone to pot so 1.384MHz to 1.496MHz.
Now what caused this to happen, isn't clear. Previous event was in early night, this one during the day. I was about at neither. Anyway now I know what happened this once, I can see if I have similar events when the SNRM is higher.
QUestion is though, why loosing 20 odd frequency bins, took the line down. Isn't the line meant to bit swap, take those bad bits else where? On my line it seemed to take the line down ....
The problem with this migrated forum is that there was/is no automatic notifications of previously replied to posts, so it was a case of come and find you! Notifications should be ok now I'm replying 
OK, to try and stop you chasing your tail somewhat, if you have an intermittent fault on the line or intermittent bursts of noise it's almost impossible to deduce how many of what type of errors will be generated at the instant the issue occurs or what bins might be affected. Visa versa also applies, though if it's always the same bins then it might be possible to narrow it down to some particular electronic equipment, but chances can be slim. Really the first thing to do is check whether all the wiring is the right standard because if not that would explain a fair bit.
It could still be an issue with an intermittent fault on the line and if you are there when a drop occurs and spot it happening, check the line for audible noise.