Register (or login) on our website and you will not see this ad.
|
|
It happened again last night, I was routing via Manchester for about 16 minutes (02:57-03:13): Seems like the exact opposite to me. I'm only around 10 miles from you and it's the opposite situation. I had 10 minutes or so when I was bounced to London with a nice ping, higher speeds on speedtest etc. Then back to Manchester.
|
|
|
It is Zen's own backhaul and fibre as far as I know, so if that is the case then there are no extra costs even if they do go a long way around. If they just let everyone take the shortest route its likely they have an imbalance with one side of their network under utilised and the other segment over utilised, so to keep things balanced some customers end up going the long way around.
Here's the problem I have with this.
I'm not in London, I'm to the west, but only a little. From my Cityfibre "exchange" or whatever Cityfibre call their local nodes Zen picks it up on their own network.
Now, I cannot possibly see a reason that Zen would run their own network from an exchange in the south to both Manchester AND London. This was why I initially assumed Cityfibre were routing me internally toward the Zen BNG I was connecting to (Manchester).
As such, if Zen are using their own backhaul network. It would make sense that they would run from localised exchanged to the nearest larger node and onward to either London or Manchester. It would seem wasteful to run parallel to both from everywhere. I admit I don't know this of course. But, it would seem pretty wasteful to be running independent connections from the south to the North. They would almost certainly rather aggregate connections like this to the largest pipe they can between London and Manchester and route in from exchanges to the nearest physically no?
As such, I can only imagine they're running from my exchange into London, then up to Manchester, to the BNG and then routing almost all my traffic back down to London.
Essentially I don't mind the ping, it's just the whole situation seems to be a bizarre choice to me.
|
|
|
It happened again last night, I was routing via Manchester for about 16 minutes (02:57-03:13):
My Broadband Ping Interesting to see that- I'm with IDNet on Zen backhaul and saw the same- https://www.thinkbroadband.com/broadband/monitoring/...
(Post here: https://forums.thinkbroadband.com/idnet/t/4773185-ve... )
Edited by billford (Thu 27-Feb-25 12:12:49)
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
Now, I cannot possibly see a reason that Zen would run their own network from an exchange in the south to both Manchester AND London.
It would seem wasteful to run parallel to both from everywhere. I admit I don't know this of course. But, it would seem pretty wasteful to be running independent connections from the south to the North.
Diversity?
Failure of the single link in your scenario could take out a large number of customers.
I used to work in broadcast transmission and I know that every main TV transmitter in the country has at least two programme feeds to it, approaching from different geographical directions, (they are set up in rings). The two feeds go in to a slipless switch at the transmitter, so that failure or degradation of one of the paths would be seamless to the viewer at home.
.
|
|
|
Diversity?
Failure of the single link in your scenario could take out a large number of customers.
I'd expect it to make more sense from here (150+ miles from Manchester, ~30 miles from telehouse) to run redundant links to more than one London peering point and then have redundant links between sites than to run multiple redundant links from exchanges in the south to both London and Manchester.
Even if you did have redundant links. It doesn't make sense to put someone on a link that's not too busy when over 90% of the traffic comes right back to London. I don't know. Just seems a weird network design to me.
I'm also not convinced the comparison to a broadcast network is a good one. Because in a broadcast network you have a single programme feed. If you send it round in a ring you have a predictable amount of traffic to handle. When it comes to the internet, if you have almost all of your peering in London, and you route users in the south into Manchester, you're going to just put all of that traffic on your connection with London.
Any time you route someone 100+ miles out of their way you're putting almost all their traffic back onto that link between Manchester and London. Albeit putting a user in the North onto the London gateway doesn't really detract from their experience, except for the small amount of traffic that has actual peering in Manchester.
Having said all that, I would be prepared to say fine balance the load. EXCEPT you also hear stories of people far in the North connecting to London gateways! It just seems wholly inefficient to me. But, the main problem with the theory of using this as a solution to direct route capacity limitations is that on the rare occasion I do fail over to the more direct route, speedtests etc are faster! So clearly there's some level of congestion on the "best" route over the "worse" one.
I feel like this is one of those legacy things Zen has, and they just don't want to do anything about it. Like I've said already. As people pick up (and actually use) 2.5gbe circuits. I wonder if this will finally cause enough of a problem for them to react.
|
|
|
I'd expect it to make more sense from here (150+ miles from Manchester, ~30 miles from telehouse) to run redundant links to more than one London peering point and then have redundant links between sites than to run multiple redundant links from exchanges in the south to both London and Manchester.
Even if you did have redundant links. It doesn't make sense to put someone on a link that's not too busy when over 90% of the traffic comes right back to London. I don't know. Just seems a weird network design to me.
I'm also not convinced the comparison to a broadcast network is a good one. Because in a broadcast network you have a single programme feed. If you send it round in a ring you have a predictable amount of traffic to handle. When it comes to the internet, if you have almost all of your peering in London, and you route users in the south into Manchester, you're going to just put all of that traffic on your connection with London.
Any time you route someone 100+ miles out of their way you're putting almost all their traffic back onto that link between Manchester and London. Albeit putting a user in the North onto the London gateway doesn't really detract from their experience, except for the small amount of traffic that has actual peering in Manchester.
Having said all that, I would be prepared to say fine balance the load. EXCEPT you also hear stories of people far in the North connecting to London gateways! It just seems wholly inefficient to me. But, the main problem with the theory of using this as a solution to direct route capacity limitations is that on the rare occasion I do fail over to the more direct route, speedtests etc are faster! So clearly there's some level of congestion on the "best" route over the "worse" one.
I feel like this is one of those legacy things Zen has, and they just don't want to do anything about it. Like I've said already. As people pick up (and actually use) 2.5gbe circuits. I wonder if this will finally cause enough of a problem for them to react.
Without seeing how their network runs across the UK its hard for us to guess the reasoning behind it. However taking data up to Manchester and back to London doesn't mean its arriving into London over any of the same fibre that it would do if going to London directly. I suspect the backbone from Manchester to London is completely different fibre to anyone finding themselves going directly to London.
According to Zen's website, they have 8 points of presence, 2 in Manchester and 6 in London. From each exchange they say they have two connections into their backhaul, each of which goes to two different core sites for resiliency, so that is probably one to Manchester and one to London. For reasons of economy and load balancing and simply knowing both routes are up and running, they have both connections in operation from each exchange, rather than one (i.e. the least optimal distance wise) simply sat doing nothing unless required. On connecting which route a customer gets is assigned round-robin style.
https://business.zen.co.uk/our-network
I'm sure this is no different to BT Wholesale as I see varying latency at random where I'm routed different ways, its just BT Wholesale have many more points of present so its not just a choice of Manchester or London so its not quite the extreme change.
Edited by E300 (Thu 27-Feb-25 16:08:23)
|
|
|
E300 beat me to it, but the cost could be something like this.
Without load balancing certain routes might need capital to upgrade the capacity, whilst having other routes under utilised, so they balance it out to get a batter return on the investment.
The vast majority of consumers wont notice this stuff, throughput is by far more important than latency. I personally would be annoyed which is why I dont use Zen, the nice thing about the UK is it does have lots of retail options. So if you dont like it move to another provider, as I agree with the others, Zen are unlikely to change how its working.
Edited by Chrysalis (Thu 27-Feb-25 18:05:50)
|
|
|
E300 beat me to it, but the cost could be something like this.
Without load balancing certain routes might need capital to upgrade the capacity, whilst having other routes under utilised, so they balance it out to get a batter return on the investment.
The vast majority of consumers wont notice this stuff, throughput is by far more important than latency. I personally would be annoyed which is why I dont use Zen, the nice thing about the UK is it does have lots of retail options. So if you dont like it move to another provider, as I agree with the others, Zen are unlikely to change how its working.
Making sure that your new provider is not another IDNet using Zen backhaul.
|
|
|
Without seeing how their network runs across the UK its hard for us to guess the reasoning behind it. However taking data up to Manchester and back to London doesn't mean its arriving into London over any of the same fibre that it would do if going to London directly. I suspect the backbone from Manchester to London is completely different fibre to anyone finding themselves going directly to London.
The problem is that with cityfibre there's no round-robin assignment about it. Once you're on Manchester, you're stuck on Manchester. Even if you connect to a London BNG (which for the last 6 months or so, just doesn't happen unless the Manchester ones are down) the route will be going via manchester (the second hop ping time will become the first hop ping time).
It used to be this way with FTTC that if you got onto a London gateway, you'd be directly connected to London. But on cityfibre something else is going on in the routing before the public IP network that makes the route you take more fixed and not connected to the BNG you connect to.
|
|
|
The vast majority of consumers wont notice this stuff, throughput is by far more important than latency. I personally would be annoyed which is why I dont use Zen, the nice thing about the UK is it does have lots of retail options. So if you dont like it move to another provider, as I agree with the others, Zen are unlikely to change how its working. I'd agree, except throughput is also lower. Speed is extremely variable when connecting via Manchester. Speedtests to the Zen London speedtest server (so I am ONLY using Zen's transit) can vary between 600/600 and 950/950. On the rare occasion I've been "failed over" to the closer London link, not only does latency drop from 13-14ms to 3-4ms. But I get consistent 900+/900+ speedtests onto the Zen speedtest server.
It's not enough to be annoying for me, and the majority of the time I am getting more than enough in terms of speed. But, I just feel like as more users upgrade to 2.5gbe, this contention is only likely to increase.
|
|
|
Pages in this thread: 
Print Thread
