If you have a connection that isn't disconnecting I can't see why in your right mind you would use the disconnecting connection for anything much, why do it to yourself... It's not going to get any better through using it a bit more so it just sounds like a hiding to nothing much.

Personally in your situation I would take the Samknows box and put it on the non-GEA line and see how that is behaving, to prove that you have a significant difference between the two, and you really do have one good line... Worst case you might actually have an issue on your non-GEA line too, that you're not really being alerted to, given your GEA line appears to speedtest OK.

Ah, but it's not totally that simple! The GEA line I have is only for testing (supplied by Zen), and the data I want to put through it is hardly 'critical' - won't put my my work or emails/domains etc through it yet.

I am really keen to get to the bottom of the real problem, and if I can help, then that's what I will do. I do know that my BTW line is good, as everything returned exactly to normal when that went in, but to really see what the GEA line is doing, I want to see something like 'real-world' traffic and look at what happens.

A quick look at SamKnows data shows things not quite as bad as since 7th September(number of disconnects and duration), no idea why though.

I restate that when things were bad here, it was nearly unusable, obviously not quite like that now, but trying to chase up what may be actually behind those problems.

I am really keen to get to the bottom of the real problem, and if I can help, then that's what I will do. I do know that my BTW line is good, as everything returned exactly to normal when that went in, but to really see what the GEA line is doing, I want to see something like 'real-world' traffic and look at what happens.

Your perseverance is admirable. I guess driven in part by your professional background in software testing and wish to understand what’s broken and why. You may never find out.

I suspect that this issue is a problem on the margins, but deeply rooted within the core network that Zen have deployed that serves their new GEA backhaul.

As you know internet fora can become echo chambers of self resonating doom - and I agree it is almost impossible to say (on here) how widespread and deep this problem is, nor how many of their customers are actually affected. It might be less than a dozen. It might be hundreds. It might be thousands.

The only folks that know are Zen networks team and so far it’s been extremely quiet.

Yes, but while it is frequently disconnecting though it is very obviously broken, Zen should already have more than enough to investigate that if they want, so really you would be better served yourself using the resource you have (time with the Samknows box in your possession) checking that your good line really is good, than trying to further investigate just how broken the bad line is.

One test which might be worth doing is swapping the ONTs between the cables in case one of the cables has a bad termination, as unless they run on a different PON you should find the GEA and non GEA connections follow the ONT and not the fibre. You might only want to do that under discussion with Zen though, and proceed with care as Pew pew laser beams.

If the customer drops are coming from the same CBT, then they will be on the same PON. Openreach don’t to my knowledge serve the same CBT with different light. It’s always the same PON.

Saying that I recall that one of the posters on the precursor to this thread had immediate neighbours on a different PON (using ECI gear as I recall) from an earlier partial FTTP deployment in the neighbourhood. Then there was a later connectorised CBT deployment on Huawei gear for the remaining properties.

Can’t recall if it was Steve though.

I guess my overarching point outside of ONT experimentation is recalling Steve's previous messages on this, he was under the impression that the GEA line was now fine, but I'd say the Samknows box is saying anything but fine with that level of disconnections. If the same level of "fine" is applied to the non-GEA line, that also might not be great. Hence why it's worth investigating the non-GEA line in more detail as that is the one he's probably going to be using longer term, while Zen are fully engaged. It is possible they are both "a bit less rubbish" than previous, below the threshold of being noticeable much in normal use.

I have wondered for some time why the so called experts at Zen haven't sent Steve a Samknows box for each line so they have second by second comparisons.

Yep follow your logic, but as each ONT is tied to a particular service (and hence backhaul) you would literally only be 'testing' the difference between the drop cables from the street (OK optical path from the output of the splitter to be pedantic). Which you could do but I think the probability of finding the issue there is quite remote.

The disconnections list Steve shared looked pretty grim. I think there's a reasonable chance they could be down to a physical connection. But it could be the whole PON, or it could just be the GEA link.

For reference, for my connection on GEA, this was the reported disconnections by the samknows box, and at least one lot of them was me playing. So I guess the point here is disconnections don't look to be an expected thing on GEA.

https://photos.google.com/share/AF1QipMWbRVSne4nu5U0...

This was the following 7 days for Steve:
https://prnt.sc/X2qFgxmyt_er

Mine was already off GEA by then, so I can't share comparable days. If Steve clicks the "Month" button on the dashboard he could show whether he was having disconnections prior to the 1st of Sept.

Edited by jimbof (Sat 10-Sep-22 17:51:26)

They were very keen to get mine back off me. I expect they don't have many of them. But i agree, it just seems a bit bonkers to go to all the cost of putting in a second line without having monitoring on both...!