I can offer no advice as how to progress this fault to a satisfactory resolution . . . but will follow this thread with a significant degree of interest. 
I'm in a similar vein here. I can offer the following:
Spotting when the line is bad:The current banding means that the *speed* is no longer a good indicator that things are going wrong with the line. Similarly a "non-standard-but-flatish SNRM" doesn't tell us much. Every time I look across all the graphs, the best indicator I can see that correlates to "fault-being-present" is a higher-than-normal
attenuation value. A secondary indicator is a variable-jittery
SNRM.
Getting Openreach to attend when the line is bad:Openreach can only fix the fault if the line is bad at the time they attend ... which is obviously delayed from the point you first notice the issue. In one sense you are lucky - because your fault tends to stick around for some period once it has occurred. However, TalkTalk are getting in the way here, because the fault doesn't hang around long enough for their incessant pauses and delays.
What will help you most is if you can get Openreach to attend ASAP after the fault is first noticed. Bypassing the TalkTalk delays as much as possible.
What you probably need to do, as an outcome from this visit, is to talk to the TT team, and get them to agree
- Your fault is intermittent.
- That, when it occurs, there is a window afterwards when Openreach could detect and fix it.
- That it needs an appointment arranging as soon as you can see it next occurs.
- That your fault remains open, so that the pauses and delays can be bypassed next time.
- That you will monitor, and phone as soon as you see the problem re-occur.
- They will arrange an appointment without delay.
If anyone else can add something to speed up the TT-delay -> Openreach appointment time, please add it...
MDWS already does way, way more than I had ever envisaged but isn't and never will be infallible so please don't expect it to be.
I agree. I tend to not bother looking for the resync indications added by the monitors, and just look for disjoint data: sudden jumps in SNRM, sync speed, attainable speed, or power.
Or I look for "gaps" in data - which might show as a physical gap in the graph (as in broadstairs "SNRM" graph), or it might appear as a sloping line that shows on the graph, but can't be hovered over in the normal way (showing "dots with data"; such as the "Sync Attainable" graph). In latter cases, hovering only produces a "dot" at the extremities of the slope.
however it still does not show any subsequent re-syncs or the AS time would be different.
I concur. There is no sign of anything other than the one disjoint period.
but that does not mean you do a test and GIVE UP, which is what OR are doing in my opinion.
Unfortunately, this is one of the consequences of Ofcom's version of "competition", and the dash for "pile it high" cheap services. I suspect the desire for a "known appointment time" is a significant constraint on flexibility. Altogether, there is a need for appointments to be constrained, with little time for "engineering perfectionism" in the face of a potential wild goose chase.
OK it does not help at all when TT do not take these issues seriously and try to get OR on site while the simply MUST be able to see an issue is live. If this were the first call out I might accept it but this is the third call on the same issue and has not been resolved. None of this is acceptable and I will not put up with this situation. Believe me TT and OR do not know what will hit them if they don't take an indisputable issue seriously.
One aspect of support that works really badly is dealing with complicated faults that run over multiple calls/appointments. Our current model of interaction between ISP and wholesaler makes this horrible - especially when you encounter an ISP whose procedures force more delays.
I'm pretty sure you'd have a better experience if this were going via AAISP's support group. It wouldn't be fixed in one go, but it would run around the cycle faster.
