|
|
|
Hello,
I'm wondering how much of an improvement would FTTP have on ping (via BT 21CN/Openreach network) compared to having FTTC with an provider that uses BT 21CN/Openreach or TalkTalks Backhaul.
I'm currently getting 10-11ms to most servers located in London Docklands (TalkTalk FTTC) from Bristol (1.2km away from the cabinet) so I guess I'll be pulling around 7-9ms when I switch to FTTP next month.
Thanks,
|
|
|
My ping reduced by about 3ms when I moved from PlusNet FTTC to Cerberus FTTP. Pings to bbc.co.uk:
Plusnet round-trip min/avg/max/stddev = 5.232/5.648/6.707/0.390 ms
Cerberus round-trip min/avg/max/stddev = 2.525/2.811/2.984/0.134 ms
Cerberus FTTP + pfSense + Asus RT-AC67U AiMesh
Edited by brookheather (Sun 27-Oct-19 20:55:03)
|
|
|
I am on FTTP with BT and I am about 5.43km (3.37miles) (as the crow fly's) from Telehouse Data Centre so my pings are normally low, Not to sure what servers you are checking with, but I here are the ones I just pinged just now:
bbc.co.uk
ping -4 bbc.co.uk
Pinging bbc.co.uk [151.101.0.81] with 32 bytes of data:
Reply from 151.101.0.81: bytes=32 time=2ms TTL=57
Reply from 151.101.0.81: bytes=32 time=2ms TTL=57
Reply from 151.101.0.81: bytes=32 time=3ms TTL=57
Reply from 151.101.0.81: bytes=32 time=2ms TTL=57
Ping statistics for 151.101.0.81:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 3ms, Average = 2ms
thinkbroadband.com
ping -4 thinkbroadband.com
Pinging thinkbroadband.com [80.249.106.141] with 32 bytes of data:
Reply from 80.249.106.141: bytes=32 time=2ms TTL=56
Reply from 80.249.106.141: bytes=32 time=3ms TTL=56
Reply from 80.249.106.141: bytes=32 time=3ms TTL=56
Reply from 80.249.106.141: bytes=32 time=3ms 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 = 2ms, Maximum = 3ms, Average = 2ms
google.com
ping -4 google.com
Pinging google.com [216.58.210.46] with 32 bytes of data:
Reply from 216.58.210.46: bytes=32 time=3ms TTL=54
Reply from 216.58.210.46: bytes=32 time=4ms TTL=54
Reply from 216.58.210.46: bytes=32 time=3ms TTL=54
Reply from 216.58.210.46: bytes=32 time=4ms TTL=54
Ping statistics for 216.58.210.46:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 4ms, Average = 3ms
google.co.uk
ping -4 google.co.uk
Pinging google.co.uk [172.217.20.131] with 32 bytes of data:
Reply from 172.217.20.131: bytes=32 time=3ms TTL=54
Reply from 172.217.20.131: bytes=32 time=3ms TTL=54
Reply from 172.217.20.131: bytes=32 time=3ms TTL=54
Reply from 172.217.20.131: bytes=32 time=3ms TTL=54
Ping statistics for 172.217.20.131:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 3ms, Average = 3ms
I also get between 8 to 11ms (currently 9.62ms) to World of Warcraft EU Servers.
Paul
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
My latency (when pinging google.co.uk) went from 22ms to 20ms when I switched from TalkTalk Business FTTC to Fluidone FTTP, with the latter on BT Wholesale tails. So I wouldn't expect a huge improvement in latency, main factors are your geographical location and the route your FTTC/P line takes to London, as that's where most ISPs have their data centres. I'm in the Highlands.
Edited by deleted (Sun 27-Oct-19 15:43:38)
|
|
|
Cerberus FTTP (oD)
Ping bbc.co.uk
| Text | 1
23
45
67
89
1011
1213
1415
| Ping No Time(ms) IP Address Note
1 5.244 151.101.64.81 Reply 2 5.196 151.101.64.81 Reply
3 5.141 151.101.64.81 Reply 4 5.124 151.101.64.81 Reply
5 4.963 151.101.64.81 Reply 6 4.921 151.101.64.81 Reply
7 5.109 151.101.64.81 Reply 8 5.208 151.101.64.81 Reply
9 5.140 151.101.64.81 Reply 10 5.214 151.101.64.81 Reply
Sent 10 Received 10 Loss 0.00%
Min 4.921 Ave 5.126 Max 5.244 |
On FTTC I was getting around an additional 2 milliseconds, with another good ISP of course.
Edited by Ixel (Sun 27-Oct-19 16:14:03)
|
|
|
Pings to BBC - both sites are the same distance from Telstra London Hosting Centre give or take 150 metres.
Zen - FTTP 150/30;
PING 212.58.244.68 (212.58.244.68) 56(84) bytes of data.
64 bytes from 212.58.244.68: icmp_seq=1 ttl=58 time=4.77 ms
64 bytes from 212.58.244.68: icmp_seq=2 ttl=58 time=4.71 ms
64 bytes from 212.58.244.68: icmp_seq=3 ttl=58 time=4.24 ms
--- 212.58.244.68 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.247/4.578/4.771/0.235 ms
Zen FTTC 80/20;
PING 212.58.244.68 (212.58.244.68) 56(84) bytes of data.
64 bytes from 212.58.244.68: icmp_seq=1 ttl=54 time=5.07 ms
64 bytes from 212.58.244.68: icmp_seq=2 ttl=54 time=5.12 ms
64 bytes from 212.58.244.68: icmp_seq=3 ttl=54 time=5.09 ms
--- 212.58.244.68 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 5.075/5.098/5.123/0.084 ms
|
|
|
My ping reduced by about 3ms when I moved from PlusNet FTTC to Cerberus FTTP
I still have both PlusNet FTTC (about 30M down/4M up) and Cerberus FTTP.
To 8.8.8.8 via Cerberus FTTP:
round-trip min/avg/max/stddev = 4.976/5.048/5.163/0.082 ms
To 8.8.8.8 via Plusnet FTTC:
round-trip min/avg/max/stddev = 10.178/10.425/11.073/0.343 ms
|
|
|
yours is the only useful reply, the rest have a change of CP.
|
|
|
You're welcome 
In the two examples I give, the tiny difference in latency between FTTC and FTTP seems to be due to the difference in the connection speeds.
|
|
|
You're welcome
In the two examples I give, the tiny difference in latency between FTTC and FTTP seems to be due to the difference in the connection speeds.
I was going to say something like that, one of my neighbours also on FTTP at the start took the 80Mbit package and I did notice their latency was a fair bit larger than mine, but when they upped to the Ultrafast 1 speeds (cannot remember the speeds) it started to be closer to my latency.
I would of expected it between FTTC and FTTP, but these were both on FTTP, so maybe the way they cap the speed affects the latency.
So you might have something there.
Paul
|
|
|
|
Compare the latency with larger pings and you'll see how the transmission rate affects it.
(Linux: ping -s1472 to get 1500-byte packets. But don't use 8.8.8.8 as the endpoint, as they truncate the responses)
|
|
|
Compare the latency with larger pings and you'll see how the transmission rate affects it.
(Linux: ping -s1472 to get 1500-byte packets. But don't use 8.8.8.8 as the endpoint, as they truncate the responses)
I couldn't use that packet size, the highest size I could pick was 1464 shown below:
ping -s1464 bbc.co.uk
PING bbc.co.uk (151.101.128.81) 1464(1492) bytes of data.
1472 bytes from 151.101.128.81: icmp_seq=1 ttl=57 time=3.04 ms
1472 bytes from 151.101.128.81: icmp_seq=2 ttl=57 time=3.17 ms
1472 bytes from 151.101.128.81: icmp_seq=3 ttl=57 time=3.10 ms
^C
--- bbc.co.uk ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 3.046/3.108/3.178/0.084 ms
I tried on my PC and one of our servers and it was the same on both..
But going from the default 64 bytes to 1464 byte packets the ping remained the same.
If I tell it to use 1472 it just sits there doing nothing, so maybe they are blocking those larger packet sizes.
I did try TBB and got the following:
Larger Packet Size
ping -c3 -s1472 thinkbroadband.com
PING thinkbroadband.com (80.249.106.141) 1472(1500) bytes of data.
1480 bytes from ip106-141.thdo.ncuk.net (80.249.106.141): icmp_seq=1 ttl=56 time=3.71 ms
1480 bytes from ip106-141.thdo.ncuk.net (80.249.106.141): icmp_seq=2 ttl=56 time=3.39 ms
1480 bytes from ip106-141.thdo.ncuk.net (80.249.106.141): icmp_seq=3 ttl=56 time=3.43 ms
default packet side
ping -c3 thinkbroadband.com
PING thinkbroadband.com (80.249.106.141) 56(84) bytes of data.
64 bytes from ip106-141.thdo.ncuk.net (80.249.106.141): icmp_seq=1 ttl=56 time=2.93 ms
64 bytes from ip106-141.thdo.ncuk.net (80.249.106.141): icmp_seq=2 ttl=56 time=2.86 ms
64 bytes from ip106-141.thdo.ncuk.net (80.249.106.141): icmp_seq=3 ttl=56 time=2.95 ms
--- thinkbroadband.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 2.864/2.919/2.959/0.059 ms
And I can see it has gone up by 1ms when I use the larger packet size.
But 1ms isn't that much.
9K Packet size
ping -c3 -s9000 thinkbroadband.com
PING thinkbroadband.com (80.249.106.141) 9000(9028) bytes of data.
9008 bytes from ip106-141.thdo.ncuk.net (80.249.106.141): icmp_seq=1 ttl=56 time=4.88 ms
9008 bytes from ip106-141.thdo.ncuk.net (80.249.106.141): icmp_seq=2 ttl=56 time=4.56 ms
9008 bytes from ip106-141.thdo.ncuk.net (80.249.106.141): icmp_seq=3 ttl=56 time=4.67 ms
--- thinkbroadband.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 4.562/4.707/4.881/0.143 ms
So the 9K packet size is now 4.5 to 5ms so its gone from 2 - 3ms to 5ms, still rather good.
But yes I can see that the size does change this.
Paul
|
|
|
I couldn't use that packet size, the highest size I could pick was 1464 shown below:
Ah OK, that'll be the 8-byte PPPoE header. On my setup I have configured "baby jumbo" ethernet (1508 byte payload) between router and modem, so with PPPoE I still have 1500 MTU.
Anyway, on FTTP you're unlikely to measure any difference because the transmission rate is so high: 2.4Gbps down / 1.2Gbps up. Transmission delay in each direction:
82*8 / 2400000000 + 82*8 / 1200000000 = 0.82 microseconds
1500*8 / 2400000000 + 1500*8 / 1200000000 = 15 microseconds
But with FTTC 40/10:
82*8/40000000 + 82*8/10000000 = 82 microseconds
1500*8/40000000 + 1500*8/10000000 = 1.5 milliseconds
So I'd expect to see an increase of nearly 1.5 milliseconds for the larger packets.
|
|
|
Hopefully won't be a big deal but latency over FTTP can take a hit as it's a shared medium. The upstream gets busy dynamic bandwidth allocation won't be so kind to ONTs that've been sending lots of idle frames, the people torrenting away will get more of the capacity.
Upstream burst maps are sent every 0.125 ms so hopefully not a massive deal but I have seen busy Verizon PONs with latency close to 10 ms.
Building better networks, not just faster ones.
|
|
|
I couldn't use that packet size, the highest size I could pick was 1464 shown below:
Ah OK, that'll be the 8-byte PPPoE header. On my setup I have configured "baby jumbo" ethernet (1508 byte payload) between router and modem, so with PPPoE I still have 1500 MTU.
Anyway, on FTTP you're unlikely to measure any difference because the transmission rate is so high: 2.4Gbps down / 1.2Gbps up. Transmission delay in each direction:
82*8 / 2400000000 + 82*8 / 1200000000 = 0.82 microseconds
1500*8 / 2400000000 + 1500*8 / 1200000000 = 15 microseconds
But with FTTC 40/10:
82*8/40000000 + 82*8/10000000 = 82 microseconds
1500*8/40000000 + 1500*8/10000000 = 1.5 milliseconds
So I'd expect to see an increase of nearly 1.5 milliseconds for the larger packets.
I could use larger packet size, I tested up to 9K, it was due to the server I was trying didn't like it.
But yeah.
Paul
|
|
|
Hopefully won't be a big deal but latency over FTTP can take a hit as it's a shared medium. The upstream gets busy dynamic bandwidth allocation won't be so kind to ONTs that've been sending lots of idle frames, the people torrenting away will get more of the capacity.
Upstream burst maps are sent every 0.125 ms so hopefully not a massive deal but I have seen busy Verizon PONs with latency close to 10 ms.
Yeah, I have only had that issue once, but after a phone call to BT and a reconnect all has been fine since and we get our full speed 24/7.
The only issue I have now is the latency is that good in games now, I cannot blame the lag for me dying in a game LOL
Paul
|
|
|
I could use larger packet size, I tested up to 9K, it was due to the server I was trying didn't like it.
Anything over your MTU will use fragmentation: that is, it splits the datagram into multiple datagram fragments which are reassembled at the far end.
You can prevent this using "-Mdo" on the ping command (Linux only; macOS is "-D"). This sets a bit on the datagram which says "do not fragment", and you should get an ICMP error back from your router if the packet is too large.
|
|
|
Hopefully won't be a big deal but latency over FTTP can take a hit as it's a shared medium. The upstream gets busy dynamic bandwidth allocation won't be so kind to ONTs that've been sending lots of idle frames, the people torrenting away will get more of the capacity.
Upstream burst maps are sent every 0.125 ms so hopefully not a massive deal but I have seen busy Verizon PONs with latency close to 10 ms.
Interesting to know, I'll keep that in mind. Fortunately so far with about a half a year of having FTTPoD no other nearby address which is now eligible for FTTP is showing as having having an ONT yet, so lucky me I guess? One day that'll obviously change, e.g. possibly when new neighbors move in or the current neighbors become aware that FTTP is available to them and they'd like more speed. It surprises me that Openreach doesn't actually promote FTTP now being available with some leaflets delivered to the appropriate premises that can get it.
|
|
|
Once the big switch over starts and all the big ISP are on board you will see that happen.
Openreach leafleting will have many thinking you can only get it from BT
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
It surprises me that Openreach doesn't actually promote FTTP now being available with some leaflets delivered to the appropriate premises that can get it. Was saying the same thing earlier in another thread, no promoting of the product locally seems to be part of the reason for poor take up.
|
|
|
Once the big switch over starts and all the big ISP are on board you will see that happen.
Openreach leafleting will have many thinking you can only get it from BT But in the mean time the stats look bad and some use that to say faster speeded products are not required yet.
|
|
|
FTTP is now installed and I'm getting on adverage of 6-7ms on speedtest.net (excluding the high jitter since it was just installed). The lowest ping I saw today was 5ms from Bristol to London. (Over WiFi)
https://www.speedtest.net/android/5451390515.png
|
|
|
Once the big switch over starts and all the big ISP are on board you will see that happen.
Openreach leafleting will have many thinking you can only get it from BT But in the mean time the stats look bad and some use that to say faster speeded products are not required yet.
They would be correct. See take up of >80 Mb in FTTP-only services and proportion of VM customers on >200.
Building better networks, not just faster ones.
|
Pages in this thread: 
Print Thread
