Why PTP is off the table on a Pi 4

The reference builds all reach for PTP (IEEE 1588), and they’re right to: on the right hardware it’s dramatically better than NTP.

The Pi 4 is not the right hardware. One command settles it:

$ ethtool -T eth0
Capabilities:
  software-transmit
  software-receive
  software-system-clock
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none

PTP Hardware Clock: none. There isn’t one. There’s no /dev/ptp0 to open.

Why that’s fatal rather than inconvenient

PTP’s whole advantage is hardware timestamping: the network card itself stamps the packet as it crosses the wire, in silicon, outside the operating system. That’s what removes kernel scheduling, driver latency, and queueing from the measurement, and it’s why PTP reaches nanoseconds where NTP reaches microseconds.

Take the hardware clock away and PTP is just… a protocol. Software-timestamped PTP has the packets stamped by the kernel, on the CPU, subject to exactly the scheduling jitter you were trying to escape. It is a more complicated NTP with worse tooling.

But the guides say the Pi 4’s PHY supports PTP

They do, and the chip does — the BCM54213PE PHY has PTP capability on paper. It doesn’t matter. The Pi 4’s bcmgenet MAC driver doesn’t expose a PHC, so Linux has nothing to give you. And the reference builds that make PTP work feed the PPS into the NIC through a SYNC pin that only the CM4/CM5 break out — a regular Pi 4 board doesn’t route it anywhere you can reach.

So don’t chase it

We spent real time on this before running ethtool -T, which we should have run first. If your board reports PTP Hardware Clock: none, close the tab. Put the effort into the PPS path instead — that’s where the nanoseconds actually are, and it needs the help.