SFI2?

We have an intermittently dropping FTTC connection, a long with a loss of downstream sync since FTTC was installed two months ago (it dropped from 52Mb to 30Mb - it's now recovered a bit likely due to G.INP being applied yesterday).

TalkTalk were being useless so we contacted the CEO's office.

We're now in contact with TalkTalk's UK engineering team who are being very helpful but the issue still has not been resolved.

We've had four engineer visits and each time their tests pass and they leave - because "there is nothing for them to fix".

The issue is intermittent, hence why their tests pass. Trying to get them to do something (a D-side change and then a lift and shift would the best solution as that would eliminate everything) based on what I'm telling them is difficult as when their tests pass they're told to go.

I've done some research on it and there's an Openreach product called an SFI2. Supposedly this service will essentially mean TalkTalk can "pay" Openreach to replace the D-side. Has anybody used this service?

P.S. This has been posted elsewhere.

Edited by deleted (Wed 22-Jul-15 11:23:26)

Why would they authorise a SFI visit if the tests pass?

Or is the problem the number of times per day you play with settings or change router?

If the standard line test passes then TalkTalk can ask for an SFI visit.

However if TalkTalk ask for the D-side to be changed and the engineer on the day can't find a problem with the D-side then it won't be changed.

However, that's all irrelevant because you're on FTTC. Therefore if everything tests ok and your speed is where the estimates say it should be then TalkTalk will request an FTTC Superfast Assure Visit. If your speed is well below the estimate or the FTTC test system called Brandeburg sees a broadband fault then a FTTC fault visit will be requested (TalkTalk generally wouldn't pay for that).

So what was your original personalised speed estimate when you signed up?

47Mb

The issue isn't the slow speed, it's the dropping connection.

The issue is, that when the engineers come their tests pass because the issue is intermittent - we might go a week without a drop and then we might have four or five in one day.

The reading I've done seems to suggest that an SFI (not SFI2) is probably what I've had.

The SFI2 visit involves TalkTalk speaking to the engineer on the day via the phone and basically telling him what to do.

Strap yourself in for a bumpy ride.

I had intermittent issues on my Sky line. At its worst there were 158 dropouts in 24 hours, at its best I went about three days without a drop on two occasions over a few month period.

Because there wasn't a "fault" when the Openreach engineer was in my house or at the cab, I kept being told there was little they could do.... I had to force them to actually look at the logs I'd collected via RouterStatsLite and the syslog - even though I'd pushed them to easy consume graphs and tables using Splunk.

I had 4 engineer visits without coming into the property, and 6 in the house... REIN checked extensively inside and outside the house and all the way back to the cab, lift and shift including D side change eventually done (visit to the house number 5, but 4 engineers had wanted to do it before that but the DCO said no).

After engineer visit 6 to my home, the problem still wasn't sorted and the engineer wanted to do a cease and re-provide, but the DCO said no. I then decided to leave Sky and go with Zen and bolt on Critical Care (I think Openreach call it Enhanced Care, but not all providers offer it).

The problem with intermittent issues is that the Openreach DCO processes don't allow them to authorise anything to be done if the fault's not there when they are. The first thing an engineer does when they arrive is unplug everything and plug in their own test equipment (understandably) - they then plug and unplug several pieces of equipment, which could all cause a drop to be missed even if it occurs whilst they're there....

Eventually my problem was solved. It disappeared without rhyme or reason several weeks after the last engineer visit but whilst I was waiting for the Zen line to go in....

I just want Openreach to change the entire line and I believe then the issue would be resolved.

I feel your pain, and know exactly where you're at. That's what I thought I was going to need to do, so I ended up ordering a brand new line through Zen whilst the old one was live - they did manage to sort it in between the last visit and the new line going live....

Edited by MrBukey (Wed 22-Jul-15 18:22:10)

But then I'd lose my phone number and I don't want that!

Like I say, I've got a fairly willing TalkTalk UK senior engineer on the case now who I am hoping I can persuade to get Openreach to change the line.

In reply to a post by arobertson545:

But then I'd lose my phone number and I don't want that!

Like I say, I've got a fairly willing TalkTalk UK senior engineer on the case now who I am hoping I can persuade to get Openreach to change the line.

I have my fingers crossed for you. Sky were very good once I got escalated to the Exec Tech Team. The engineers were good. My problem lay with Openreach's DCO office ignoring authorisations Sky gave and actions Openreach engineers wanted to take, and actively refusing to allow things to happen.

There is another avenue that I found helpful but I don't want to put it "in public view" as it's unfair to the person involved - if you continue to have issues send me a private message and I will share it privately.

This saga has been going on for a good few months now.

I'm fed up with the whole thing and part of me just wants to give up now to be honest.

In reply to a post by arobertson545:

This saga has been going on for a good few months now.

I'm fed up with the whole thing and part of me just wants to give up now to be honest.

Sending you a private message. As I say, I understand totally where you're at with it all, I was in the same position a few weeks back.

Thanks a lot - very much appreciated

I just think Openreach's response of "it tests fine so there's no fault" isn't helpful in any way. I'm not making up a fault for fun - this isn't an enjoyable experience. I just want the Internet service I pay for.

Changing to FTTC has been a big mistake.

Edited by deleted (Wed 22-Jul-15 19:07:45)

The other thing that is odd (although some people disagree) is my Hlog:

http://i.imgur.com/vpWOlCFl.png

Edited by deleted (Wed 22-Jul-15 23:54:20)

And another resync...

That generally wouldn't result in a "whole new line". The same cable would be used at the house end - just a different pair on it. Further back in the network it may well be a new line but if any fault develops in future there is nothing to stop BT swapping that on to a different pair - which could actually be the same pair as you were having issues with.

Ah I see.

Well in that case I don't know what to do

I'm afraid it is keep plugging away to get it fixed. Or, if you have the option, move to someone like Andrews and Arnold who are better at pushing BT for a resolution.

EDIT to add: I assume you have ruled out problems with the router?

Edited by ian72 (Thu 23-Jul-15 12:34:39)

The issue is primarily the cost.

Also the fact that we have a landline and we need anytime calls which AAISP won't offer

Edit: I've tried three routers now

Edited by deleted (Thu 23-Jul-15 12:35:05)

That it is the problem with going for a bargain ISP - support tends to suffer and they don't have the time to invest in difficult to find issues.

In reply to a post by ian72:

That it is the problem with going for a bargain ISP - support tends to suffer and they don't have the time to invest in difficult to find issues.

Like I say, I'm being dealt with by their UK-engineers via the CEO's office now who at least are annoying Openreach a bit.

At the same time you need to know what Openreach will and won't do. I've tried to explain that due to you being on FTTC you won't get an SFI visit, that's a copper only product. Secondly, you mentioned Openreach engineers phone TalkTalk on SFIs and TalkTalk (them them what to do). TalkTalk never tell OR what to do on a repair, it just doesn't work like that at all! They don't have the right to tell the engineer what to do, and to be fair most of the time people sitting in an office have far less knowledge about how it all works than someone who works every day on the network so actually you wouldn't want it to work like that.

I'm literally just repeating what I've been told: don't shoot the messenger

Like I say, there must be some reason that the line is dropping and I think I have every right for that to be fixed, do I not?

https://www.openreach.co.uk/orpg/home/updates/briefi...

Fair enough
The top bit of that briefing describes that it's for copper broadband only. Not FTTC, which is what you have.

Oh absolutely you should push to get it fixed but don't expect the engineer to be phoning TalkTalk and taking orders from them because that absolutely won't be happening!

Edited by deleted (Thu 23-Jul-15 13:30:18)

To be fair I don't have complete confidence in what this TalkTalk engineer is saying.

He's convinced he can make the connection more stable by changing the DLM profile but he can't as ISPs have no control over FTTC-DLM, except the line profiles which only change when DLM makes changes to the line.

I am fairly certain TalkTalk put FTTC lines on the stable profile anyway.

If their tests keep passing I'm basically in limbo because as far as I know, Openreach don't do changes without hard evidence

In reply to a post by arobertson545:

I'm literally just repeating what I've been told: don't shoot the messenger

What you've been told is wrong, apparently.

The only change he can make is put you on speed, standard, or stable profile.

I just Googled it and supposedly the SFI2 visit does allow a co-op between ISP and Openreach.

However, as has been said already, it's not for FTTC.

https://support.gradwell.com/entries/23218367-What-i...

That's a really good description of SFI for anyone that's interested.

You're spot on there, they have no control over DLM on FTTC. If OR are called out repeatedly they will generally try a pair change to be fair. If your line is dropping then OR can see that by logging into the DSLAM so it's not like they're going in blind and just having to take your word for it. The engineer on the day should definitely be phoning the OR internal helpdesk who can log into the DSLAM and check stuff like that.

In reply to a post by BatBoy:

The only change he can make is put you on speed, standard, or stable profile.

Yes that's what I meant.

But like I say, that won't, in itself make any difference at all.

In reply to a post by Icaras:

...so it's not like they're going in blind and just having to take your word for it. The engineer on the day should definitely be phoning the OR internal helpdesk who can log into the DSLAM and check stuff like that.

Forgive me but I cannot help but think that they are "going in blind".

They arrive, they plug in their JDSU and do a PQT. It passes and then they leave.

The one I had most recently said that if those tests pass, that is all they actually have to do. As he said, "you're just wasting time" if the tests have passed.

They don't really have much interest in what I have to say at all.

I'm hoping eventually I'll get an engineer who will do more than just run the tests and go: I know they're out there!

In reply to a post by arobertson545:

I just Googled it and supposedly the SFI2 visit does allow a co-op between ISP and Openreach.

However, as has been said already, it's not for FTTC.

It does indeed, you would do the co-op call as a last resort if there's no problem in the network or if you require information. The reason for the co-op call could be to find out when exactly the connection is dropping, or to get a history of the speed. Also, the co-op call can be used to switch ports on the CP's equipment in the exchange (in simple terms). The co-op call isn't there for them to tell the engineer what to do I assure you!

The problem is if you report too often, the line may get marked as unsuitable for broadband.

In reply to a post by Icaras:

It does indeed, you would do the co-op call as a last resort if there's no problem in the network or if you require information. The reason for the co-op call could be to find out when exactly the connection is dropping, or to get a history of the speed. Also, the co-op call can be used to switch ports on the CP's equipment in the exchange (in simple terms). The co-op call isn't there for them to tell the engineer what to do I assure you!

No no, I believe you!

If TalkTalk's UK engineers don't understand this, how can anyone underneath?

In reply to a post by arobertson545:

In reply to a post by Icaras:

...so it's not like they're going in blind and just having to take your word for it. The engineer on the day should definitely be phoning the OR internal helpdesk who can log into the DSLAM and check stuff like that.

Forgive me but I cannot help but think that they are "going in blind".

They arrive, they plug in their JDSU and do a PQT. It passes and then they leave.

The one I had most recently said that if those tests pass, that is all they actually have to do. As he said, "you're just wasting time" if the tests have passed.

They don't really have much interest in what I have to say at all.

I'm hoping eventually I'll get an engineer who will do more than just run the tests and go: I know they're out there!

And are these broadband engineers? They should be phoning the helpdesks. I don't know why you wouldn't do that because they (the engineers) are marked down for repeat visits so they are incentivised to try and fix it.

But it's a shame if the guys in your area are just walking off.

In reply to a post by Icaras:

But it's a shame if the guys in your area are just walking off.

I promise you that that is what is happening.

Yes they are broadband engineers: I have asked them.

The most annoying thing is when they leave and say "I expect you'll be seeing us again." If you know that, then do something!

Crazy! They're definitely personally affected by repeat visits in the following 30 days.

You mentioned about your speed and you asked why that's important. The reason I mentioned your speed is because your speed will have reduced if your connection is intermittently dropping. DLM will have kicked in to try and reduce those connection drops. So speed is a very good indicator of all sorts of issues. If your speed has dropped a lot then that should be ringing alarm bells for the OR engineers.

The guy yesterday said "I live the same distance from the cabinet and get less than you.."

I'm sorry but if I know the line can support 52Mb (it did error a lot but besides the point) then I don't see why I should accept 12Mb less.

In general I agree with your point but crosstalk could knock 12Mb off your speed over time. The initial personalised speed estimate you got when you signed up is supposed to take expected crosstalk into account.

And again I would agree with you but the first engineer said crosstalk was very low

Try and find out how many customers are connected to the cabinet next time.

In reply to a post by Icaras:

Try and find out how many customers are connected to the cabinet next time.

Okay I will assume that is the cause of that but the disconnection issue remains.

In reply to a post by arobertson545:

The guy yesterday said "I live the same distance from the cabinet and get less than you.."

I'm sorry but if I know the line can support 52Mb (it did error a lot but besides the point) then I don't see why I should accept 12Mb less.

Because your estimate was less than 52 Mbps.

In reply to a post by BatBoy:

Because your estimate was less than 52 Mbps.

But either way, the connection dropping issue must be fixed.

How would I find my initial speed estimate?

In reply to a post by BatBoy:

Because your estimate was less than 52 Mbps.

You're right, it was 47Mb.

I'd be inclined to live with it assuming G.INP does it's stuff, if TT don't succeed in getting OR to fix the problem. You could always switch to AAISP to see if they can knock some sense into OR.

In reply to a post by BatBoy:

I'd be inclined to live with it assuming G.INP does it's stuff, if TT don't succeed in getting OR to fix the problem. You could always switch to AAISP to see if they can knock some sense into OR.

I won't be living with the dropping connection thanks!

True, DLM will keep lowering your speed cap until the disconnections stop. Then, when it gets too low, I expect OR will have to take some action.

Well eventually I'm hoping Openreach won't just leave

Well TalkTalk haven't called back - I'm really starting to become increasingly tired of this whole issue.

Kind-of regretting upgrading to fibre now - at least my ADSL connection was stable

SNRM on the upstream dropped to 5dB from 6dB last night in a single go and is now stuck there.

REIN?

It turns out my last TalkTalk contact was hospitalised so I've got a new one.

Had a long chat with him tonight and he's sending out a new router which after some discussion we agreed was pointless - oh well.

He said he would get Openreach to do a lift and shift but the engineer would come to my house first - I thought the engineer went to the cabinet.

He said he would discuss with his colleagues, a pair change.

Progress I suppose.

The engineer will come to your house first, always the case in a broadband appointment.

TalkTalk can request a lift and shift, but if the Openreach engineer doesn't believe that'll help then it won't be done. Don't forget, Openreach manage all of that part of your connection with FTTC. It's solely their decision to do a lift and shift which involves moving you from one port to another in the cabinet. The DSLAM is Openreach's.

It's different from ADSL where TalkTalk own the DSLAM in the exchange so an Openreach engineer would do a lift and shift on ADSL by calling TalkTalk.

Discuss with his colleagues about a pair change? Again, they can't make the engineer do that as the engineer doesn't work for them and they don't own the network!

Edited by deleted (Tue 28-Jul-15 08:48:06)

I think he meant discuss as in decide whether it was worth me suggesting to the engineer that it would be a good idea.

I believe they can add it to the fault notes for the engineer to see too although like you say he doesn't have to do anything.

I am fairly confident I have an HR fault.

Looking at the Hlog, the attenuation suddenly increases and then decreases again (around 2000) which is a symptom of an HR fault.

In reply to a post by arobertson545:

I just Googled it and supposedly the SFI2 visit does allow a co-op between ISP and Openreach.

However, as has been said already, it's not for FTTC.

SFI2 does allow the co-op IF the ISP selects it for another 20 quid or whatever it is wholesale rate. It makes sod all odds though, because BTO rely on the "Pair Quality Test" as the determining factor.

I've got a copper DSL service fault for a customer, it's never going to fail the PQT test unless they happen to be around at the exact moment it fails, and even then it's questionable as it doesn't last long. But it does kill the DSL service.

What's worse, is that I've discovered every other household on the route has the same issue, they've all raised faults at one time or another and the issue isn't resolved.

...because there's no mechanism to get BTO to fix a "general area" intermittent fault - if someone bulldozed the line plant, they'd fix it as a general issue (eventually), but this type of fault goes nowhere even WITH SFI2 fees paid.

They don't just rely on the PQT, they look at the ADSL2 or VDSL2 test on their testers also.

What would you suggest then instead of relying on the handheld testers?

D-side changed today and lift and shift done.

We'll see how the line performs now.

In reply to a post by Icaras:

They don't just rely on the PQT, they look at the ADSL2 or VDSL2 test on their testers also.

What would you suggest then instead of relying on the handheld testers?

Sorry to ruin your illusion, but as it stands, for an SFI Visit with just the Base + Network + Frames modules, if when the BTO engineer tests the line, it passes the PQT, the visit is chargeable. If the PQT passes, the engineer will not complete any further work on a precautionary basis. That's what the rules say, and in practical terms that's exactly what they do unless the engineer is feeling generous and/or isn't going to get hell from a manager. Essentially if the line "passes" to SIN349, that's good enough for them.

You've lost me a bit about "ruining my illusion". What do you mean by that?

I'm obviously talking from first hand experience here! You know that the PQT test gets saved on the Exto and JDSU and set off to the test system? Do you also realise that the 4 minute Exfo/JDSU ADSL or VDSL test also gets saved and sent off and is also compulsory?

Imagine a case where the PQT passed but the ADSL or VDSL test on the Exfo/JDSU fails due to constantly dropping sync, or hundreds of errors that takes it over the threshold. The engineer can't just walk off and leave it like that as that test has failed on the tester. Even though the PQT passed, the broadband test didn't.

If it worked like you suggest then all broadband faults could just go out as CDTA jobs.

Edited by deleted (Fri 07-Aug-15 13:55:13)

In reply to a post by Icaras:

I'm obviously talking from first hand experience here! You know that the PQT test gets saved on the Exto and JDSU and set off to the test system? Do you also realise that the 4 minute Exfo/JDSU ADSL or VDSL test also gets saved and sent off and is also compulsory?

I do, yes. But as CPs, we get billed (unless we're good at arguing the toss) as long as the PQT passes. (Edit: To clarify, the rules state that even if the engineer does any work at "frames" or "network", at no charge - such as the required drop 6 swap, the base module is charged to the CP if it passes the PQT, regardless of whether the work on the network or frames fixed a BB issue separately - in fact the job completion thing asks you specifically "did it pass a PQT" - and if you say yes, I get charged, because IIRC it is how they decide if the CP is charged...

Imagine a case where the PQT passed but the ADSL or VDSL test on the Exfo/JDSU fails due to constantly dropping sync, or hundreds of errors that takes it over the threshold. The engineer can't just walk off and leave it like that as that test has failed on the tester. Even though the PQT passed, the broadband test didn't.

That's the exact situation I am in with an end user right now as it happens. The PQT passed, the JDSU shows errors clocking up very fast, and the EU has loss of sync regularly (hours, sometimes minutes, rarely longer). We've replaced routers, filters and so on numerous times, we've looked and eliminated any issues at our end. I booked an SFI2, I attended myself, after 6 hours on-premise (3 of which were waiting for a cherry picker to be free so they could go up and have a look on a pole), 1 of which was waiting for control to call back, and 2 were replacing a drop wire as that's a standard part of the "network" module (as you know), because it was an old drop 6 etc.

...and control told the engineer he was not to do nothing more because it passed PQT, despite the fault still existing, despite it also being obvious from discussions (held in front of OR engineer) that others suffer too in the local area,

...and yes, it still has the same errors on the BB as it did to begin with. Sync is slightly faster (marginally) but unreliability remains. Sadly, I don't have to imagine that scenario you described, because as you can see, I have that situation, and not for the first time, and not with one customer.

Edited by therioman (Fri 07-Aug-15 21:04:14)

Anyone fitted an RF3 filter?

In reply to a post by Icaras:

Anyone fitted an RF3 filter?

No - fitted new drop wire, new NTE5, and a MK3 SSFP. Specifically said "no point installing an RF3 because the MK3 SSFP does it already...

In reply to a post by Icaras:

Anyone fitted an RF3 filter?

I've actually ordered one.

There's some ambiguity on that. They may well be right but no one seems to know to be honest. Might be worth someone getting a definitive answer from the guys in Adastral Park who invent the things. Until there's a proper answer I always think it's worth fitting a separate RF3.

Well it was all going so well and this weekend it's started dropping again

Therefore I've re-raised it with TalkTalk.