Hi there,

Just replying this point:

"Why there has been no mention or consideration of getting specialist 3rd parties in to put a 2nd pair of eyes on the situation?"

There are already several people working on this internally. Without exaggeration there really probably aren't too many people out there who can be asked. SOOC manufacturers tend to assume you will be running something like Linux on their chips. Certainly out approach of an entire ground up OS, hardware drivers, networking etc is rare to the extend that some initially have trouble believing it to be true. But it really is.

That being said, yes, contact has been made with both TI and ARM on this, suggestions made, ideas explored.

It wasn't mentioned because this is all a pretty standard part of hardware development work, I think, in situations such as this one.

Cheers-

Alex.

There really honestly are good reasons.

And yes you are right! We have somewhat been here before.

-A

Inevitably as time has gone by alternative solutions have come up.

And yes, not all end users can read and understand CQM graphs.

But as a business, I think we would be far far less capable of offering the services and support that we do without the FireBrick.

Not to take away from anything you say, though.

Cheers,
Alex.

Replying hopefully in order:

"Is there much of a market for bonding FTTP?"

Not zero but not a huge amount. As you correctly identify, some of that small amount of demand is from those who wish for higher upload speeds, rather than downstream speeds.

"Utilisation can be measured at the BNG, latency and loss rely on preferential treatment of LCP and without it may be measured out of band with similar accuracy so what customer benefit do you see going forward?"

You are right, CQM was an absolute assassin for problems on copper based RF services. And as fibre services are far more reliable, and not susceptible to things like water, REIN etc. But undoubtedly it has allowed us to diagnose a surprising range of issues with fibre circuits, backhaul network stuff can still be sniffed out, and even things like problematic GPONs etc. And of course So it definitely still has a use.

"Are you folks going to be having the CPE putting customer data in PPP purely for the LCP echoes to keep CQM running?"

At present we feel that it's still the best option to run all "broadband" circuits using PPP. Ethernet is a different matter, although I think we may have some doing PPP over ethernet for specialist reasons.

"Lower power consumption is super important but per subscriber how are the numbers?"

Unquestionably the FB9000 is lower consumption per Mbit/sec or per customer or pretty much however you want to measure it than FB6000. So it is "greener". Really and truly compared to any PC based or (ex Cisco solution it is minuscule. Absolutely tiny. At present we have no plans to launch higher than 1Gbit services via BTW as (I think) they are currently not offering it. We may offer slightly higher services via CityFibre, and blended in with other customers; we don't envisage it being too much of a problem in reality.

"The FB9000 is brand new, can't be purchased yet, what kind of lifespan do you folks see for it?"

The FB6000 lasted something like fifteen years, in active live use. I do not see any reason why the FB9000 wouldn't have a useful life of perhaps close to ten.

Thanks for your comments. Hopefully I've managed to answer vaguely OK most of them! Yours has been one of the most interesting to write a reply to so far!

Cheers-
Alex.

This has been addressed now.

I wanted to wait until there were a few questions, before answering them all in one go; particularly as some questions do repeat, I figured this was the best way.

Sorry if it looks like there's been a gap in contact.

Alex.

I've been on AAISP for the last week or so now and I haven't experienced any speed drops.

I can consistently hit a 940 speedtest wired or wireless (6E, iPhone 15 Pro Max, admittedly sat close to the AP in the living room)

Hi njh,

Thanks for the question.

CQM is rather a blunt animal. It is an echo and response at the PPP layer, which we then graph the timing of. Not much more or less than that. So with that methodology, it's rather hard to get inbuilt diagnostics of the sort you are suggesting.

We have built up a lot of knowhow over the years of how to interpret and read the graphs though as is described in the following article : https://support.aa.net.uk/CQM_Graphs

Over the years these have been able to narrow down a surprising variety of faults.

It would be theoretically possible for us to have realtime stats from things like intermediate hardware, if our carriers allowed it. But it wouldn't be "part of CQM". It could potentially be correlated against CQM data, though. Honestly I doubt this is likely to happen though, as carriers are famously defensive about giving anyone detailed stats about their networks and equipment (and understandably so).

If you've not seen the wiki page above before, it might give you a new appreciation of what sorts of stuff we can infer by looking at graphs at least!

Cheers,
Alex.

Adding to Andrew's point... just for clarity (and others have already said similar to this) ...

I am 100% certain this specific customer's problem is nothing whatsoever to do with the LNS troubles that are the subject of this thread. At no point has there been any impact on throughput. This has been an issue with stability, not throughput in live use.

We will obviously work with the customer to resolve it, just as we would with any other.

Alex.

Edited by aabloor (Tue 23-Apr-24 16:37:38)

Tangential thought :

One possible use of AI would be to make a stab at interpretation of graph results.

We probably won't do it, but it feels like it would be a perfect application.

Alex.

In reply to a post by aabloor:

Tangential thought :

One possible use of AI would be to make a stab at interpretation of graph results.

We probably won't do it, but it feels like it would be a perfect application.

Alex.

It's what day job and others do: use AI to interpret telemetry and both assist with reporting and take action where appropriate.