Thanks for the PM AO - it's hard to answer your question ATM - this is the nearest I've been to comparing like with like since reply #122 using the Netgear, it being the only time I've had a 6dB DS target SNRM with interleaving, although then it was applied at level '128' rather than the current '64', and also the upstream target margin was 6dB rather than the current 15dB.
(Prior to this whole saga it was completely stable with a DS target of 3dB (tweaked to around 5db), DS interleaving 64, upside target 6dB for months if not years on end, and that with a 15m non twisted-pair extension cable!  ::))
I'll keep monitoring for the rest of the day and see whether there are any significant differences in the pattern of errors and margins and post back here tomorrow.

Current DSL stats (not that brilliant for 6 hours uptime in mostly daylight conditions.):
Uptime: 0 days, 6:34:02

DSL Type: ITU-T G.992.5

Bandwidth (Up/Down) [kbps/kbps]: 888 / 11,281

Data Transferred (Sent/Received) [MB/MB]: 2.87 / 12.99

Output Power (Up/Down) [dBm]: 12.8 / 0.0

Line Attenuation (Up/Down) [dB]: 16.7 / 37.0

SN Margin (Up/Down) [dB]: 14.2 / 5.4

System Vendor ID (Local/Remote): TMMB / ----

Chipset Vendor ID (Local/Remote): BDCM / IFTN

Loss of Framing (Local/Remote): 0 / 0

Loss of Signal (Local/Remote): 0 / 0

Loss of Power (Local/Remote): 0 / 0

Loss of Link (Remote): -

Error Seconds (Local/Remote): 113 / 0

FEC Errors (Up/Down): 505 / 350,693

CRC Errors (Up/Down): 6 / 205

HEC Errors (Up/Down): 2 / 2,823

Just completed 24 hours uptime with the 'new' DS interleaved and US banded profile bestowed by the DLM - the figures in red are the 24-hour equivalent totals for the Netgear from 2/12/2014 as referred to in my previous post. I don't know whether 'RS corrected errors' as reported by the Netgear are the same as 'FEC' as reported by the TG582n, and although the DS target SNRM is the same in both cases, the Netgear DS interleave level at the time was 128 rather than 64 now, and the upstream target 6dB rather than 15db and banded rate now..
Uptime: 0 days, 23:59:14

DSL Type: ITU-T G.992.5

Bandwidth (Up/Down) [kbps/kbps]: 888 / 11,281 (1,144 / 9,726)

Data Transferred (Sent/Received) [MB/MB]: 10.56 / 51.65

Output Power (Up/Down) [dBm]: 12.8 / 0.0

Line Attenuation (Up/Down) [dB]: 16.7 / 37.0

SN Margin (Up/Down) [dB]: 14.5 / 6.7 (5.7 / 5.2)

System Vendor ID (Local/Remote): TMMB / ----

Chipset Vendor ID (Local/Remote): BDCM / IFTN

Loss of Framing (Local/Remote): 0 / 0

Loss of Signal (Local/Remote): 0 / 0

Loss of Power (Local/Remote): 0 / 0

Loss of Link (Remote): -

Error Seconds (Local/Remote): 519 / 0 (239 / 0)

FEC Errors (Up/Down): 1,846 / 1,026,971 (0 / RS corrected 3,487,015)

CRC Errors (Up/Down): 22 / 1,006 (0 / 598)

HEC Errors (Up/Down): 11 / 13,801 (0 / 445)

Apart from the differences in line parameters between the two sets of stats, there are too few 'Routerstats graphable' errors to detect a change in pattern, although I have noticed a big difference in the ping graphs between them - apart from the jump in ping time due to interleaving, the current pings have a much higher baseline now (around 37ms) than with the Netgear (around 25ms) and during yesterday's evening peak the spikes looked fairly horrendous (I was doing either nothing or just web browsing at the time.) The two attached graphs refer (Netgear second, also covering evening peak period.)
Good job I'm not an online gamer! 
Unless the above points to a problem which can be improved or rectified I guess I'm stuck with it - my line always required interleaving before this saga started, and it's hard to understand why it's taken so long to re-apply it, so can only hope that a) it remains stable, and b) at some point DLM decides to give me at least some of my lost US speed back. 

6 days uninterrupted uptime now, and the errors have accumulated at a more or less constant rate over that period:
Uptime: 6 days, 0:12:48
DSL Type: ITU-T G.992.5
Bandwidth (Up/Down) [kbps/kbps]: 888 / 11,281
Data Transferred (Sent/Received) [MB/GB]: 257.77 / 5.12
Output Power (Up/Down) [dBm]: 12.8 / 0.0
Line Attenuation (Up/Down) [dB]: 16.7 / 37.0
SN Margin (Up/Down) [dB]: 14.7 / 6.6
System Vendor ID (Local/Remote): TMMB / ----
Chipset Vendor ID (Local/Remote): BDCM / IFTN
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): -
Error Seconds (Local/Remote): 3,434 / 0
FEC Errors (Up/Down): 8,948 / 4,785,283
CRC Errors (Up/Down): 68 / 7,897
HEC Errors (Up/Down): 39 / 118,394
I have noticed that even with an upstream target SNRM of 15dB the RS plot is fairly spiky at times, yet some (but not all) of the smoothest traces have been during the evenings. 
On 18/01 I gateway hopped from pcl-ag07 to ptn-bng01 which resulted in a reduction in baseline ping from 37ms to 32ms.
The pings as recorded by Routerstats are also a little strange - despite there being no background programs nor large downloads taking place at any time, the attached graphs show marked differences in the evening peaks between the weekend and weekdays.
At the back of my mind is the fact that I've read that Saturdays and Sundays are the busiest days of the week...hmmm.

Just to say I haven't forgotten about this, those weekend pings may be related to the amount of streaming going on, either on the Gateway or your exchange SVLAN. I'll post a bit more another time.

Current DSL stats:
Uptime: 10 days, 0:07:48

DSL Type: ITU-T G.992.5

Bandwidth (Up/Down) [kbps/kbps]: 888 / 11,281

Data Transferred (Sent/Received) [MB/GB]: 376.02 / 7.64

Output Power (Up/Down) [dBm]: 12.8 / 0.0

Line Attenuation (Up/Down) [dB]: 16.7 / 37.0

SN Margin (Up/Down) [dB]: 14.6 / 6.1

System Vendor ID (Local/Remote): TMMB / ----

Chipset Vendor ID (Local/Remote): BDCM / IFTN

Loss of Framing (Local/Remote): 0 / 0

Loss of Signal (Local/Remote): 0 / 0

Loss of Power (Local/Remote): 0 / 0

Loss of Link (Remote): -

Error Seconds (Local/Remote): 5,649 / 0

FEC Errors (Up/Down): 12,414 / 9,304,238

CRC Errors (Up/Down): 96 / 12,549

HEC Errors (Up/Down): 57 / 182,490
So, 10 days uptime with only a brief loss of PPP session at 1000 23/1 which resulted in being moved from gateway ptn-bng01 to pcl-bng02.
Otherwise, the errors have accumulated at a more or less constant daily rate, and there was no repeat of the very high evening weekend pings in the weekend just gone (due to the gateway change?  :-\)
Upstream still banded, meaning a loss of about 20% in precious connection speed compared with 'good old days', and if I understand Kitz's online article explaining how DLM intervenes (or de-intervenes), there isn't much prospect of it being removed automatically.
1) Upstream banding, with a hike in SNRM target to 15dB, and downstream interleaving (level 64) was applied on 16/1, presumably due to a major noise event on my line taking it from just over to well under the fault thresholds.
2) I understand that error seconds (and SES) are the only parameters the DLM uses to monitor the stability of the connection, and yet the TG582n only reports them as local/remote, and Routerstats reports them in its summary window in the 'downstream' column.
Does this mean there is no such thing as error seconds caused by upstream problems, or are they all lumped together for reporting purposes?
3) Although I now have downstream interleaving, the downstream noise margin graphs always looked fairly smooth (and still do) with a slow decline from 6-4.5dB or thereabouts after dark, with a slow recovery after sunrise.
The upstream noise margin graphs have always looked a little spiky, whether at a 6dB or 15dB margin, although there doesn't appear to be an overall decline as night falls. The two graphs attached show the typical patterns - the number and size of upstream downward spikes don't seem to vary much whatever the time of day, and are up to 5dB in size, which is presumably why I now have the 15dB margin.
Seems to me that my upstream connection is causing more issues than the downstream, and if that's true there doesn't seem to be much point asking PN to reset my line - can anyone please suggest whether there any causes of erratic SNR which are more specific to the upstream than the downstream?

Considering that CRC and FEC errors can only be detected by the end receiving the signal, and those numbers reported for Up or "Far end" must be been sent back to you by the equipment in the exchange, I think the zero remote error seconds just means the error seconds count isn't sent back to you. The telnet stats from my 582n only had a "Near end" column for Error seconds. The DLM calculates the MTBE (mean time between errors) separately for the upstream and downstream, and that's calculated from the error seconds count, so there must be an upstream error seconds count.

@JayG
In another thread you mentioned a problem with the Mk3 SSFP.  Did you ever query the problem with that Mk3 plate with the supplier?
Did you try and see if a remote filter got rid of the hum, bearing in mind the location of the DECT ?
Can you concisely summarise the recent issues, and post up if they are still ongoing this week?

Oh, forgot to ask, has RS been running with these recent extra drops, if so, is the pattern on the graphs any different in any way?

Quote from: Anotherone

@JayG In another thread you mentioned a problem with the Mk3 SSFP.  Did you ever query the problem with that Mk3 plate with the supplier? Did you try and see if a remote filter got rid of the hum, bearing in mind the location of the DECT ? Can you concisely summarise the recent issues, and post up if they are still ongoing this week?

Today I've tried all possible combinations of my two phones - a DECT near the master socket connected directly to a BT splitter, and a standard corded  phone upstairs connected to the splitter via an extension. Have swapped phones over, switched DECT on and off at mains, and obviously also tried with and without an intermediate additional rats tail ADSL filter in the Mk3 SSFP.
The results are quite conclusive - I get a slight hiss on the quiet line test with no additional filter, silence with one, irrespective of how I swap things around/switch them off..
I will have to 'put the question' to the SSFP seller, but I'm also wondering whether there is anything inside a BT NT5e socket which can be damaged by lightning strikes?
We had one here around 8 years ago which took out the cordless phone and the modem upstairs, although there are no visible signs of molten wiring or any other damage inside the socket.
I shall return to the other subject  of the on-going early morning sync losses anon, although today has thankfully been a drop-free one.

JayG,
I would find it difficult to believe that a power spike could pass through the phone wiring and kill connected devices without having some detrimental impact on the phone socket.  It might remain functional, but possibly out of specification?
Others might have a better informed view.

You aren't getting a hum any longer with the Mk3 plate?  At anytime the most you should ever get is a very slight hiss.
There are 3 components in a Master socket backplate. A surge arrester, a capacitor and a resistor. If the surge arrester gets blown open circuit it will no longer give any protection, if it's blown short or low resistance then obviously it can affect broadband or calls. Some are spark-gaps, but some are a semiconductor device & it may not be low resistance all the time.It may only conduct when a voltage is present.
The capacitor could blow open in which case any phone that needs the bell wire won't ring, but with BB and filters you wouldn't know.
If the capacitor goes short if a phone with a bell wire and electronic ringer is plugged in direct, the the ringer may sound all the time, but again with BB and filters you may not know.
If the resistor is blown open circuit, of no consequence except to line testing which can't detect anything unless a phone is plugged in.
If it's blown short or very low, this is the worst scenario as it will (via the capacitor if working or short) bridge/short the broadband and phone line and could result in total loss or severely degraded service. HTH.
As I'd finished this post before seeing Townman's comment, the above applies, but it could be possible for it to be completely undamaged if the lightning surge did not damage the surge arrester.  Was the NTE5 not replaced after the strike then?

Thanks guys - it did seem pretty unlikely that the NT5e survived the lightning strike unscathed, but then again after 8 years or so I guessed that any damage was not phone or broadband threatening, but of course by now I'm looking under what seem to be the last few proverbial stones just in case.
BT condemned the telegraph pole which was struck and put a new one in across the road - they took the opportunity to 'rationalise' their overhead drop cables (i.e. remove them from properties who had swapped to cable) and surprised at least a couple of neighbours by removing theirs even though they hadn't actually swapped! 
I was at home at the time they replaced my overhead drop cable and they didn't offer to check or replace the master socket.
I get an audible hiss with no additional filter connected to the Mk3 plate, complete silence with one, which of course is not supposed to happen, and not what I bought it for - the issues originally raised in this thread considerably predate fitting the plate, and the overnight sync losses started before fitting it, so I'm reasoning that leaving it in place is not having any detrimental affect.

I'd certainly ask the Mk3 plate supplier about the hiss, and not mention anything else for them to make excuses.
I'm pondering over this NTE5A!

Quote from: Anotherone

I'm pondering over this NTE5A!

Not sure what you're referring to there AO (but then again I can't even get the name of the thing right!)
Have contacted the Mk3 SSFP seller, who has offered to replace it or refund - I shall try another one as long as he is confident about their provenance.

Quote from: Anotherone

Oh, forgot to ask, has RS been running with these recent extra drops, if so, is the pattern on the graphs any different in any way?

Unfortunately not - one of the PC cooling fans doesn't like the cold so I'm playing safe and switching off overnight. Certainly could have been helpful, especially if the drops coincided with mega bursts of CRC's!
No further PPP or sync drops since the early hours of Monday 2/3 (now Friday 6/3), which is obviously good, but has fooled me before.

Current DSL stats (router uptime 16 days.)
Uptime: 4 days, 4:06:23

DSL Type: ITU-T G.992.5

Bandwidth (Up/Down) [kbps/kbps]: 888 / 12,003

Data Transferred (Sent/Received) [MB/GB]: 295.70 / 5.30

Output Power (Up/Down) [dBm]: 12.8 / 0.0

Line Attenuation (Up/Down) [dB]: 16.7 / 37.0

SN Margin (Up/Down) [dB]: 14.8 / 6.9

System Vendor ID (Local/Remote): TMMB / ----

Chipset Vendor ID (Local/Remote): BDCM / IFTN

Loss of Framing (Local/Remote): 326 / 0

Loss of Signal (Local/Remote): 37 / 0

Loss of Power (Local/Remote): 0 / 0

Loss of Link (Remote): -

Error Seconds (Local/Remote): 11,226 / 0

FEC Errors (Up/Down): 2,764 / 1,704,105

CRC Errors (Up/Down): 38 / 5,695

HEC Errors (Up/Down): 34 / 79,839
Will update thread if anything of any significance happens.