I have been made aware of crosstalk since my speed dropped, but the line tests (to my uneducated eyes) seem to suggest none was detected
Test Outcome Pass
Test Outcome Code GTC_FTTC_SERVICE_0003
Description No problem found, OAM test is not currently supported on this line.
Main Fault Location OK
Sync Status In Sync
Downstream Speed 55.2 Mbps
Upstream Speed 19.8 Mbps
Appointment Required N
Fault Report Advised N
NTE Power Status PowerOn
Voice Line Test Result Pass
Bridge Tap Not Detected
Radio Frequency Ingress Not Detected
Repetitive Electrical Impulse Noise Not Detected
Cross Talk Not Detected
Profile Name 0.128M-80M Downstream, Interleaving Low - 0.128M-20M Upstream, Interleaving On
Time Stamp
The result of "Crosstalk not detected" is laughable on that result, IMHO. Crosstalk is an infinitely variable affair, creating noise of different levels at different frequencies.
It is caused by having two or more VDSL2 subscribers in the same cable for some distance; if the twisted pairs are closer within the cable, then more crosstalk results.
But the design employed by BT - having tie pairs that run from FTTC cabinet to the PCP - guarantees that once there are two customers, then there is some shared cable, so there is crosstalk. Beyond the PCP, the shared cables spread out, reducing the likelihood of further "contamination", but it doesn't eliminate it.
The amount of crosstalk added by each subscriber might vary, but its existence doesn't. Add each subscriber, then you add crosstalk - sometimes tiny, sometimes small, sometimes large.
When you see the graphs, you realise that, in the absolute worst case, more than half your speed can disappear from the extra noise and interference. Seeing 10Mbps over 2 years isn't that bad a result.
Worse, there is a double-whammy. As well as causing reduced SNR levels (so lower speeds), crosstalk causes more errors to appear on the line. Eventually, the higher error level trips DLM into action; the old-style DLM solution was to turn on FEC and interleaving ... which would reduce speeds by 10-15% in one hit (on top of any reductions from raw crosstalk) and add 8-16ms onto latency.
From the result quoted above, DLM has intervened on your line, and set this kind of old-style solution. You will have lost a chunk of your sync speed to this.
Right now, BT are deploying G.INP retransmission, which is an alternative approach for DLM to choose to correct errors; this should not have such a large impact on sync speed or latency - so that chunk of performance can be recovered. However, it doesn't overcome crosstalk.
To properly overcome crosstalk requires BT to deploy vectoring. That acts as noise cancellation for subscribers, so it ought to undo the effect of crosstalk, restoring speed back to your starting speed.