Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ixel]

Reading this thread recently, it appears to me that Zen haven't really improved over the last few years sadly. It looks like you'll need to change provider.

If you're going down that route, which by emailing cancellations I'm assuming that you are, if they don't budge then leave them a detailed and critical Trustpilot review instead. I did this years ago when I had issues which at the time they weren't really interested in resolving. Someone got back to me from Zen within a few days of that review, regarding that review, and they decided to release me from the contract as well as refund some months of service on top. Trustpilot reviews can be a powerful tool for customers to use sometimes.

[bogof]

Reading this thread recently, it appears to me that Zen haven't really improved over the last few years sadly. It looks like you'll need to change provider.

If you're going down that route, which by emailing cancellations I'm assuming that you are, if they don't budge then leave them a detailed and critical Trustpilot review instead. I did this years ago when I had issues which at the time they weren't really interested in resolving. Someone got back to me from Zen within a few days of that review, regarding that review, and they decided to release me from the contract as well as refund some months of service on top. Trustpilot reviews can be a powerful tool for customers to use sometimes.

Yes, where I am at the moment it just makes no sense to carry on battling with whatever it is that is causing Zen's network variability for me.  It's already wasted an inordinate amount of my time going back and forth with them once, so to have the fruit of all that work (the decision to go back to BTW, which fixed the issues) revoked so randomly and without warning is just inexcusable.

You'd like to hope it wouldn't take such measures, but I'm losing confidence in that by the day.  I called in yesterday to check the cancellations had received it, and they said they'd get someone to get back to me, which hasn't happened yet.

While there's no guarantee some other service provider won't have issues too, I think so long as I constrain the provider selection I should be quite safe.   if I can at least stay away from providers using Zen backhaul - which would avoid geographic Zen specific issues - I should be reasonably safe.  I already know BTW in the area can offer full reliable 900Mbps+.  So I think BT business will probably be in the frame.  I am considering AAISP, but I can think of a few pros and cons there given their relatively recent arrival in the 900Mbps service category.

[bogof]

I'm officially in the "looking for another provider to complain about" business now - Zen have just agreed to release me from contract. 

Seems to be quite hard to get good data on just how well the various providers are doing with the top FTTP packages

Given BTW from here to Zen seemed performant, I'm tempted by BT Business as an option.

Also considering AAISP, though price and the recent arrival nature of their offering make me hesitant.

Intrigued by Cuckoo, particularly as they had no contract.  BTW / TTalkTalkBusiness there though.  I've not seem much info about performance, and did see a post or two about lacklustre single thread performance on TTB.

Any thoughts on alternatives appreciated.

[burakkucat]

Perhaps it would be worthwhile to "draw a line across the bottom of this topic", now that you are leaving Zen, and to start a new thread regarding which provider's service to consider?

[bogof]

I think you are of course right.  I will make a separate post later.

[burakkucat]

I will make a separate post later.

Thank you. 

[bogof]

This seemed the most appropriate place for it:
https://forum.kitz.co.uk/index.php/topic,27311.0.html

Though if anyone has any other questions or observations about the Zen GEA fiasco, or ideas for tests, let me know here.  I probably have the Zen line for a couple of weeks at least.

[craigski]

I have a theory, I'm not an expert in how this all hangs together, I'm going to use the word 'pipe' to describe a backhaul connection, as I'm not sure what correct terminology is, here we go:

It seems the 'backhaul' (what ever that is) could be the bottle neck when running a 'single thread' speedtest, and only seems to affect some users on maybe particular exchanges.

I'm assuming this 'backhaul' is some kind of layer 2 connection from OR at the exchange to the ISP. This could be a big fat pipe (10G+) and/or could be aggregated by multiple pipes (possibly slower 1G?) to achieve more bandwidth. The slower pipes are more that sufficient for FTTC.

When running a single thread connection on a FTTP 900, and if the path is on a aggregated link, you are limited by the available bandwidth on a single slower pipe, rather than being shared across multiple pipes. Or maybe it is shared across multiple pipes but it takes time to reassemble the packets.

I can see the benefit of multiple aggregated links for redundancy, SLA, etc.

As BTw are wholesale, they can afford to put big 'pipes' in, as supporting multiple ISPs so you don't see the issue using BTw as backhaul.

However, in a typical use case of multiple users using multiple devices, these connections would be spread across all of the aggregated links, and would achieve the full connection speed.

So, if you are using an ISP backhaul rather than BTw, and that ISP backhaul is using aggregated links, and you are running a single thread 'speedtest' you will see the issue. The ISP could upgrade the links, but I assume can not justify this until they hit a threshold of FTTP users.

This may also explain why some providers do not sell 900 services in all exchanges, because they don't have fast pipes (yet).

Or maybe I have this totally wrong?

[j0hn]

If it was just down to what you say then providers wouldn't be able to make small config tweaks to fix single thread issues.

The right provider fixes single thread issues. It usually isn't a fibre/hardware bottleneck.

It's also extremely unlikely your data is being split at the exchange and different threads of the same download are running down separate fibres across the backhaul.

Single thread issues were (are) also a thing on FTTC for people on 80Mb/s and less connections.
That's not because the pipes are too small.

It's often down to things like the backhaul provider having a "hot" svlan.
Moving the customer to a less congested svlan fixes single thread issues for many.
Poor config usually.

[bogof]

My understanding is the PPPoE is terminated after the traffic has entered the ZEN GEA network.  So it's hard to see how the backhaul has an effect, though it seems to, yet I had good performance on the same gateways when on BTW backhaul, which then got much worse when moved back to ZEN GEA, and this hasn't been some configuration fluke as it's looked the same now twice on Zen GEA and twice on Zen BTW.  It's very confusing.  And why my results would appear to be different to other people's on what appears to be the same gateways, again seems strange (maybe there is more to what gateway you are on than just its IP address).

But I'm getting into theorizing now on what could be wrong that's causing such odd behaviour, which seems particularly futile now I've committed to leaving!  I should be migrated to AAISP on 26th Oct.
If anyone has any tests they think are interesting to run before that happens then I'm all ears.  I'm going to be interested to see if AAISP is much different, I'm hoping it is.

[Ixel]

If AAISP isn't better, which I would be a little amazed if that were the case, I'm fairly certain that their support team would be interested in resolving the problem. Hopefully AAISP will be considerably better for you.

[bogof]

If AAISP isn't better, which I would be a little amazed if that were the case, I'm fairly certain that their support team would be interested in resolving the problem. Hopefully AAISP will be considerably better for you.

I'm sure it will be, given Zen via BTW was also good for me.  There's always just that small question of the unknown.

[Chrysalis]

You know whats funny guys, TT were having some stability issues lately so I migrated to BTw, I assumed BTw congestion days were gone given all the nice reports about them on FTTP, but I have the exact same problems as you guys now, slow single threaded, line rate multi threaded on BT wholesale lol.

BT wholesale are struggling to even do single threaded 20mbit/second, so I guess they still have congestion problems on their platform  TBB visible congestion since around 5pm.  Surely they must be using a different platform for FTTC and FTTP as FTTP rates that low would be really bad.  I expect AAISP to give me a quick resolution though, it wouldnt be surprising if I run back to talk talk now with tail in between my legs.

[bogof]

You know whats funny guys, TT were having some stability issues lately so I migrated to BTw, I assumed BTw congestion days were gone given all the nice reports about them on FTTP, but I have the exact same problems as you guys now, slow single threaded, line rate multi threaded on BT wholesale lol.

BT wholesale are struggling to even do single threaded 20mbit/second, so I guess they still have congestion problems on their platform  TBB visible congestion since around 5pm.  Surely they must be using a different platform for FTTC and FTTP as FTTP rates that low would be really bad.  I expect AAISP to give me a quick resolution though, it wouldnt be surprising if I run back to talk talk now with tail in between my legs.

Would love to understand the mechanism by which the backhaul affects single threaded performance.  Given you're talking to some real people at AAISP instead of 'droids, maybe you can ask them what gives?  Since it seems very odd when you'd consider that the PPPoE session I think terminates at AAISP.  As a relative luddite it's hard to explain the mechanism.

[Alex Atkin UK]

Would love to understand the mechanism by which the backhaul affects single threaded performance.  Given you're talking to some real people at AAISP instead of 'droids, maybe you can ask them what gives?  Since it seems very odd when you'd consider that the PPPoE session I think terminates at AAISP.  As a relative luddite it's hard to explain the mechanism.

Agreed, you'd think single or multi-thread would look the same on the backhaul if all its seeing is the PPP tunnel.