Poor running speed on Infinity 200m from exchange

[stchedro]

• We have two VDSL lines that are FTTC on a 40/10Mb/s unlimited business service
• We are located 200m from the cabinet which is right against the wall of the exchange
• We are connected to ports 1 & 2 in the cabinet
• Two engineers have confirmed that we have new cable infrastructure
• One line tests at 128Mb/s down stream the other tests at 131Mb/s which is 3 times the bandwidth that is required for the subscribed service.
• On installation the maximum throughput measured was 24Mb/s the throughput profile is suspiciously flat as if it is being capped – there are no spikes above the 24 Mb/s
• However, the negotiated rate is shown as 38Mb/s on both lines
• We are tried a number of routers and modems including 3rd party – BT’s appear to be of very poor quality – however this has had no more than minimal effect on the throughput
• Ping tests show no packet loss
• We don't get significanlty faster download than we did on ADSL which was at around 21Mb/s although the upload is around 10x faster than it was at 8Mb/s

Observations

• All three engineers who have been to site have commented on the excessive ping times in excess of 20ms whereas they would have expected 6-9ms given the proximity of the cabinet. We have never seen less than 18ms with any equipment
• None of the engineers seem to have had any training in how to diagnose a port fault or how to investigate if a bottleneck exists between the cabinet and the backhaul. Infact there is a distinct disinterest in getting involved in throughput issues.
• The ‘diagnostics’ rely on a system that clearly does not interrogate and test every hop on the system and it can’t possibly be loop testing each step hop otherwise it would quickly find the bottlneck

Case Conclusion

• Given the nearly 100% discrepancy between negotiated and delivered rates it is pretty clear that there is a bottleneck.
• Given that both copper lines test perfectly the fault must lie at either end.
• As the equipment at our end has been swapped out for a number of different units including 3rd party VDSL modems the fault likely rests between the port and the backhaul
• BT are either unwilling or unable to diagnosee FTTC throughput faults
• with the excessive response times caused by the latency 'blazingly fast' it ain't it actually feels quite sluggish to respond

Global conclusions

• Although BT can’t really blame the capacity of the copper connection the propensity to blame ‘unknown’ factors remains. Bluntly in an all digital system there are no unknowns that cannot be tested. This is purely an issue of competence and or willingness. The trouble with identifying faults is that you have to fix them so a level of fault blindness seems to be willfully introduced.
• BT FTTC isn't a business grade product
• If it doesn't work with a close to ideal case such as ours there is little prospect of it working properly elsewhere

[paragon123]

This happens everywhere no matter what line you use.

I think it's best to either look for another plan that might work pretty well for you. Because you don't want to pay for a service that you are not fully taking advantage of. I understand how this works and we really can't blame the provider.

[stchedro]

Actually I disagee it doesn't happen everywhere and it certainly shouldn't happen when the copper line measures properly. We have around 10 broadband connections to various sites and they mostly work rather well. 

Once it has gone from the port into the DSLAM then it is simply a glorified layered IP network. Getting the traffic managemnt and prioritisation wrong in that is pretty silly, as it is well known how to do it. Lets face is VDSL isn't cutting edge it is, politely, a very mature technology.

My suspision is that the assigned bandwith to the connection is misset at 40Mb/s and for a 40/10 that means that once the reserved frequenceis are taken off between voice and upstream the downstream is left with limited bandwidth. That is in all likelyhood a config error and pretty simple to sort it should of course be set to 50Mb/s. The maddening thing is that nobody has the power to investigate what is going on from end to end.

[325consultancy]

Hi,

If you want to contact me directly I'd be happy to follow up on this issue with the Infinity Fibre team and try and get some answers for you.

karen@325consultancy.com

Best regards,

[stchedro]

And still no response from BT even to the complaint I submitted before Christmas!

[stchedro]

Well we have had another engineer come out and go through all the copper side gear and confirm that it is all 100% and he can't understand what is going on either. Nice guy, very, very, very thorough. 

The nub of the issue is that BT blame OFCOM for preventing faults being handed between OpenReach and Wholesale.  I don't think OFCOM intend that at all and it is being used as a convenient excuse to shelve issues of marginal functionality.

As Wholesale own the Port - DSLAM in the big green cabinet the engineer needs their say so to start tinkering with it.

However, the engineer can't get a number to speak to Wholesale whilst onsite: he (the nice engineer) tried but no dice.

Where there is a hard fault and the OpenReach Engineer has confirmed it is should go through an automated triage. Along the lines of we have done all our tests it isn't at spec therefore a deeper investigation is required.

At the moment the only way it gets triaged is if you start complaining very very loudly.

[MHC]

OFCOM - don't get me started!   Their rules really make things difficult and BT get their knuckles rapped if they try to bend the rules.   It is almost certainly totally true.

I had a fault, and it was obviously ORs responsibility.   Spoke to Business faults, who had to speak to their Point of Contact, who then spoke to the OR Point of Contact who spoke to the repair team in OR who spoke to the specific middle manager ... How many extra layers and delays in that?   Too many ...

OFCOM put rules and regulations in which attempt to make it "fairer" but ultimately the end user or customer pays.   

Another example:   I needed a fibre feed from an overseas site into a UK location.   BT could break out and give us a feed.  But NO,  OFCOM required it to be run all the way to London, turned round and run all te way back to the location where both we and BT had facilities.    The extra cost was measurable in tens of thousands of pounds per year!  

[stchedro]

Well partial sucess

One of the enigneers who had previosuly been out appeared and said this is riduculous. The sync speed and the throughput doesn't match.

So he had a bit of a brainwave and said why doesn't he measure the throughput at the cabinet end. In this instance not to difficult as the cabinet is bolted to the wall of the excahange. So off he goes with the router and the modem and come back saying it makes hardly any measurable difference is the moden is connected to the cabinet or in your office "the problem is in the cabinet." He also disconnected the exchange end so he was testing just the DSLAM which eliminates the possibiltiy of dodgy filters spewing out the wrong frequencies etc.

Armed with this info he then persudes the power that be in Wholesale to do a lift and shift: this of course goes wrong and "gets stuck." Not his fault but after all this it did feel like the last straw.

However, the good news was when it was "unstuck" two days later 37/8 suddenly appeared. I'm perferctly prepared to accept that this is decent performance.

However, as another engineer pointed out, this doesn't mean it was a port fault it could have been to do with the firmware that is flashed to the port to enable the service.

Now all we need to do is to get this performance done on the other line........

Moral of the story if your sync speed is good and the troughput is dreadful don't accept "it is the copper/aluminum wire BS" becasue BS is exactly what it is.

Really if the sync is good and the throughput is awful then the port should be reflashed as a matter of course. It is a zero cost job that can be done from a remote computer and but it doesn't appear as a solution on the fault handling protocol.

[stchedro]

Hmme

Well now our other number is down totally.

Apparently BT decided to do some work overnight without telling us and it hasn't quite worked out.

Great.

Except that the VOIP system that rerouts the emergency site contacts runs via this Infinity line. And yes there is a backup but if somebody helpfully removes one service then it is running solo.

If they had bother to tell us then we could have moved one RJ45 and been prepared for this.

8/10 people I deal with at BT are very profesional and try desperately to help but they are up against a system that forces them to do, well nothing useful. They know and acknowledge that there is a real problem here that can be fixed.

This isn't just crazy it is sapping huge amounts of productivity from UK businesses. The big question is why are BT still allowed to get away with this as it isn't a customer service isssue it is a pure serivce provision (lack of) issue.