They couldn't find any fault while at my property, reported PQT was good and passed all tests they ran on JDSU "really clean D side" apparently.
Mooched off down to the cab - on return advised me they couldn't get the full 80/20 at the cab which is a bit of an odd one - I'd expect them to get full sync?
I'd expect that too. Some people on here have had cases of a faulty port on the DSLAM, and have needed to be shifted to a new port. I don't know if that applies to you though.
Dismissed my suggestion it could be a bridge tap based on the dip on hlog, didn't push any further as they weren't the most receptive..
Shame. It would have been interesting to see if his JDSU detected the same thing.
Also asked me what interleaving was, as they rang the DCoE for a DLM reset and were advised the diminishin sync speed was due to interleaving.. 
Interesting. From MDWS, it looks like you originally had G.INP activated (INP=48) - aka retransmission - which comes with a small amount of interleaving. In your case this was a depth of 16. In general, G.INP is the best way for a line to be set up, and doesn't come with any particular reduction in speeds.
Your line stayed like that until 16:28 on the 11th August, when logging stopped briefly. Logging started up again at 16:49, but your line had, by then, put full interleaving in place (INP=3, interleaving depth=981). This might have been due to a DLM intervention (because of multiple resyncs, perhaps), and might have been due to a DLM reset (some types of reset cause this level of interleaving to be the norm, at least for the first 48 hours). However, in your case, this interleaving only stayed in place until 16:55, when logging stopped again.
Logging then started up again at 17:09, but this time it was without interleaving of either kind (so no G.INP retransmission either). Some types of DLM reset do this (and is what all DLM resets used to be until relatively recently).
Do you know if they did two resets? I'm wondering if all their investigations caused a DLM intervention to add interleaving, which the DCoE saw 5 minutes later as "reduced speed caused by interleaving", and they then did a reset.
Having said all of that (related to interleaving), it looks more like your line was actually
banded, and had an artificial speed cap of 49/15 set on it by DLM. This will have been set try to keep it stable in the face of errors or resyncs.
The first DLM reset or intervention (that put full interleaving in place, alongside a hefty amount of FEC protection) looks to have removed the banding restriction, and allowed your sync to increase to 50.1/20; here, the speeds will indeed have been reduced because of the FEC protection that sits alongside the interleaving.
The second DLM reset (that took away all interleaving and retransmission) looks to have kept the banding restriction away too, and allowed your sync to increase to 53.8/20.
Because the first "DLM event" took away banding, rather than merely adding interleaving, I'd say it was actually most likely to have been a deliberate reset by DCoE rather than an automatic DLM intervention.
I know the BTw ADSL checker is theoretical - but it does state two ranges 1 x clean and 1 x impacted..
My range for clean is 80 - 64.8 and impacted is 65.5 - 35
If my D side cable is as good as OR are implying, shouldn't my sync be in the clean range?
The speeds used in both the clean and impacted estimates come from the 80th and 20th percentiles ... which means *most* lines that have similar properties (60% of them) fall within the estimates. 20% get a higher speed, and 20% get a lower speed.
If an engineer has attended, and given your line a clean bill of health, then you should indeed have a line that can be classified as "clean", and should indeed be able to compare your speed to the "clean" estimates. It doesn't mean that, automatically, you must be one of the 60% though.
It is worrying, though, that your line continues to exhibit the signs of the bridge tap (from the Hlog graph). The knock-on consequence (in the bits/tone graph) shows you are likely to be missing a chunk of speed ... but perhaps not enough to give you a huge boost - I'd estimate around another 5Mbps.
Note: From JDSU documents, this bridge tap is likely to 4 - 4.5m long.
I offered the possibility of my reduced sync being down to more subscribers at the cabinet but this was also dismissed by the engineer.
They're likely to know just how many subscribers are using the DSLAM, but it is hard to judge how many are affecting your line.
For more giggles I jumped on Live Chat with BT afterwards and relayed the suggestion from OR that the CP can pay for an upgrade to the line plant - and apparently I now have a boost engineer appointment for the 17th. I won't hold my breath - just hope it's not the same chap who came yesterday..
Wondering if it's really worth the effort, logically given the contradictory nature of the fault I want to get to the bottom of it.
Others can advise on that better.
However, it is noticeable that your rate of errors increased as of 9pm yesterday and further as of 7am this morning. As of 8:45 (when logging stopped), the Errored Second counter had reached high enough to ensure that DLM will intervene shortly. Whether it will add banding, interleaving, or G.INP is unknown.
Something is definitely getting errors onto the line ... but whether a boost engineer could fix it, I dunno.
