|
|
Hi all, I have been browsing this forum for years but today is my first time signing up and raising questions!
I'm from Manchester, was using Hyperoptic in my last place and the ping time can be as low as 1-3ms which is fantastic.
However I recently moved to a place which doesn't have Hyperoptic FTTH/FTTB coverage but Openreach FTTP, so I'm trying to find out which ISP provides the best ping?
For BT FTTP, I'm aware of the ping time to bbc.co.uk from Manchester currently sits at 10-20ms, depending the tier of services you're using (yes, 36Mbps has much higher ping time than 330Mbps!).
But how about other FTTP ISPs? Aquiss and Zen are on my list, I personally preferred to Aquiss as it's cheaper... but seems Zen has direct links from Manchester which is very attractive too!
Any thoughts from anyone? Or anyone can share their ping times of Aquiss and/or Zen for comparison? Cheers all
Edited by guyinman (Wed 08-Apr-20 12:14:08)
|
|
|
Here's mine from Aquiss on FTTP 3 80/20
Pinging bbc.co.uk [151.101.0.81] with 32 bytes of data:
Reply from 151.101.0.81: bytes=32 time=9ms TTL=59
Reply from 151.101.0.81: bytes=32 time=9ms TTL=59
Reply from 151.101.0.81: bytes=32 time=9ms TTL=59
Reply from 151.101.0.81: bytes=32 time=9ms TTL=59
Ping statistics for 151.101.0.81:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 9ms, Maximum = 9ms, Average = 9ms
|
|
|
|
Ping to what? Where you are pinging is key to the question. If on Hyperoptic you were pinging London from Manchester then I think you would have been breaking some rules of physics to do it in 1-3ms. It is possible that on Hyperoptic doing a ping was pinging a local server close to Manchester to be able to get pings that low.
The question of where you are pinging is important. If pinging something in London then it wouldn't matter if the main link connection for the ISP was in Manchester or London as it would still take about the same time - but if you were pinging something in Manchester and the internet main link was in London then the ping would have to travel to London and then back to Manchester meaning a longer transit.
Also, if pinging US then some ISPs might have better routes than others. And those routes may dynamically change depending on Internet usage and line conditions.
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
|
Are you in Manchester? If not you would need to say where in the country you are as locations are critical in ping times.
|
|
|
Here's mine from Aquiss on FTTP 3 80/20
Pinging bbc.co.uk [151.101.0.81] with 32 bytes of data:
Reply from 151.101.0.81: bytes=32 time=9ms TTL=59
Reply from 151.101.0.81: bytes=32 time=9ms TTL=59
Reply from 151.101.0.81: bytes=32 time=9ms TTL=59
Reply from 151.101.0.81: bytes=32 time=9ms TTL=59
Ping statistics for 151.101.0.81:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 9ms, Maximum = 9ms, Average = 9ms
Thanks! Which city are you from?
Edited by guyinman (Wed 08-Apr-20 11:57:56)
|
|
|
Ping to what? Where you are pinging is key to the question. If on Hyperoptic you were pinging London from Manchester then I think you would have been breaking some rules of physics to do it in 1-3ms. It is possible that on Hyperoptic doing a ping was pinging a local server close to Manchester to be able to get pings that low.
The question of where you are pinging is important. If pinging something in London then it wouldn't matter if the main link connection for the ISP was in Manchester or London as it would still take about the same time - but if you were pinging something in Manchester and the internet main link was in London then the ping would have to travel to London and then back to Manchester meaning a longer transit.
Also, if pinging US then some ISPs might have better routes than others. And those routes may dynamically change depending on Internet usage and line conditions.
Let's treat bbc.co.uk or google.co.uk as reference - don't worry about overseas traffic
The problem with BT is, it's always connecting to the Docklands (London) before going anywhere else. This cause extra delays of ~10ms (even more if you are at Scotland).
|
|
|
Are you in Manchester? If not you would need to say where in the country you are as locations are critical in ping times.
Yes I do. That's why a local server will be ideal, who likes the traffic all the way to London!
|
|
|
|
So the consideration to get you maximum speed is going to be only ISPs that have a dropout in or near Manchester to minimise any extra traffic. However, as most servers are probably based in London then for practical purposes it wouldn't make much difference.
The other thing to consider around type of traffic is the ISPs that have content distribution networks. If you are using things like Netflix then with an ISP like BT the service will mostly come from a much closer CDN rather than going to the main servers.
Low ping really doesn't mean much unless there is a specific service you need a low ping on. Gaming generally if you ping is really low tends to have built in delays to ensure that people on a very low latency don't get an advantage over the "average" latency player.
So, what services are you using specifically that you need low latency for and it is those you need to be testing - pinging bbc or google doesn't really tell you anything about real world performance.
|
|
|
So the consideration to get you maximum speed is going to be only ISPs that have a dropout in or near Manchester to minimise any extra traffic. However, as most servers are probably based in London then for practical purposes it wouldn't make much difference.
You're correct! What I'd like to find out is whether Aquiss or Zen has a better optimisation of traffic (without necessarily going via London).
|
|
|
Asking for google and bbc comparisons is a waste of time since they use multiple hosts rather than www.bbc.co.uk for example a single server based in London.
Curious about the idea that icmp ping is noticeably different between the 40/10 service and the faster variants. If looking at latency people are posting in speed tests that is likely to be the case as these invariably show a return trip time for a small TCP packet.
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
Asking for google and bbc comparisons is a waste of time since they use multiple hosts rather than www.bbc.co.uk for example a single server based in London.
Curious about the idea that icmp ping is noticeably different between the 40/10 service and the faster variants. If looking at latency people are posting in speed tests that is likely to be the case as these invariably show a return trip time for a small TCP packet.
The flow of traffic I'm looking for is:
My home (Manchester) <=> ISP server (Manchester / The North) <=> Outside World
Hyperoptic does achieve this. Not sure for Aquiss / Zen.
The traffic I don't want to see is this:
My home (Manchester) <=> ISP server (London Docklands) <=> Outside World
Extra latency occurred, not ideal.
Edited by guyinman (Wed 08-Apr-20 12:24:00)
|
|
|
|
But what services are you using where you would see any real world difference in that latency? And going back to what I said earlier some of those services are more optimised within ISPs like BT using CDNs. A link that drops out in Manchester may still have to travel through London to actually then get to whatever service it is you are using. Chasing pings to services that aren't impacted particularly by latency is not going to give you any real world benefit.
|
|
|
But what services are you using where you would see any real world difference in that latency? And going back to what I said earlier some of those services are more optimised within ISPs like BT using CDNs. A link that drops out in Manchester may still have to travel through London to actually then get to whatever service it is you are using. Chasing pings to services that aren't impacted particularly by latency is not going to give you any real world benefit.
e.g. Remote Desktop? 2ms vs 20ms do make some differences.
|
|
|
|
But where is the remote desktop server? If it is in Manchester and you are then I can see that would make a difference (although running remote desktop over a 20ms+ link is still usable for most tasks). If that is your specific requirement (and this is the first you have said that) then I suspect the number of people on this forum reading your post will not be enough to get a meaningful response specifically for the Manchester area. You might need to contact your preferred ISPs directly to ask them if they have Internet POPs doing drop outs to public Internet within your area.
|
|
|
But where is the remote desktop server? If it is in Manchester and you are then I can see that would make a difference (although running remote desktop over a 20ms+ link is still usable for most tasks). If that is your specific requirement (and this is the first you have said that) then I suspect the number of people on this forum reading your post will not be enough to get a meaningful response specifically for the Manchester area. You might need to contact your preferred ISPs directly to ask them if they have Internet POPs doing drop outs to public Internet within your area.
That's why Remote Desktop is just an example - Latency is sometimes more important than speed 
Anyone else in the North can share their thoughts please?
|
|
|
|
So are you saying you aren't using remote desktop? Are you asking because you have a specific low latency requirement or are you chasing low latency as a want rather than a need? You might find that getting a low latency ISP may mean you end up compromising on other features that could be more relevant to your actual Internet usage.
|
|
|
So the consideration to get you maximum speed is going to be only ISPs that have a dropout in or near Manchester to minimise any extra traffic. However, as most servers are probably based in London then for practical purposes it wouldn't make much difference.
You're correct! What I'd like to find out is whether Aquiss or Zen has a better optimisation of traffic (without necessarily going via London).
Or you could just ask us
The traffic is taken from your local area to the nearest of 30 regional PoPs around the country, then into the core network.
So in Manchester, it's taken into MANAP and then down the core network and routed according out via the exit PoP/Peering exchange nearest to where you are trying to reach. The core network also has a presence in Europe, remaining within the core network.
Martin Pitt
Company Founder
Aquiss Limited
https://www.aquiss.net
FTTC, FTTP, GEA, EFM, Leased Lines, Telecoms and Hosting
|
|
The above post has been made by an ISP REPRESENTATIVE (although not necessarily the ISP being discussed in the post).
|
|
|
For BT FTTP, I'm aware of the ping time to bbc.co.uk from Manchester currently sits at 10-20ms
It shouldn't be anywhere near as high as 20ms.
With BT FTTC it's a 16ms ping to bbc.co.uk from Edinburgh.
BT FTTP nearby it was 15ms last time I checked.
BT FTTP should be nearer to 10ms than 20ms from Manchester to London.
Not many ISP's do the Manchester peering you want.
Zen's Manchester peering is very hit and miss and can switch between Manchester/London with a new PPP session.
You would need to check with Zen if they definitely do Manchester peering on FTTP as it may differ across products.
There isn't a whole lot hosted in Manchester so the vast majority of your traffic would go via London anyway.
|
|
|
So the consideration to get you maximum speed is going to be only ISPs that have a dropout in or near Manchester to minimise any extra traffic. However, as most servers are probably based in London then for practical purposes it wouldn't make much difference.
You're correct! What I'd like to find out is whether Aquiss or Zen has a better optimisation of traffic (without necessarily going via London).
Or you could just ask us 
The traffic is taken from your local area to the nearest of 30 regional PoPs around the country, then into the core network.
So in Manchester, it's taken into MANAP and then down the core network and routed according out via the exit PoP/Peering exchange nearest to where you are trying to reach. The core network also has a presence in Europe, remaining within the core network.
Oh hi Martin, the MD of Aquiss! Made me shocked!!
That's the best answer I wanted to hear, I did use BT FTTP for a really short while but was really depressed by their routing all the way to London and back...
Please let me dig into slightly deeper - is the ping depending on the tier of Aquiss package (Qos) I'm applying for?
I'm just awaiting Opt 5/6 roll-out to be honest... not for the speed but lowest ping to the exchange
Many thanks Martin!
|
|
|
For BT FTTP, I'm aware of the ping time to bbc.co.uk from Manchester currently sits at 10-20ms
It shouldn't be anywhere near as high as 20ms.
With BT FTTC it's a 16ms ping to bbc.co.uk from Edinburgh.
BT FTTP nearby it was 15ms last time I checked.
BT FTTP should be nearer to 10ms than 20ms from Manchester to London.
Not many ISP's do the Manchester peering you want.
Zen's Manchester peering is very hit and miss and can switch between Manchester/London with a new PPP session.
You would need to check with Zen if they definitely do Manchester peering on FTTP as it may differ across products.
There isn't a whole lot hosted in Manchester so the vast majority of your traffic would go via London anyway.
As said the ping of BT FTTP also depends on the speed you applied for, but anyways 15ms is still bad in my mind, even Virgin Media may be better than this...
Hyperoptic does have local exchanges, so as Aquiss just mentioned above. Those have proved not all traffic (although mast majority) has to go via London
|
|
|
I'm just awaiting Opt 5/6 roll-out to be honest... not for the speed but lowest ping to the exchange 
For an individual ping it won't make any difference.
The raw modulation speed on FTTP is 2.4G downstream, 1.2G upstream. This is the same regardless of which package you're on. Therefore, the time to transmit a single packet is the same.
Now, there is shaping in the OLT so that once you start receiving or sending a whole load of packets, and your average usage exceeds the line profile, the later ones are delayed so that you get the average bits-per-second throughput that you've paid for - typically using a "leaky bucket" algorithm. But if the bucket doesn't fill, there's no delay.
The result is: if you're on (say) 145/30, and as long as your short-term *average* usage is less than 145M down / 30M up, then you won't get any extra delay.
I can observe this on speedtest: I'm on 300/30, and outbound traffic bursts above 30 for a fraction of a second before settling down to 31-32, as the shaping kicks in.
(Aside: it's always slightly above 30. I think they might be shaping to 30Mibps = 30x1024x1024 instead of 30Mbps)
Edited by candlerb (Wed 08-Apr-20 16:01:35)
|
|
|
That's 15ms from Edinburgh to London.
What's bad about that?
21ms to London on my Virgin FTTP.
I was simply pointing out that BT FTTP pings from Manchester to London isn't as high as the 10-20ms you said you were aware it was.
It's much nearer 10ms
As said the ping of BT FTTP also depends on the speed you applied for
That's not the case...?
I would get a 15ms ping from Edinburgh to London on BT FTTP on their 40Mb package, the 80Mb package, or the 1000Mb package.
It's only if the line is saturated that ping will increase, meaning a higher speed package would benefit more.
That's not unique to BT FTTP but is the same for the vast majority of contended broadband offerings.
|
|
|
I'm just awaiting Opt 5/6 roll-out to be honest... not for the speed but lowest ping to the exchange 
For an individual ping it won't make any difference.
The raw modulation speed on FTTP is 2.4G downstream, 1.2G upstream. This is the same regardless of which package you're on. Therefore, the time to transmit a single packet is the same.
Now, there is shaping in the OLT so that once you start receiving or sending a whole load of packets, and your average usage exceeds the line profile, the later ones are delayed so that you get the average bits-per-second throughput that you've paid for - typically using a "leaky bucket" algorithm. But if the bucket doesn't fill, there's no delay.
The result is: if you're on (say) 145/30, and as long as your short-term *average* usage is less than 145M down / 30M up, then you won't get any extra delay.
I can observe this on speedtest: I'm on 300/30, and outbound traffic bursts above 30 for a fraction of a second before setting down to 31-32, as the shaping kicks in.
(Aside: it's always slightly above 30. I think they might be shaping to 30Mibps = 30x1024x1024 instead of 30Mbps)
Yes so this becomes the problem of routing and traffic management.
All FTTP/FTTH ISPs shape the Internet speed as you described (physically their lines can run 1Gbps+), but routing and priority of traffic makes the difference
|
|
|
That's 15ms from Edinburgh to London.
What's bad about that?
21ms to London on my Virgin FTTP.
I was simply pointing out that BT FTTP pings from Manchester to London isn't as high as the 10-20ms you said you were aware it was.
It's much nearer 10ms
As said the ping of BT FTTP also depends on the speed you applied for
That's not the case...?
I would get a 15ms ping from Edinburgh to London on BT FTTP on their 40Mb package, the 80Mb package, or the 1000Mb package.
It's only if the line is saturated that ping will increase, meaning a higher speed package would benefit more.
That's not unique to BT FTTP but is the same for the vast majority of contended broadband offerings.
OK 10ms
Just found another similar topic:
https://forums.thinkbroadband.com/fibre/f/4640898-bt...
|
|
|
As said the ping of BT FTTP also depends on the speed you applied for
This is not correct.
|
|
|
The flow of traffic I'm looking for is:
My home (Manchester) <=> ISP server (Manchester / The North) <=> Outside World
Hyperoptic does achieve this. Not sure for Aquiss / Zen.
The traffic I don't want to see is this:
My home (Manchester) <=> ISP server (London Docklands) <=> Outside World
Extra latency occurred, not ideal.
On my three FTTP lines (all on BT Wholesale tails):
Line 1- Fluidone - FTTPoD 330/30
19ms to 8.8.8.8
Line 2- Trunk Networks - FTTP 330/50
26ms to 8.8.8.8
Line 3- BT Business - FTTP 330/50
17ms to 8.8.8.8
I'm in Inverness and on lines 1 & 3, the traffic hits Manchester first. On line 2 the traffic goes direct to London hence the higher ping times. The bigger ISPs (eg BT) will have more PoPs across the country so chances are they'll have a PoP between you & London. I'd be very surprised if BT don't route their traffic to Manchester first in your case. Oh and out of the 3, BT's service is the cheapest...so paying more doesn't guarantee you a better connection
Edited by deleted (Wed 08-Apr-20 18:01:58)
|
|
|
Please let me dig into slightly deeper - is the ping depending on the tier of Aquiss package (Qos) I'm applying for?
Not at all, all packages are equally managed in the same fashion, so you don't have to buy a higher tier to get a better ping.
Martin Pitt
Company Founder
Aquiss Limited
https://www.aquiss.net
FTTC, FTTP, GEA, EFM, Leased Lines, Telecoms and Hosting
|
|
The above post has been made by an ISP REPRESENTATIVE (although not necessarily the ISP being discussed in the post).
|
|
|
OK 10ms 
Just found another similar topic:
https://forums.thinkbroadband.com/fibre/f/4640898-bt...
Really need to test a simple site that is not multicast or potentially has caching at the ISP level. Using the famous sites of BBC, Google etc, or the 8.8.8.8 DNS server could give incorrect results. Pinging the thinkbroadband sites for example goes to Cloudflare.
So here are my answers from Virgin Media coax cable in North East Hampshire (Guildford franchise)
C:\>ping bbc.co.uk
Pinging bbc.co.uk [151.101.128.81] with 32 bytes of data:
Reply from 151.101.128.81: bytes=32 time=14ms TTL=58
Reply from 151.101.128.81: bytes=32 time=28ms TTL=58
Reply from 151.101.128.81: bytes=32 time=10ms TTL=58
Reply from 151.101.128.81: bytes=32 time=12ms TTL=58
Ping statistics for 151.101.128.81:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 10ms, Maximum = 28ms, Average = 16ms
C:\>ping google.co.uk
Pinging google.co.uk [172.217.168.227] with 32 bytes of data:
Reply from 172.217.168.227: bytes=32 time=26ms TTL=50
Reply from 172.217.168.227: bytes=32 time=22ms TTL=50
Reply from 172.217.168.227: bytes=32 time=22ms TTL=50
Reply from 172.217.168.227: bytes=32 time=22ms TTL=50
Ping statistics for 172.217.168.227:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 26ms, Average = 23ms
C:\>
C:\>ping thinkbroadband.com
Pinging thinkbroadband.com [80.249.106.141] with 32 bytes of data:
Reply from 80.249.106.141: bytes=32 time=17ms TTL=56
Reply from 80.249.106.141: bytes=32 time=15ms TTL=56
Reply from 80.249.106.141: bytes=32 time=11ms TTL=56
Reply from 80.249.106.141: bytes=32 time=11ms TTL=56
Ping statistics for 80.249.106.141:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 17ms, Average = 13ms
C:\>
20 years of broadband connectivity since 1999 trial - Live BQM
|
|
|
|
As others have said, your estimates of pings on BT are crazy.
I'm on 330/50 G.fast in Altrincham (just a couple of miles from Manchester Airport) and here are my pings;
PING bbc.co.uk (151.101.64.81) 56(84) bytes of data.
64 bytes from 151.101.64.81 (151.101.64.81): icmp_seq=1 ttl=57 time=8.35 ms
64 bytes from 151.101.64.81 (151.101.64.81): icmp_seq=2 ttl=57 time=8.83 ms
64 bytes from 151.101.64.81 (151.101.64.81): icmp_seq=3 ttl=57 time=8.61 ms
64 bytes from 151.101.64.81 (151.101.64.81): icmp_seq=4 ttl=57 time=8.85 ms
When on 80/20 FTTC pings were around 3ms higher. FTTP should give pings a couple of ms less than this from my experience of seeing it in use in Ireland.
|
|
|
Gfast and FTTP I would expect to be very similar pings as one of the improvements of gfast was lower latency to improve VR activity
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
|
I am on virgin,the later fibre to the home,no coax, in littleborough,pings to bbc average between 8-10 ms and usually get around 380mb on the 350 package
|
|
|
I am on virgin,the later fibre to the home,no coax, in littleborough,pings to bbc average between 8-10 ms and usually get around 380mb on the 350 package
Do Virgin no longer use coax internally? ie its now fibre all the way to an indoor ONT for their FTTP services?
Edited by deleted (Thu 09-Apr-20 11:05:23)
|
|
|
|
It converts to coax on the outside of the property.
I have less than a meter of coax between outside and my Virgin Hub.
|
|
|
OK 10ms 
Just found another similar topic:
https://forums.thinkbroadband.com/fibre/f/4640898-bt...
That topic is nonsense. It's comparing latency to London from London versus latency to London from elsewhere in the country. The speed of light is a thing.
Building better networks, not just faster ones.
|
|
|
Let's treat bbc.co.uk or google.co.uk as reference - don't worry about overseas traffic 
Let's not as it's misleading. What are you actually so interested in the latency to?
Most of the time traffic is going via London anyway, whether via the ISP's network or via transit or peering.
There's a reason why the London LINX LANs are in the multi-terabit per second range while the Manchester LAN is in the sub-100 Gbit/s range.
Building better networks, not just faster ones.
|
|
|
|
Wow, always thought pings up north were alot higher.
G Fast from sky in Kent:
Tracing route to google.co.uk [216.239.38.120]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms SkyRouter.Home [192.168.0.1]
2 2 ms 2 ms 2 ms 97e7feae.skybroadband.com [151.231.254.174]
3 6 ms 6 ms 6 ms be432.pr2.bllon.isp.sky.com [2.120.10.0]
4 6 ms 6 ms 5 ms 027ff1bb.bb.sky.com [2.127.241.187]
5 8 ms 7 ms 7 ms 216.239.48.217
6 7 ms 6 ms 6 ms 172.253.71.191
7 6 ms 5 ms 6 ms any-in-2678.1e100.net [216.239.38.120]
Trace complete.
|
|
|
Choice of endpoint makes a huge difference. This is also from Kent, via Cerberus 330/30:
MacBook-Pro-4:~ $ ping google.co.uk
PING google.co.uk (172.217.19.195): 56 data bytes
64 bytes from 172.217.19.195: icmp_seq=0 ttl=52 time=10.549 ms
64 bytes from 172.217.19.195: icmp_seq=1 ttl=52 time=10.459 ms
64 bytes from 172.217.19.195: icmp_seq=2 ttl=52 time=10.567 ms
64 bytes from 172.217.19.195: icmp_seq=3 ttl=52 time=10.983 ms
64 bytes from 172.217.19.195: icmp_seq=4 ttl=52 time=10.490 ms
^C
--- google.co.uk ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 10.459/10.610/10.983/0.191 ms
MacBook-Pro-4:~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=5.073 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=5.177 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=5.130 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=5.027 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 5.027/5.102/5.177/0.057 ms
MacBook-Pro-4:~ $ ping 216.239.38.120
PING 216.239.38.120 (216.239.38.120): 56 data bytes
64 bytes from 216.239.38.120: icmp_seq=0 ttl=57 time=4.264 ms
64 bytes from 216.239.38.120: icmp_seq=1 ttl=57 time=4.336 ms
64 bytes from 216.239.38.120: icmp_seq=2 ttl=57 time=4.388 ms
64 bytes from 216.239.38.120: icmp_seq=3 ttl=57 time=4.345 ms
^C
--- 216.239.38.120 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.264/4.333/4.388/0.045 ms
Notice how google.co.uk resolves to a different IP for me, with 10ms RTT. However, if I ping the IP that google.co.uk resolved to for you, that is only 4.3ms away.
The reason? Apparently 172.217.19.195 goes to a server in Amsterdam.
MacBook-Pro-4:~ $ traceroute google.co.uk
traceroute to google.co.uk (172.217.19.195), 64 hops max, 52 byte packets
1 gw1.home (10.12.0.1) 0.570 ms 0.206 ms 0.197 ms
2 lo-3-hex-lns08.cerberus.net.uk (46.37.48.1) 4.084 ms 4.225 ms 4.199 ms
3 gi-0-0-1-thn-gw05.cerberus.net.uk (46.37.33.193) 4.413 ms 4.361 ms 4.236 ms
4 195.66.224.125 (195.66.224.125) 7.980 ms 4.746 ms 4.808 ms
5 108.170.246.176 (108.170.246.176) 27.513 ms 4.927 ms
108.170.246.144 (108.170.246.144) 5.248 ms
6 216.239.58.133 (216.239.58.133) 7.144 ms
72.14.237.53 (72.14.237.53) 6.056 ms
216.239.57.227 (216.239.57.227) 5.931 ms
7 209.85.245.230 (209.85.245.230) 12.092 ms
209.85.142.166 (209.85.142.166) 11.385 ms
209.85.245.230 (209.85.245.230) 11.926 ms
8 216.239.42.171 (216.239.42.171) 11.687 ms 11.451 ms
209.85.254.48 (209.85.254.48) 11.356 ms
9 108.170.241.225 (108.170.241.225) 13.099 ms 12.719 ms
108.170.241.193 (108.170.241.193) 10.862 ms
10 72.14.239.45 (72.14.239.45) 11.017 ms 10.858 ms 11.556 ms
11 ams16s31-in-f3.1e100.net (172.217.19.195) 10.769 ms 10.544 ms 10.118 ms
In short: DNS geo-location, together with anycast and regular routing/peering, give complex results.
|
|
|
In short: DNS geo-location, together with anycast and regular routing/peering, give complex results. +1
Its why I always suggest people don't ping these high profile websites, or even DNS like 8.8.8.8 which is anycast.
Ping whatever it is you're trying to get through to, such as a VPN server, or a game server etc.
20 years of broadband connectivity since 1999 trial - Live BQM
|
|
|
I think its coax(,but could be fibre) for about 8ft from internal wall socket(not sure what to call it) to router,fibre into that internal socket from main cable/socket outside my property,they came and laid fibre under my garden to the house
https://richardglover.co.uk/2017/07/virgin-media-ftt...
Edited by steve195527 (Thu 09-Apr-20 21:33:59)
|
|
|
Not got VM so cannot say but going by one of those images its using a coaxial cable fitted with a F Connector as Power / RF In / RF Out (main broadband feed) and then uses optical fibre from there to inside the home.
Paul
|
|
|
Virgin Media RFOG/FTTP
Is fibre from the street to the outside wall, then a very short piece of coax into the home. There is a small fibre to docsis converter outside powered by the coax.
This means indoors the same kit can be used as is used in the many millions of fully coax streets
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
Ah, that makes sense, it was hard to see what was going where in that image.
Paul
|
|
|
|
I would suggest discarding Zen from your consideration.
I had a quite involved face to face discussion about this with some senior (technical) members of Zen staff in Rochdale last year... Because their network is flat, it can be load balanced (at L2) and go via London & that's just how it is. There's apparently a long range plan that should sort it (i.e. not being a massive flat network anymore) but I was told not to hold my breath.
|
|
|
|
Post deleted by steve195527
|
|
|
e.g. Remote Desktop? 2ms vs 20ms do make some differences.
Given it runs at 30 fps, 33.3 ms frame time, unless remote hardware acceleration is there this isn't really a thing.
Building better networks, not just faster ones.
|
|
|
Virgin Media RFOG/FTTP
Is fibre from the street to the outside wall, then a very short piece of coax into the home. There is a small fibre to docsis converter outside powered by the coax.
This means indoors the same kit can be used as is used in the many millions of fully coax streets
does that small length of coax impact the performance at all?as much as connecting to your router via WiFi or using a poor quality Ethernet cable?
|
|
|
Or you could just ask us 
The traffic is taken from your local area to the nearest of 30 regional PoPs around the country, then into the core network.
So in Manchester, it's taken into MANAP and then down the core network and routed according out via the exit PoP/Peering exchange nearest to where you are trying to reach. The core network also has a presence in Europe, remaining within the core network.
Hello!
I thought ManAP didn't exist anymore, there's a LINX peering LAN there, IX Manchester, and that's it?
Regarding IX Manchester, doesn't seem to be a LINX member named Aquiss.
Is this a third party supplier whom you resell? So probably TTB?
Building better networks, not just faster ones.
|
|
|
Not really - look at DOCSIS 3.1 and the 1.1 Gbps download already, upload will improve too once DOCSIS 3.1 used for that and coax has a lot more to give
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
I thought ManAP didn't exist anymore, there's a LINX peering LAN there, IX Manchester, and that's it?
Regarding IX Manchester, doesn't seem to be a LINX member named Aquiss.
Is this a third party supplier whom you resell? So probably TTB?
Aquiss always used to be an Entanet reseller and I am not aware this has changed.
|
|
|
I would suggest discarding Zen from your consideration.
I had a quite involved face to face discussion about this with some senior (technical) members of Zen staff in Rochdale last year... Because their network is flat, it can be load balanced (at L2) and go via London & that's just how it is. There's apparently a long range plan that should sort it (i.e. not being a massive flat network anymore) but I was told not to hold my breath.
Thanks for the info. Aquiss seems my choice then
|
|
|
e.g. Remote Desktop? 2ms vs 20ms do make some differences.
Given it runs at 30 fps, 33.3 ms frame time, unless remote hardware acceleration is there this isn't really a thing.
https://imgur.com/LxAKBRd
This is the (mobile) broadband service I'm currently using. Speed is not everything
Edited by guyinman (Fri 10-Apr-20 15:58:56)
|
|
|
|
Did you end up going with Aquiss? How have the ping times been?
|
|
|
Ping to what? Where you are pinging is key to the question. If on Hyperoptic you were pinging London from Manchester then I think you would have been breaking some rules of physics to do it in 1-3ms. It is possible that on Hyperoptic doing a ping was pinging a local server close to Manchester to be able to get pings that low.
The question of where you are pinging is important. If pinging something in London then it wouldn't matter if the main link connection for the ISP was in Manchester or London as it would still take about the same time - but if you were pinging something in Manchester and the internet main link was in London then the ping would have to travel to London and then back to Manchester meaning a longer transit.
Also, if pinging US then some ISPs might have better routes than others. And those routes may dynamically change depending on Internet usage and line conditions.
Let's treat bbc.co.uk or google.co.uk as reference - don't worry about overseas traffic 
The problem with BT is, it's always connecting to the Docklands (London) before going anywhere else. This cause extra delays of ~10ms (even more if you are at Scotland).
BBC, Netflix, Amazon etc do have CDN servers in the city centre BT exchange in Manchester though, I’ve seen them.
|