Zen FTTP MTU Query

My parents have Zen FTTP 500/70 via a Huawei ONT and a FritzBox 7530 AX, with the MTU 1500 option enabled. Runnnig a speed test using different speed testing websites, the result is consistent on every website, with a downstream of ~500Mbit, an upstream of between 65Mbit to 70Mbit, a ping of 9ms to 20ms and 0% packet loss.

My home connection also runs Zen FTTP but I only have the 300/47 service, although it's going via a Nokia ONT and a FritzBox 7530 AX and the MTU 1500 option is disabled, so the MTU is 1492. Running a speed test using different speed testing websites, the result is different on every website, as follows:

speedtest.net: Downstream of 200Mbit to 300Mbit, upstream of 36Mbit to 47Mbit, a ping of 9ms to 20ms and packet loss of 0.5% to 1.5%.

speed.cloudflare.com: Downstream of 250Mbit to 300Mbit, upstream of 18Mbit to 25Mbit, a ping of 12ms and packet loss of 0.5% to 1.5%.

thinkbroadband.com: Downstream of 303Mbit, upstream of 20.0Mbit and a ping of 30ms.

All of these tests are conducted via Ethernet.

The Nokia ONT at my home is the 2.5Gbit version, dated 06/2023 on the back.

When I enable the MTU 1500 option at home (with the Nokia ONT) and re-run the tests, the results are worse and the packet loss increases,

Should I be seeing worse performance when I increase the MTU to 1500?

I thought for PPPoE authentication the MTU had to be 1492 because of the PPPoE header size.

Not if the infrastructure and ISP support RFC4638

The likely explanation for the difference between the similar setups is routing.

To answer your question; in an ideal world you shouldn't be seeing worse performance. Packet fragmentation is probably the cause, as this adds to overhead. So depending on the congestion of a router that your traffic is passing through, this may result in the extra packets being dropped. Ideally MTU discrepancies would be handled by Path MTU Discovery. The idea is that the MTU is reduced until everything is playing nicely. But some, primarily home, routers won't acknowledge the request to reduce the MTU and keep spaffing out packets at the predefined setting. Resulting in the aforementioned fragmentation and potential dropping.

Assuming you're on Windows you can play about with these via switches on the PING command:

-f Sets Do not fragment.
-l 1464 Sets the size. It's a lowercase L.

For example if I run "ping bbc.co.uk -l 1465" the request times out. Drop that to 1464 bytes and it works.

Yet I can ping quad9 with 9000 bytes (jumbo frame size) and it works, with only an additional ms of latency. That is, unless I use run "ping 9.9.9.9 -f -l 9000", at which point I get a "Packet needs to be fragmented but DF set." response and I'm back to the same 1464 size as BBC.

The easiest thing is to stick with the default MTU. You may miss out on the squeezing the last bit of performance from your connection, but it's not likely to cause you any issues.