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)

In reply to a post by candlerb:

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

In reply to a post by PaulKirby:

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.

In reply to a post by candlerb:

In reply to a post by PaulKirby:

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

In reply to a post by CarlTSpeak:

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

In reply to a post by PaulKirby:

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.

In reply to a post by CarlTSpeak:

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

In reply to a post by Ixel:

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.