The next exciting episode in this 'Digital' Nordic Adventure ....... Starts Now
Are you sitting comfortably ?
So I will begin ....................Please read until the end of the missive before comment.
This is a venting of speen more than anything and a scream to the skies re: OR and some of their Engineers, even if pressured. I got a call from Plusnet yesterday (03/04/15) to query the status of my outstanding issue with my line.
I explained that my line was 'stuck' at 66999/20000 after the last OR fix.
I had been at 70000 when the engineer left, which was less than I had been before the fault, and the Engineer had stated if 'DLM does not fix it re-log a call'.
The sync had fallen to 66999 and stayed there for 3 weeks+.
I was able to point to a 64M profile on the line yet I got a 72M Speedtest on the BTW Speedtest.
This did not make sense to me or the Plusnet staff member.
It was agreed, after investigation, that the line appeared to be stuck on a 67M profile and and an OR Engineer would be sent out to reset DLM.
(The suspicion was that DLM reset, that had been promised by the Engineer at the end of the 1st job, had not done.)
Appointment arranged for today (02/04/15) between 08:00 and 13:00.
Engineer rang to query the 'Fault reported' at approx 12:30, and advise he was running late.
I explained that Plusnet had booked the engineer to reset DLM on the line as I had a stuck Profile.
1st response was to talk about attenuation on the line & possible crosstalk which may be responsible for the drop in sync.
(Even though the line tests performed by Plusnet all stated No REIN/RFI/Bridge Taps/Crosstalk detected).
Eventually agreed he would call and check the line.
Engineer arrives at 13:30 approx and immediately checks the physical line at the point of entry to the house. (Tester connected to line and sync checked)
Again straight into the spiel regarding attenuation & Crosstalk and it may be all you can get on the line now.
The intent from opening the door appeared to be 'get me to agree that the issue is simply the usual loss of sync speed due to new users being added to the cab etc.'
I had prepared all the stats and graphs from DSLStats + HGStats (Thank god for
BE1, Ronski, & Roseway ) + Plusnets Test results as entered into the call log on the Plusnet website.
I explain the situation again and demonstrate that the evidence to support the contention is not there, as far as I can see.
Round the houses once again re:Attenuation/Crosstalk ..... Yada Yada.
Agrees to check the cab. More testing at the cab and the line bounces up/down etc.
Apparently the port I was connected to was faulty and would not work at more than 71M when set to 80M.
Now getting 61489/19999, No G.INP and lots of Interleaving & delay. Sync is less than I had before the Engineer arrived !!!
Another round of the usual spiel ..... Yada Yada
I explain with printed docs that the line is now worse than before he touched it.
Engineer trying to close down the call and pass it back to the ISP (Plusnet).
I explain that the ISP cannot impact the line speed in anyway as DLM is deciding what I get.
More discussion and its reaching the 'Its all I can do' point & exit stage left OR Engineer.
I cannot understand how I can have a 'worse line and that is it' and say this to Engineer (politely).
He goes to cab one more time.
Wait 10-15 minutes or so and get call on mobile.
Punch line: (Wait for it ....... wait for it !)I am now told by the Engineer on the mobile that he has found the problem. Yay
The DSLAM has a fault affecting all users.
After escalating the fault to OR (Internal Support people
), he had been advised to swap my line to another users 'working port' to test the line.
He swapped me to another port that was being used and found that when tested it was fine BUT randomly the speed would crash to 51M.
This was the fault I had originally on my line. A sudden drop to 52M and dropping (So I was told).
The whole DSLAM needs to be looked at and fixed or replaced.
This impacts approx 45 users on the cab according to Engineer.
So the cab is not exactly full to generate the huge crosstalk impact anyway.
My pain and grief over this is as follows:
1.) The fault was only found due to 'luck' & 'my persistance to NOT accept the Attenuation/Crosstalk spiel'
2.) The Engineer was obviously under extreme time pressure to close all jobs. The average user would have accepted the spiel and be worse off.
3.) The fault had also been missed by another Engineer on the original call. He also was under time pressure and walked off the call too quick.
4.) Only because of the fact I collected Stats, from the earliest date and anticipated the need to 'fight' my corner did this call NOT get closed.
5.) The Engineer found the fault inspite of the pressures put on him by OR, but I have no timescale for the fix nor did the Engineer.
6.) The need for the ability to collect Stats without having to 'Hack' your modem is self-evident, and should be supported by OR.
7.) I am now in no-mans land. As OR do not report anything to me and the resolution of this is invisible outside of OR.
I appreciate the Engineers problems but pushing the users to accept issues by using Crosstalk/Attenuation as an excuse it not good.
In this case the real problem impacts more than just me so it is not trivial.
OR are their own worse enemy at times by working against their own Engineers
Comments & Ideas are welcome.
(My Brain & Fingers hurt !!!)
FYI:
I have logged all this (slightly less wordy) with Plusnet and asked for feedback from OR via Plusnet.
All Typos etc are a 'No-Cost Extra' just for you.