You think your internal wiring is OK? So did I!

[#1]

Quote

If BT did that work, perhaps BT can be called out to rectify their own wiring mistake (if it is indeed a mistake!).

The second line was taken out 8 years ago so I wouldn't fancy my chances of a 'workmanship' claim against BT!
Thanks WWWombat for the detailed response. I think I have an understanding of the options now. Truth is, fitting the i-plate back in August made such an improvement that I'm not sure how much more there is to be gained by fiddling with the wiring. After all, my line isn't performing badly at 5344kb/s on an attenuation of 39db.  If I was brave enough, I suppose separating the two lines temporarily would give me a clue as to what could be achieved - after all, it is only the equivalent of plugging into the test socket!
However, since my training period with Plusnet was before the i-Plate was fitted, I wonder whether that could still be responsible for my high SNR margin (12-15db)?  If so, maybe I should ask for an SNR reset . The only thing that makes me doubtful is that, when the router first synchronises, it usually achieves a rate of around 6500 then, over the next couple of days does a couple of re-synchs (DLM triggered?) ratcheting it down to 5568 or 5344. During this period CRC and HEC errors are clocked up fairly briskly but, as I said in my earlier posting, I've never seen an FEC error. I would like to monitor this process more closely but, unless someone knows of an equivalent to Routerstats for the Mac, I can't think how to do so.

[#2]

There is certainly a possibility that wiring the A-B lines straight through will improve your signal, but I agree that you're more likely to have achieved the bulk of the improvement with the iPlate.
The high SNR value is caused by exactly the process you witness: The initial sync at higher speeds; the high speed ends up being unsustainable and causes errors; BT's DLM probably then increases the target SNR and triggers a resync. Eventually you achieve stability at a lower speed and higher SNRM. And yes, the speed you actually get isn't too bad for the attenuation value, but I'd expect it to be higher (Kitz suggests 7100).
This means you are getting noise on the line, and it appears the DLM is doing the exact right thing (for once!) to give you a stable line. That means it probably isn't worth going for an SNR reset, as the same process would happen again.
The source of the noise could be out on BT's network, or could be due to your internal star wiring. But because of the questions over exact ownership, it is hard to predict exactly how a BT engineer would respond to a fault call-out, and whether you'd get charged or not. I guess at *some* point, you're going to have to find out.
I just googled on this kind of point, and found a couple of links that might help (or might just add to the confusion): http://www.techtalkz.com/telecom/186105-openreach-wiring-gpo-mess-adsl-query-3.html#post773230 and http://forums.thinkbroadband.com/technical/t/3570350-wiring-in-house-is-still-gpo-how-to-maximise-ad.... And a couple of opinions here: http://community.bt.com/t5/BB-in-Home/Moving-master-socket-replacing-old-wiring-question/td-p/7628.
Oh - a zero FEC usually means you have interleaving turned off. I would have thought DLM would have turned this back on when it decided to raise the target SNRM.

[#3]

Well, a few days ago I got around to removing the i-plate and disconnecting the bell wire. The router connected at 5824 and has held it for 4 days. It's only a modest increase compared with the 5344 I had before but it does mean that my profile has gone up from 4500 to 5000. Of course this could be due to many other factors (I did have a profile of 5000 back in October before the cold weather / long Winter nights set in).
The link is clocking up errors (no FEC errors though and just the one Error Second) so maybe it is a bit close to the edge at this rate? Here are the stats:
Uptime: 4 days, 11:24:05
DSL Type: G.992.1 annex A
Bandwidth (Up/Down) [kbps/kbps]: 448 / 5,824
Data Transferred (Sent/Received) [kB/kB]: 0.00 / 0.00
Output Power (Up/Down) [dBm]: 11.5 / 19.5
Line Attenuation (Up/Down) [dB]: 21.5 / 39.0
SN Margin (Up/Down) [dB]: 20.0 / 12.0
Vendor ID (Local/Remote): TMMB / TSTC
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): 0
Error Seconds (Local/Remote): 1 / 0
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 70 / 39,215
HEC Errors (Up/Down): 26 / 23,584
One day, I might pluck up courage to try disconnecting the star wiring at the point of entry to see whether it is worth paying BT  to upgrade the wiring. To be honest though, 5Mb/s meets our present requirements so I suppose we could wait until we get an obscure fault in the old wiring and hope that they decide it would be worth fitting a proper master socket just to unload the responsibility.

[#4]

I removed the bell wire from all the sockets and and just left the wires in terminal 2 and 5 throughout.
The connection continued to improve over several weeks.

[#5]

Trevor,
That's an impressive improvement over the iPlate, whose job is to physically do the same as you just did manually, and to squeeze the best speed out!
It might just have been the time of day that you did the resync (10AM-2PM is best time for lowest noise; hiighest sync), but to have kept it over the 4.5days is good.
The CRC figure looks to be a good one for you to be monitoring - this shows an average of around 6 CRC's/minute downstream, which is starting to be noticeable (that's around 0.2% of all your data frames), but should be managable.
The equivalent value for your first set of stats was around 3 CRC's/minute.
The errored second value is implausible to go with that level of CRC's. An errored second is a second-long period where 1 or more faults occur: but there are only 59 frames per second, so it should be impossible to have an error count larger than 59 alongside an errored second count of 1.

[#6]

Well, after nearly two weeks enjoying a profile of 5000 at a sync rate of 5824, it dropped back to 5216 at around 4am yesterday. I did a manual re-synch later in the morning and got the 5824 back again but overnight it has again dropped back to 5216.
Conclusion: removal of the i-plate didn't improve anything - as you would expect.
Interestingly, the S/N margin has gone up to 17db (It normally fluctuates between 11 and 15):
Uptime: 0 days, 8:40:04
DSL Type: G.992.1 annex A
Bandwidth (Up/Down) [kbps/kbps]: 448 / 5,216
Data Transferred (Sent/Received) [kB/kB]: 0.00 / 0.00
Output Power (Up/Down) [dBm]: 12.0 / 19.5
Line Attenuation (Up/Down) [dB]: 21.5 / 39.0
SN Margin (Up/Down) [dB]: 21.0 / 17.0
Vendor ID (Local/Remote): TMMB / TSTC
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): 0
Error Seconds (Local/Remote): 13 / 0
FEC Errors (Up/Down): 0 / 0
CRC Errors (Up/Down): 0 / 184
HEC Errors (Up/Down): 0 / 119
During the long 5824 sync period the CRC errors clocked up at just under 10,000 per day. Interestingly over the first 13hrs since the manual re-synch to 5824 yesterday morning, it only clocked up 417 CRC errors so I wonder what happened overnight to upset the DLM?
I may yet be tempted to try a temporary disconnect of the extension wiring!