Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Black Sheep]

Admin Note:  Ive split this topic from the original thread here

This post wasn't the start of the conversation about Openreach, but was the most logical point to split and merge without losing any info about the line or fault.

--------------------

'If you'd like to explain to me where in your working practices, that this is considered efficient use of OR's time, then please help me understand so I can interface with them better as an EU as well as appreciating how they are managing my expectations'.

I'm not here to discuss what is or isn't efficient as you see it yourself. I keep putting the point across that OR have certain expectations they must meet as agreed by the ISP's, Ofcom and BTOR. Every time you or your ISP raise a fault, we have to go through the exact same motions again with regards to testing the quality and performance of the line.

If REIN is suspected, then the proper course of action for the engineer is to perform a 'Lift & Shift', D-side change (E-side as well on ADSL), fit an SSFP/RF3, ISP to despatch a new router. Officially, only then will the REIN team build a case.

Once a REIN case has been built, the subsequent task will only go to a REIN trained engineer.

How the engineers go about their faulting after that is down to them. OR are under no obligation to do this, as I keep commenting on. So, my advice to you would be let your ISP drive this rather than yourself if there is evidence that it is REIN ?? The ISP will have to e-mail the REIN team a job-pack which shows all the relevant stats for your circuit, so that an informed decision can be made whether to actually build a case. I will say it again ...... the reason being is because it is a free service offered.

Patience is a virtue, and it is very much needed with this type of fault. 

[Roxy]

Every time you or your ISP raise a fault, we have to go through the exact same motions again with regards to testing the quality and performance of the line.

I am not against them 'ticking the boxes,' and going over the fundamentals, in fact I welcome it. The part that concerns me, is where they do not do anything afterwards and then leave it open ended - with no intention or signs of intention to progress it in whatever direction it should go.

So yes, do all the repetitive unnecessary tests you want, but don't just shrug your shoulders at the EU and then leave.

If REIN is suspected, then the proper course of action for the engineer is to perform a 'Lift & Shift', D-side change (E-side as well on ADSL), fit an SSFP/RF3, ISP to despatch a new router. Officially, only then will the REIN team build a case.
Once a REIN case has been built, the subsequent task will only go to a REIN trained engineer.

REIN was suspected for a while now by the same engineer, and yet he did nothing. On his second visit, the best he did was walk his K208 radio around the house and then still didn't feel he was 'hearing' any thing particularly detrimental. On the third visit, he did this Lift & Shift and it made things worse, while not fixing the potential REIN/SNR issue.

By your examples, then the next visit should progress to some effort to build a REIN case?

How the engineers go about their faulting after that is down to them. OR are under no obligation to do this, as I keep commenting on. So, my advice to you would be let your ISP drive this rather than yourself if there is evidence that it is REIN ?? The ISP will have to e-mail the REIN team a job-pack which shows all the relevant stats for your circuit, so that an informed decision can be made whether to actually build a case. I will say it again ...... the reason being is because it is a free service offered.

Answer me this. In one visit from an engineer, would you find it both physically possible and prudent for him to do a Lift & Shift, a RF3 filter fitting, a graph analysis and a REIN case build attempt via a walkaround the premises with a radio?
Or is it 'procedure' for them to spread this out over several visits?

Patience is a virtue, and it is very much needed with this type of fault.

This all comes back to managing customer expectations. IF OR (or their engineer) came to me and said that "so far all signs indicate their is nothing wrong with the line, hardware or cabinet. Based on the information you've gathered and the information we see, something is influencing the line in an unexpected way. It COULD be REIN, however we'd like to tie off some other possibilities first. I'll be back next week to run through some fundamental tests and look to try MY BEST, to narrow down the cause of YOUR issue(and potentially any one else affected by it). From there we may be able to raise a REIN case or proceed down a different avenue. Please be patient as we try to establish a resolution for you."

I do not think I am being impatient or unreasonable in expecting them to at least give me some visibility on what is happening and what the plans are.
What I've had instead is little sporadic communication and been left with a broken service.

[kitz]

eke - I sense your frustration. 
All engineers arent trained to look for and know about REIN. BS is, so therefore he'd know best what should and could be done.  Unfortunately not all engineers have had the benefit of his knowledge.  He is also of the ilk that he puts in the extra mile to assist customers which is something that BT doesnt allow all engineers and they are strictly limited to time slots. 

I blame company ethos [this applies to all organisations & not just BT] where time is money and someone at the top dictates how much time an engineer should spend on a job.  The people at the top have no idea what its like out in the field.  BT engineers already come under pressure because they only do 4 jobs per day rather than the 5/6 that the contractors like Kellys manage to get through.  Yet all of us know who is most likely to get it right first time.    
 
Officially REIN falls outside of BTs standard remit although they do attempt to assist if they can, even though the cause of REIN is usually the EU's own or neighbouring EU equipment.  I cant think of a simile right now, but in effect BT are providing a service and its something in the local environment outside of BT's control that is ruining that service. 

Im not sticking up for BT, just stating facts and add into the mix of how hard REIN is to track down, then even the best engineers get frustrated with REIN.

Ive been there too when it comes to faults, took a couple of months for BT to sort my fault and numerous visits before it was fixed.  It started off with what looked like REIN, they found an oxidised joint, things were fine for a few days, then it all started again but now looked more like a HR fault, that also dragged out and I could see the engineers were trying all they could, but it wasnt until my voice line failed too that it was tracked down and completely sorted.

In one visit from an engineer, would you find it both physically possible and prudent for him to do a Lift & Shift, a RF3 filter fitting, a graph analysis and a REIN case build attempt via a walkaround the premises with a radio?

I cant speak for BT, but in my experience and the experience of many others on here.. Id say no.. because this is normally done over several visits.  When my fault was eventually fixed it took the one engineer the best part of the day to rebuild my line, and the guy didnt even stop for lunch.   He took a quick 10 min tea and fag break when I offered a sandwich but aside from that and the odd slurp of coffee I could see he worked his ass off to do what needed doing in the one day.

There are some on here that will have seen my frustration during that period, and TBH I nearly threw the towel in at one point.  I was lucky though in that my ISP was behind me 100% of the way, and it was them that rejected without even asking me & pushed BT for that final visit which sorted it.
 

[Black Sheep]

Phew !! Thank you, Kitz ....... I was in the throes of a reply when it highlighted somebody had added a response. I think you've boxed the scenario off pretty well.

I'm going to bow out of this one for now, as I feel tensions are growing between myself and Roxy. That was never the plan.

[Chrysalis]

Roxy to me I am amazed you got an engineer call out for a REIN issue without being charged, my line is full of RFI in the evenings but have not contacted my service provider BT as it's not effecting my broadband that much yes there is a low level of hiss on the telephone.

For me a pair swap would do the job for me as my original pair have become way out of balance over 3 years and the effects are low SNRM in the evening and US CRC when phone rings if I left this line for another 3 years as is it would definately become service affecting.

What I do when I am quoted a possible fee I Say something like this.

"I agree under the conditions the attending engineer tests all possible points of failure, and if proven all are ok I will pay"

I have said that 3 times and every time got an agreement from the person at the other end, its probable they not fully understanding my terms, but regardless they agree, I have yet to be charged for a visit.

Since we both know openreach are never going to test all points of failure due to their contract with the isp's this means if openreach raise a fee with the isp, the isp cannot raise it on you as you didnt agree under those terms.

I do feel tho these fee's although strict in the openreach t&c, seem to be there just to deter people who repeatedly report faults that openreach are unwilling to action on, e.g. reporting a low speed and there is no spare pairs or whatever.

Perhaps Black Sheep can answer why SFI engineers rush off when they have 2 hours allocated? do openreach overbook them so they have more than 4 jobs a day?

[kitz]

Perhaps Black Sheep can answer why SFI engineers rush off when they have 2 hours allocated? do openreach overbook them so they have more than 4 jobs a day?

I dunno, but logistics would imply to me that the engineer doesnt really have 2hrs at the premises.  Although 4x2hrs fits nicely into a working day, it doesn't take account of travelling time to and from premises and writing up of notes.   

I suppose a lot will depend on how sensibly the jobs were allocated.  Around here it takes a good 45 mins to get from one side of town to the other - and thats not including heavy traffic.  The distances some of the contractors travel appear to be much wider than those of BT, so its no surprise they dont want to stay longer than 15mins 

[Black Sheep]

  ...... as it is 'Off Topic' I am giving Chrys a reply.

He makes a fair point about the 2hrs. The job does indeed have 'Up to 2hrs' time allocated to the task. That is just a figure though ............. one has to treat each job on an individual basis.

If I arrive on-site and the Hub has an axe in it, then it's pretty obvious where the fault lies. 15mins later and I'm leaving site. If it's a job akin to Roxy's, then just like her last visit with two engineers involved for a few hours, further in-depth analysis will be required.

For info, travel times to the premises are factored in and added on to the 2hr task-time. The system that does this assumes you are piloting a Lynx Helicopter, and that rush hours are a series of Jackie Chan films.

[loonylion]

Are you allowed to land said helicopter, or do you have to rappel out the side with all your equipment over your shoulder? 

[Black Sheep]

Due to our infamous 'i-Pop effectiveness and efficiency' measures ........... we remain connected to the rappel rope, and after a 4-minute PQT test, the shout out, "Go Go Go" is given and we are whisked away.

<Disclaimer> This is not actually true, as some may believe it is. 

[Chrysalis]

to kitz

I am only talking about faults not installs, I have never had a contracter here.
The 2 hours is supposed to not include travel time.

black sheep, I guess been realistic if an engineer doesnt want to do overtime at least one job needs to be under 2 hours to allow a break and travel time to the others.  Assuming 4 are allocated per day.

[Black Sheep]

We seem to be wandering away from Roxy's string, but unless told otherwise ...............

Engineers work patterns can differ greatly from a 5-day week (0800-1552 with lunch) to a 4-day week (0800-1740 with lunch). There are quite a few permutations in-between, plus those with personal circs who may have less hours (child care/infirm relative etc).

Then, each engineer has a choice as whether they want to go on 'Tours' (picks up multiple tasks at the start of the day), or 'Single job allocation' (What it says on the tin .... one job at a time).

If on a 'Tour', our Work Manager Allocation tool should only allocate work for the engineers scheduled hours. However, to chuck a swerve ball in, our wonderful Union negotiated us into a 'Flex' situation, whereby we can be 'Flexed on' for a further hour at the end of the day. So, in theory unless the engineer utilises the 'No Flex today' option, the WMA could give 10+hrs work to some engineers.

[Roxy]

eke - I sense your frustration. 
All engineers arent trained to look for and know about REIN. BS is, so therefore he'd know best what should and could be done.  Unfortunately not all engineers have had the benefit of his knowledge.  He is also of the ilk that he puts in the extra mile to assist customers which is something that BT doesnt allow all engineers and they are strictly limited to time slots. 

That's kinda what I am saying ; they're not all him

Officially REIN falls outside of BTs standard remit although they do attempt to assist if they can, even though the cause of REIN is usually the EU's own or neighbouring EU equipment.  I cant think of a simile right now, but in effect BT are providing a service and its something in the local environment outside of BT's control that is ruining that service. 

My understanding is that due to the majority of REIN/interference being down to the EU or items on a private property, then the rule of thumb is that they only get involved when REIN creates a massive business or investment problem for an ISP partner. However in some cases (and probably more than they should), they do get involved.

I cant speak for BT, but in my experience and the experience of many others on here.. Id say no.. because this is normally done over several visits.  When my fault was eventually fixed it took the one engineer the best part of the day to rebuild my line, and the guy didnt even stop for lunch.   He took a quick 10 min tea and fag break when I offered a sandwich but aside from that and the odd slurp of coffee I could see he worked his ass off to do what needed doing in the one day.

There are some on here that will have seen my frustration during that period, and TBH I nearly threw the towel in at one point.  I was lucky though in that my ISP was behind me 100% of the way, and it was them that rejected without even asking me & pushed BT for that final visit which sorted it.

We did have an engineer out today. Firstly you could just tell he wasn't an a-hole or an entitled unionist with a chip on his shoulder - he smiled. He also listened fairly intently, asked questions and engaged in conversation. His first order of business he said was to get the connection back online, because it was failing to sync badly. That took him quite a while, as he had to be on the phone and back to the cabinet a few times. His assessment was that the unbanded 48mbps speed was too much for the line and there were natural raw CRC causing it to be unhappy. Whether that alone was causing the amount of CRC that I've observed, and therefore is the singular culprit in the application of interleaving, he was hesitant to say - not conclusive enough.

Next he did a REIN walk around with (I forgot to ask) a pretty hunky radio looking piece of equipment. He found significant interference on the satellite line stapled into the brick of the house. He said he wasn't convinced it is related, but would keep it in the notes for next time. Additionally he agreed that based on the graphs I had (yes he actually looked), and the behaviour of the line that I've seen, that REIN was potentially a factor. He seemed particularly concerned that something was influencing the line outside of the line itself.

It's possible that the sync issue and the REIN issue may be related and in some ways completely separate. One is affecting the raw error rates/CRC of the line and the other is creating more unnecessary errors.

I told him about the pattern of recalc > CRC increase/SNR drops > interleaving > repeat
I thought FEC was an indication of corrected CRCs and other errors, which is why I was getting so many(200 million FEC in ten days) while interleaved. He replied that it's the other way around, saying that CRC are 'hard' errors, where as REIN would induce large amounts of FEC. Additionally he gauged ES/hour as 32ES per minute per mbps to be the threshold. I said 'per minute!?!' And he confirmed. So, that's 32X39 = 1248
Even per hour that seems high..


As for the lift and shift, I asked if he would put us back on the previous port and he said they would not allow him because they've now deemed it 'damaged,' even though he says it's fine. I tried to explain that if this port caused a big disconnect (my first ever) then why keep me on that same port? Aren't I going to get the same errors? Especially if the speed is even faster?
I also gave him a question about his opinion whether he would take a sync of 42 DS (interleaved due to errors), or a 39 DS (fastpath clean). He chose the former. Which I replied with a tough spot question on whether we could (if it comes to this), get BT/OR to put us back on unbanded and just let the interleave do it's thing. HE didn't see a problem with that, effectively it means a line recalc, but under this new port, we can't get the same max attainable any more.

He removed the RF3 filter and we ended up with 39.5 DS at 6.3db and 7.2 US sync at 10.3bd (10.3 !?)   I didn't mention that yesterday the line temporarily came on line at 40 DS at 4db and 10 US at 7db (I've never seen 10 US that was odd).

The plan is to leave it till Friday and see if it A) Drops out B) What kind of errors it accumulates. What concerns me here is that previously this port resulted in 9 DS with 70,000 CRC and a huge disconnect.

I'm going to get back in touch with Paul and let him see the new data in a few days.
So far, the behaviour is similar stats wise. I note the total ES and CRC, as well as the lack of FEC which seems to happen under Fastpath.

HG612 by Ronski
Connection up time : 6 hours 21 minutes
Sync                     39655  7198              Interleaving                  OFF / OFF
Attenuation              23.9  -                   INP                                   0/0
SNR                         5.5  10.1               Delay                                0/0
Power                       11.9 3.5                SES Errors                       3/0
RSunCorr (DELTA)       0 /0                    RSunCorr (TOTAL)            0/0                 
Error Seconds (DELTA) 40/0                  Error Seconds (TOTAL)    4018/11
Bit Swaps (DELTA)       51/0                  Bit Swaps (TOTAL)          18370/79 
CRC(DELTA)               140/-                  CRC (TOTAL)                   14038/1
HEC (DELTA)               14/-                   HEC (TOTAL)                  3328/0
FEC (DELTA)                0/-                    FEC (TOTAL)                    0/67

DSL Stats
SNR is dropping from 6-5.5 but has yet to go under that
Interestingly, ES/hour is 0

This is the first time I've seen 612GUI and DSL stats disagree on ES counts.



@Black Sheep,

No need for you to excuse yourself, your input is valued. You attempted to remind me that I cannot let frustration skew my considerations on how my case is being handled. And I simply wanted to remind you that not every engineer is you, and my experience(S) hasn't been what I feel it should.

@Chrysalis,

That's a good idea, I like it. Fortunately I have had any 'fees' waved by the claims handler - which if this gets fixed, I might by a Christmas present.
You also raise a fair question about engineer visit duration. Only one passed the two hour mark (and by two hours I mean actually working).
Then again, some of the guys that left my pace early, sat outside in their van for almost an hour, so clearly they don't HAVE to be somewhere. I just wish I was logging graphs back then so I could run out and say LOOK LOOK LOOOOOOOOOOOOOK!

[Chrysalis]

Well as you discovered I think two things are in play here.

One luck of the draw who the engineer is, they not all the same.
Two the type of job the engineer is given, it seems Black Sheep has posted there is several different types of jobs, and us consumers are unaware of which type of job they have been issued, I suspect the type of job has a bearing on what the engineer will do or is willing to do.

I think once a fault is confirmed either by an engineer or the remote test the isp runs, you will probably be immune to charges, after my GEA test failed plusnet guaranteed I wouldn't be charged regardless of outcome of visit.

[Roxy]

Well as you discovered I think two things are in play here.

One luck of the draw who the engineer is, they not all the same.
Two the type of job the engineer is given, it seems Black Sheep has posted there is several different types of jobs, and us consumers are unaware of which type of job they have been issued, I suspect the type of job has a bearing on what the engineer will do or is willing to do.

I think once a fault is confirmed either by an engineer or the remote test the isp runs, you will probably be immune to charges, after my GEA test failed plusnet guaranteed I wouldn't be charged regardless of outcome of visit.

Funny you should say about confirming a fault. So far only Beatie is claiming that, where as OR is seemingly happy to act as if that's  'the way some connections just are..' as one engineer eloquently put it. Having said that here is the small update :

A) I mentioned in my last post that the DSL stats and the Ronski stats were different in reporting of ES rates. I believe that was a small temporary glitch, so have now ignored it.
B) I had an exponential CRC growth and a disconnect that same evening/late night on last Monday after the gentleman left.
C) This continued on till Tuesday, until another disconnect where it then came back online under interleave.
D) Throughout this week the SNR has continued to fluctuate however it's a bit more controlled, it's from 4.9 - 6.2 there about and the total CRC/ES per hour/FEC is also less than it was previously in an eight day stretch.
E) I did not get a call on Saturday from the engineer(or whoever was meant to 'check in'). I had to call Beatie and they were very apologetic. After forty minutes with the offshore department, the result was :
 -Issue is raised to a 'team leader' at Open Reach
 -Issue is also raised to the 'back office systems analysis team' at Beatie for further investigation into what OR is doing and the performance of the line since the reported problems
 -Engineer booked for Wednesday

After all the promises and guarantees Beatie made over the phone about this to be taken care of on each visit, I think they are now frustrated that OR isn't progressing the issue and after ten engineers, they want some answers. One of them even read the notes and started asking me 'what happened after this engineer left?' 'and what happened when this one I see came back twice?'  I told him and he was like 'sir that is not acceptable, hold on.'

I am not sure how to approach this visit, if it's one of the previous guys that's a double edged sword. I think I'll go first from the angle of the current port being poor, and request him to change it, then investigate where the errors are coming from.

[Bald_Eagle1]

Looking at 24 days worth of your stats (montage attached), apart from the periods when stats weren't recorded, there seems to be a definite pattern of 'noisiness', loosely from early afternoon to midnight.

US Output power also seems to fluctuate quite a bit too.

When on fastpath, error counts generally increase significantly, even on reasonably quiet lines & Interleaving is usually re-applied after a few days, as seems to have happened on your connection.

Other than thinking the timing of the interference could fit with pub operating hours, maybe a pumping station of some sort or someone using a plasma TV, I'm at a loss as to what the cause could be.

Can you think of anything else in your area that is likely to operate during those times causing quite sudden starts & stops to the 'noise'?

If it was a general line fault (HR or otherwise), I would expect to see the issue at all times of day rather than just from early afternoon to midnight.

I imagine your reduced error counts are currently down to the lower, interleaved sync speeds.

I don't hold out much hope for Wednesday's engineer finding a physical fault (unless it is indeed a faulty DSLAM port).
I suspect that you may have to simply live with it until such time the source of the interference is tracked down & rectified.