Disappointed with BT?

Well, not really that disappointed, but somewhat unhappy that even BT continue to disregard packet loss and round trip latency as a valid measure of the quality of their services. Overall we are quite happy with BT taking issues seriously.

They do talk of speed during peak hour, and similar metrics, but miss the point that packet loss and latency are much easier to measure and quantify and less subjective. If there is congestion or a fault, then they show in packet loss and latency.

We monitor every line every second for loss and latency and we can see when there are issues very easily. Some parts of BT, notably some of the people in BT Operate, and some more clued up support people, do understand the issue, and will take our monitoring seriously. We have used our monitoring to help BT identify major issues in their network, and even software bugs in supplier equipment. We have shown the merits of loss and latency measures time and time again over many years. I even get calls from BT asking for my help some times!

Loss and latency are well understood as key metrics for any Internet link, and are part of the contracts for some transit providers. Sadly, the product specification still does not cover these key metrics. It is ironic that, for a tenth of the price BT charge to connect me to a few hundred exchanges around the UK, I can get international transit to connect to thousands of endpoints around the globe with a contractual guarantee on loss and latency!

So, when we have one customer who mysteriously gets latency over night on an otherwise unused FTTC line, we expected a bit more from BT in terms of trying to fix the problem. This could be a simple fault or configuration issue in the network or cabinet DSLAM. Finding the cause will help ensure future faults are detected and fixed promptly helping all BT customers.

Sadly we are getting to the stage of BT basically saying they do not guarantee packet loss of latency (which, indeed, they don't), so tough! But if that means a service can be "broken" in this way, we have a service that is no good for either businesses or non-businesses as this sort of peak latency can break VoIP and gamers alike.

To me, it is a clear symptom of a fault and we are trying to help BT find and fix it.

Anyway, I think we'll look to put in a second FTTC for this customer. It may show the same issue or not. It will allow us to run completely independent tests, with only our equipment connected, on one or other line as needed to pin this down. Ultimately, if the new line works and the existing one does not, then we "fix" it by ceasing the old line. Not ideal, as we would rather the underlying cause is found.

This happens to some extent pretty much every night :-


  1. I've noticed Packet Loss and Latency in Ofcom's bi-annual broadband performance reports, but it's hard to know what levels are significant to users in the same way as speeds.

    What would you say are the critical figures or zones for VOIP, gaming or other real-time applications?

  2. I love the monitoring charts that we as customers have access to & indeed the first thing I do each morning is check how many disconnects I have had over night but as a middle aged buffoon I really have no idea what each chart means. Is there any chance for an idiots guide "blow up" of what it all means somewhere on the website?

    1. Hmm, you should not get disconnects over night - talk to support. Does this help?

  3. Ahem. We're BT Technology, Service & Operations now :p

    1. BT Operate and BT Innovate & Design merged at the beginning of the year. http://www.btplc.com/Thegroup/Ourcompany/Groupbusinesses/BTTSO/

    2. Cool. Ken still there I assume. Very keen to work with you guys.

    3. To clarify, I'm not related to the guys you'd be dealing with, I'm from exchange infrastructure plan and build (power, cooling, space etc.) so I'm unfamiliar with Ken!

    4. BT TSOps is a rather confusing acronym, completely different from the correct pronunciation - whenever we work out what's wrong with the links invariably the answer I get back is "BT TITS-up".

      Maybe related, I heard a rumour BTOR is soon to be split into several new companies:-

      BT BAPWND "Borrowed a Pair with No Dialtone"
      BT HTHHBDY "Has the Home Hub Been Delivered Yet"- the new name for the old "No HomeHub-No Install" section
      BT FTTUA "Failed To Turn Up Again"
      BT IKO "I Knocked, Honest"
      BT HGOOTV "Haven't Got One On The Van"
      BT FFRAR "First Fault Report Auto Rejected"
      BT LCR "Line Card Reseated"
      BT NFFAN "No Fault Found Ad Nauseum"
      BT EQ4NY-EY "Expected Quarter 4 Next Year-Every Year"

      and finally

      BT TICTOC/BWAHAHA - the codename for the top-secret 7-hour fix task force

  4. What happened to the problematic line in question in the end? Did BT accept it was a fault and fix it, and/or reveal the cause?

    Interestingly, I note it lost just a single LCP echo in the two days shown - a world of difference from my own FTTC line which sometimes goes for a few minutes between lost LCP echo packets if I'm lucky.

    I'm really hoping the fourth BT engineer today will finally try a new port in the cabinet, where the first three just confirmed that running tests which don't check packet loss fail to show a problem they aren't testing for (in related news, my metal detector doesn't show gas leaks!) and went away trying to close the ticket as "right when we didn't bother testing for the actual reported fault".

    A friend who works in a Dutch ISP's infrastructure team was rather baffled by BT's intransigence on this; for them, trying another VDSL port would be obvious and SOP for a fault like this.


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

Bulk ESP32-S3 programming

Programming an ESP32-S3 is really easy. The S3 has build in USB, which means literally just connecting GPIO 19 and 20 to D- and D+ on a USB ...