In reply to a post by dect:

In reply to a post by S2KIP:

I suspect the issue is that the backhaul from the exchange to the core POP is contended.

Please go back and read this thread as it will become very clear that its not as simple as that.

Only one person (AFAIK) has had their issue fixed by replacing a faulty Cablelink.

Please explain to me how this is not congestion on Zen's backhaul and their reluctance to admit it.

Edited by S2KIP (Thu 30-Jun-22 18:05:48)

In reply to a post by dect:

Don't forget this thread started on 29th March 2022 over 3 months ago and all the pain and heavy lifting of getting the initially extremely slow Zen to do something has already been done by the members here, if you was here at the start of the thread and felt the frustration due to the lack of progress then you may have a different opinion by now.

I am trying to give Zen the benefit of the doubt because what happened in the FTTC days when my previously good Sky 80/20 line started to play up, (probably due to Openreach swapping stuff around to share the issues about. - Under Sky the Openreach Engineers found nothing and as the connection dropped down to 28 mbps which became the new max target to my line.

I moved to Zen and they sent an able Openreach Engineer who found the FTTC fault and my [censored] 28 mbps line became a rock solid 55 mbps line and that is why I still have faith in Zen in spite of the hassles.

All ISPs have issues now and again and its how they respond that is high on my list.

As I pointed out earlier in the thread my move to 900 mbps FTTP on 7th October 2020 was a disaster with months of total hassle and three months ago it started again in its erratic fashion but at least the people at Zen don't try to pretend that it is OK when you contact them. - I will give them a few more weeks and if it is not fixed I will press for more help or an an early release but I am hopeful that they sort it by mid July.

In reply to a post by SteveBushell999:

I have considerable experience here! BEWARE, I was getting perfect speeds using PPPOE directly on my Mac equipment, but when the router (any router) was used, the speeds tumbled.

Yes; I told them that I was not interested in what a MAC PC did or did not do at a specific point in time as that was a Red Herring since most people, (myself included), use Windows and it needs to work properly with Windows..

At least most of the people in Zen Technical Support avoid using a script and they seem to want to provide a good product and that is why I am reluctant to go elsewhere.

That said; I have seriously been looking at getting a separate line only 900 mbps FTTP Broadband connection from BT with a copper phone line change from Zen to a Sipgate Basic VOIP line.

Sorry S2kip, but the issue is massively more complex than that, for a start, Zen's own tests have revealed here and with FakeJake, and by my own tests that the issue IS TCP disconnections, the backhaul IS capable when in this fault condition, of delivering full bandwidth (500Mbits in my case), but only if the connected TCP stack is tolerant of disconnections.....

All well and good, but the Zen supplied router(s)- different manufacturers.... work 100% fine when the line is good (before GEA migration, and when back migrated), but they don't handle the disconnections well (circa 20-100Mbits for me), and using different routers provide up to a 200Mbit region, but very unreliable. When migrated back, all is 100% fine.... How is that contention please? I would point out that I have hundreds of Speedtest runs, iPerf traces etc which all tell the same story. I appreciate your. contents, but in this case it's not backhaul contention, nor is it apparently the other hot chestnut of how we're routed, that may affect the latency, sure, but the bandwidth is still the same it seems. What is it? I am afraid I have a friend who is a Phd in networking, he looked, spent quite a few hours here, and all he said is that it's something at osi level 2.

In reply to a post by S2KIP:

Please explain to me how this is not congestion on Zen's backhaul and their reluctance to admit it.

I take from what you're saying you believe you have a different issue to what we are discussing in this thread as all the main contributors of this thread know the issue we have been discussing for the last 3 months isn't congestion, if you have a different issue then I will leave you to take that up with Zen.

Yes; I told them that I was not interested in what a MAC PC did or did not do at a specific point in time as that was a Red Herring since most people, (myself included), use Windows and it needs to work properly with Windows..

At least most of the people in Zen Technical Support avoid using a script and they seem to want to provide a good product and that is why I am reluctant to go elsewhere.

That said; I have seriously been looking at getting a separate line only 900 mbps FTTP Broadband connection from BT with a copper phone line change from Zen to a Sipgate Basic VOIP line.

No No No !!! The Mac or windows pc's, 2 flavours of Linux all work just fine behind the router, IF the line is good, if not, then they work terribly (chains and weakest links etc....)

Then, still more, using a Mac on PPPOE - Fine... Windows 10 PPPOE - Fine .... Windows Server 2016 on same hardware! as the Windows 10 box on PPPOE rubbish, hence my conclusion that it is the stack that DISPLAYS the problem, not hardware related! But it's just displaying the problem, it is NOT 'THE' problem, that's the fault of the disconnects happening outside our LAN's.... Obviously ANYTHING behind the router is as bad as the router itself is, but even there, it gets way more complicated, read the parts of the thread where I mention speed tests done directly from the Fritz box, which work fine, but apparently they use UDP not TCP, so just don't go there! It's a different pile of (related) poo I fear.

We have 'too much' information, and believe me, every wacky idea in the world has been tried, the problem is outside our control, it's between Zen and BTW - and Lord only knows who else !

Edited by SteveBushell999 (Thu 30-Jun-22 17:33:47)

In reply to a post by SteveBushell999:

Sorry S2kip, but the issue is massively more complex than that, for a start, Zen's own tests have revealed here and with FakeJake, and by my own tests that the issue IS TCP disconnections, the backhaul IS capable when in this fault condition, of delivering full bandwidth (500Mbits in my case), but only if the connected TCP stack is tolerant of disconnections.....

All well and good, but the Zen supplied router(s)- different manufacturers.... work 100% fine when the line is good (before GEA migration, and when back migrated), but they don't handle the disconnections well (circa 20-100Mbits for me), and using different routers provide up to a 200Mbit region, but very unreliable. When migrated back, all is 100% fine.... How is that contention please? I would point out that I have hundreds of Speedtest runs, iPerf traces etc which all tell the same story. I appreciate your. contents, but in this case it's not backhaul contention, nor is it apparently the other hot chestnut of how we're routed, that may affect the latency, sure, but the bandwidth is still the same it seems. What is it? I am afraid I have a friend who is a Phd in networking, he looked, spent quite a few hours here, and all he said is that it's something at osi level 2.

I'm talking specifically about latency and not throughput. I'm happy for your friend.

The latency was never a problem for me, save when it was so bad that TCP times out! Obviously, being on the same backhaul (via BTW now) - if Zen had backhaul issues then I'd see them now, which I don't, nor time outs, nor bad latency..... QED

Edited by SteveBushell999 (Thu 30-Jun-22 17:58:37)

In reply to a post by S2KIP:

I suspect the issue is that the backhaul from the exchange to the core POP is contended.

That doesn't match what I'm seeing here now that OR fixed a line card in the exchange. My connection has been perfect since (on the GEA migrated line).

In reply to a post by SteveBushell999:

Obviously, being on the same backhaul (via BTW now) - if Zen had backhaul issues then I'd see them now, which I don't, nor time outs, nor bad latency..... QED

No you wouldn't. You aren't on Zen backhaul anymore. You are on BT Wholesale backhaul.
It isn't the same backhaul with a different GEA cablelink. That's not how it works.

Last time I tried explaining the topology you just accused me of missing the point that Zen were responsible either way. A point I had never argued or raised.

Edited by j0hn83 (Thu 30-Jun-22 22:08:29)

In reply to a post by S2KIP:

Only one person (AFAIK) has had their issue fixed by replacing a faulty Cablelink.

Faulty line card on the L2S, apparently, rather than Cablelink. Minor point.