FTTC Line Sync has crashed ..... OR Say DSLAM Fault

[#1]

Could someone from Plusnet please read Question (reference number: 100230761)
Engineer call has not been completed.
Need feedback on OR Timescales for fix etc.
Full details added to Question, Please read fully.
Synopsis:
Ports on DSLAM are randomly dropping to 50's Mb (approx) when ports are set to 80Mb.
My line faulted and testing on another 'working' port gave the same error.
1st fault was a drop on the line from 78M to 52 'ish Mb (ish) and 'fixed' by Engineer 10/03/15.
Only got 70M back then dropped to 64M for 3 weeks.
2nd Fault was DLM Reset due 02/04/15 to try to restore original sync speed but random speed drop on ports found.
Call has been flagged as 'not completed' by OR
DSLAM Fault escalated to OR.
No visibility of status or timescales outside OR, Engineer could not get estimate of time to fix.
Need to escalate to OR to chase status and expected time to fix.
TIA

[#2]

Everything has been ok upto the last couple of weeks and then all hell break loose, hope BT or openreach sort this mess out as your not on your own.

[#3]

It's a bit strange as they are usually very quick (within hours) to replace suspect or faulty line cards.
Are other people on the same line card seeing the same thing?

[#4]

Don't know any other details.
All facts are as reported to me by Engineer via mobile from Cab.
Engineer asked about Time to fix and got no answer.
He told me I would be advised by my ISP or OR would call me. 
As OR usually report to 'their' customers (ISP) I have made this posting.
I have NOT gone off-line or had a re-sync so nothing has happened at the cab since.
(Time now 12:40 03/04/15 ..... next day)

[#5]

I note that the fault ticket is with faults at the moment. I am sure they will provide a thorough update shortly, including feedback to BT.

[#6]

Plusnettony,
Thank you for the 'Heads-Up'
I will wait to see what feedback comes.

[#7]

Plusnet Please update my Call with this and respond to the contents of the 1st PDF and the unsatisfactory resolution by BTW/OR.
My line has been totally screwed up by BTW/OR.
Short Version:
They took a line that was 69999/20000 and simply needed a stuck 68M profile reset (DLM Reset), on the morning of the OR Engineer Callout.
Performed 2 Lift & Shifts via DCoE.
Found an error on the DSLAM where ports would not maintain sync speed.
Called the job not completed. Left over Easter ... No work performed on cab/DSLAM over Easter Holiday Period. (Drive past it everyday at least twice.)
By Yesterday there was 'No fault' on the DSLAM and my line was all Tested OK.
The line as left by the OR Engineer on the day of the call gave 61.5 down and 20 up.
DCoE announced that my line was now estimated to be capable of 54.5 down and 15.7 up.
So 'It tests at 61.5 down and 20 up. so you are better than estimate' !!!. End of Call. Passed back to Plusnet.
Long Version:
See Attached .pdf & Graphs.
Full details of line performance to date supporting Chronology, Stats and Engineers Notes from the call etc
Also attach Graphs from 24/7 Monitoring of modem/line.
See http://www.kitz.co.uk Forum and 'Router Monitoring Software' & http://www.mydslwebstats.co.uk
Zero justification for the end result of a line worse than The Engineer started with and much worse than I was gettting before the onset of line faults.
Plusnet are unable to progress this with OR as 'No Fault'  
Total frustation at insane reasoning to solve a problem.
Re: BTW/Openreach:
Is there any other industry where contriving to give your customers less than they had is called solving a problem.?
Not Happy and will not let this lie as it is totally unreasonable.
Someone needs to be able to standup to BTW/OR and state this is 'not good enough'.

[#8]

What sort of modem are you using?

[#9]

It sounds like a line issue, rather than a DSLAM issue to me.

[#10]

Quote from: jelv

What sort of modem are you using?

I am using a Zyxel VMG8324-B10A it gives 5M higher DS sync compared to the HG612.
When the Engineer calls I am back on the HG612.
The 'Short Version' of the issue is too short to convey the full issue but is for quick setting of the basic problem.
If you have time please read the 1st .pdf. (It is just 2 pages incl Screencap)
All the details are in the doc, chronological detail is there re: the line and past performance.
The Other pdf's are to support ,with Graphs, my line performance since install demonstrating I had a working 80/20 line until faults begining mid feb.
TIA

[#11]

From what I can see your current sync speed is 69.3mbps.
We estimated you at 72mbps when you signed up and unfortunately whilst you were getting higher before it is going to be hard to get this investigated further as it hasn't dropped enough below the estimate.
There's certain criteria that has to be met before we can raise it further and I'm afraid at this time it doesn't meet it.
I know this won't be what you want to hear but unfortunately there won't be much further we can do.

[#12]

Quote from: AndyH

It sounds like a line issue, rather than a DSLAM issue to me.

In a nutshell it is a line issue, compounded by the following:
The OR Engineer did report a DSLAM fault which manifested even though the line 'tested as good.'
This fault was recorded in the Engineers notes, the call was flagged as 'Not Completed'.
The line was at 66999/20000 with a stuck 68M profile directly before the Engineer touched it
The line I ended up with has been set via DCoE by ignoring the lines original state 'on the day of the callout & pre original fault'  and 'forgetting' the DSLAM problem as reported by the OR Engineer.
The line estimate has been reduced in line with the fault conditions (original callout & this callout).
It has then been announced 'fixed' without 'any fix' at all.
By narrowing the window that is looked at (ignoring the past state and its change), the fault has been simplified to nothing other than stating the obvious (tyou are better than the contrived estimates).
Note:
Contrived mean that DLM is NOT referencing the full error state change.
The window is too small and past drops in sync are being factored in when they are in fact part of the fault in the 1st place.

 

[#13]

Quote from: Matthew

From what I can see your current sync speed is 69.3mbps. We estimated you at 72mbps when you signed up and unfortunately whilst you were getting higher before it is going to be hard to get this investigated further as it hasn't dropped enough below the estimate. There's certain criteria that has to be met before we can raise it further and I'm afraid at this time it doesn't meet it. I know this won't be what you want to hear but unfortunately there won't be much further we can do.

Been through this already in a very long non-productive Telephone call.
Please read the 1st pdf. Even better if you read through the whole call log.
Quoting the estimate does not further any argument.
Look at the real performance and the chronology of the faults & actions taken. (All provided for you in the attached files in my last MAJOR posting)
You cannot simply ignore the facts to quote the 'OR Mantra'
The Mantra does not apply if the fault(s) are compounding to cause the ultimate problem which is being ignored.
BTW/OR have some responsibility which cannot be abdicated by quoting a standard line or even better forcing Plusnet to do it for them.
Suspend all preconceived ideas or points of view, read the 1st pdf carefully and understand the problem then explain why the end result is valid/reasonable/fair or even just.
I have worked & even run a Helpdesk, I know you often categorise a call before you have even fully understood the problem on the basis of past experience.
It is a useful skill to have but in this instance is obstructing the real issue.

[#14]

I think the problem comes when there is no clear fix. I understand that you want your line back to its original speed, but it's unfortunately not so simple if OR cannot find the source of your problem.

[#15]

I can see the EU's PoV here.  I also have access to his line stats via MDWS.
As such I can see that until Feb 14th the line held a steady 80/20.  I can also see that from MDWS that the line was Error Free and the amount of CRC/ErrSecs were insufficient to trigger the DLM as he was below the MTBE threshold.
The Zyxel is compliant with g.inp (I use one myself by preference because IMHO its performance on my line is superior to the BT Openreach modem)  but I note that  he has also been using the HG612 for the sake of elimination.
I find it strange that a few hours before the bank holiday weekend an engineer admits there is an issue at the DSLAM, but then it can be cleared by someone at  DCoE running a Woosh test before the bank holiday weekend is over.
Looking at the SNRm I concede that over the past few months there has been some degradation of the line due to crosstalk and I will admit that it looks like the line wont ever attain 80Mbps again.
BUT  it also looks like there's something else that occurred outside of that.  I can sympathise with the OP when he finds his speeds have plummeted to 57Mbps.. and it then appears so has his predicted speeds dropped to 54.5/15.7  [I cant check this and going of information in this post] and because it now fits in the new parameters someone at BT DCoE can run a woosh test and say its within parameters so everything is ok.. and ignore the fact that the engineer admitted to finding a problem at the dslam.    AIU this is what the OP is most aggrieved about. (apologies if I jumped to wrong conclusion)
For those that dont have access to MDWS, here's a copy of the OPs sync over the past 4 months.