[time-nuts] IEEE 1588 PTP support on raspberry pi 4 compute module

Wed Oct 21 15:00:32 UTC 2020

Hello!

In summary, I say go for it!

This topic was bound to hit time-nuts - great to see Rpi finally going for
a MAC/PHY with hardware timestamp support and hopefully future full-sized
models will follow suit. Unfortunately for most chips other than Intel and
enterprise comms vendors like Solarflare, Mellanox etc, a IEEE-1588
compliant MAC/PHY means that the silicon physically only timestamps PTP
packets, whereas with Intel and others, it can timestamp all packets,
making for example hardware-backed NTP possible.

I would hardly dismiss the chance to use hardware timestamping and/or PTP,
or in fact dismiss any chance of any fun and experimentation with anything!
:-)

This being Broadcom, I could not get my hands on any reference documents
for BCM54210, so I am unable to assess whether it has any timestampable
event inputs on top of hardware timestamping, which could be used to sync
the h/w clock to 1PPS directly. If it hasn't, then it's a two-step process
to get GNSS (1PPS) into hardware: GNSS -> OS clock -> PTP clock. If one is
after PTP though, there are more suitable SBCs than the CM4 for which the
breakout board isn't sold yet, like Beaglebone Black (TI AM335x) or
Wandboard (i.mxN) or MinnowBoard (x86 and some variants have discrete Intel
PHY chips with 1PPS in/out support) or PC Engines' APU1/APU2 with
multiple(!) Intel PHYs.All of these support PTP.

Some comments to Bob's reply:

On Tue, 20 Oct 2020 at 23:08, Bob kb8tq <kb8tq at n1k.org> wrote:

> Hi
>
> Two very separate chunks to this:
>
> To get 1588 to work well, you either need very lightly loaded hardware

99% of servers used in high frequency trading today use 1588 and they are
hardly lightly loaded. CPU load has no effect on hardware timestamping and
PTP on the network card itself. It does affect syncing the OS clock to the
network interface, but not as much as you may think. Just like sub-100 ns
with a software-based 1PPS input is possible, sub-100 ns between the PTP
clock and OS clock also is.

> ,  no hardware or 1588 compatible
> switches and routers. In most cases “home use” cases NTP will get you into
> the microsecond(s) level. It
> does not take any fancy hardware and NTP drivers exist for just about
> everything.
>

PTP-compatible routers or switches (PTP Transparent Clock or Boundary
Clock) are only a real requirement if:

- you have a physical source of network path asymmetry such as a speed
change (100M ingress, 1G egress or similar)
- your network is actually congested e.g. you have frames contending for
port or switch fabric, not just by principle of this being a switch, but
really bad congestion

Physical path asymmetry will affect accuracy, so as far as time and
frequency stability, it only introduces a constant error.

Unless one's router/switch is a software-based or virtual one, or a very
ancient device otherwise, and the network isn't heavily loaded,  PTP
routinely achieves precision of sub-100 ns or better without network
assistance, depending on timestamp resolution of the hardware used, and
inherent PDV (jitter) of network equipment used - but it tends to be
Gaussian, and so filtrable. Obviously as long as the software (PTP slave)
isn't dumb and is capable of decent filtering and outlier removal,etc. In
early days, hubs (as in repeaters) rather than switches fared better; I
remember we used to use an old hub for PTP sync at work back in ~2007. PTP
I see and sell to customers today, provably delivers +/-20 ns or better
over transparent clocks, but before we had transparent clocks, sub-100 ns
was pretty much a norm already. Granted, on expensive hardware and on a
dedicated network, but the results were not all that different on a
proverbial NetGear switch, not by an order of magnitude anyway.

Practically, as far as the core principle of two-way time transfer goes,
PTP and NTP are identical, as long as hardware timestamping is used - which
tends to be problematic for NTP. It's only on-path PTP support that is
something that NTP will never grow.

If you happen to have a WiFi setup as part of your “net” forget about any
> sort of timing accuracy dimensioned in microseconds.
>
>
100% agree.

> ====
>
> Time wise, a < $10 single band GPS module ( ublox 8 series or whatever )
> will get you well below 100 ns.
> That’s much “better” time than NTP or 1588 will reliably transfer.

NTP not, PTP yes! With some asterisks but generally mostly yes. Key also
being fast message rates for PTP where the slave has plenty of samples to
pick and filter from. Otherwise this isn't really about NTP versus PTP,
it's about hardware vs. software timestamps. The amount of jitter
introduced by software timestamping on a non-realtime OS often tends to
exceed the same introduced by the network - on a local network that is.

> The F9P ( or better the F9T ) will do some neat stuff, you will loose it’s
> “value” as soon as you try to move it over the ethernet.

...but exactly the same happens if you try to move it over software-based
NTP, in fact it's much worse. Ethernet itself - really not that bad.
Granted, an F9x may be an overkill, but an 8-th gen or 7-th gen ublox
timing board would work very well, bordering on what PTP can actually
deliver.

> Simple answer:
>
> Plug one of the many ublox modules into a random PC or server, bring up
> NTP, get things pointed at it,
> move on. For added points, bring up three or four NTP servers …..
>
> Bob
>
>
...Or get a pair of those CM4 or say Beaglebone Black, even without GPS,
and see how PTP precision will look like between them on your network and
report back! Why settle on maintaining a stable clock in one device and not
share it with other devices even if the result is slightly degraded? This
is what mobile network operators did. Starting with 3G, but especially with
4G and now into 5G as backhaul networks became more sync friendly, you will
hardly see a GNSS receiver in a new base station anymore - you will see PTP
instead.

Just go for it :)

Thanks,
Wojciech

> > On Oct 20, 2020, at 4:49 PM, John De Witt <jhdewitt at gmail.com> wrote:
> >
> > First post, please be patient with me. Reading the list for a handful of
> years and grateful to the community.
> >
> > Am interested in low cost GNSS time source to keep clocks during
> internet outage.
> >
> > Just read that compute module raspberry pi 4 supports IEEE 1588
> Precision Time Protocol.
> >
> > Exciting to me ~25usd base for microsecond or better performance over
> network.
> >
> > Anyone planning on using this? Ethernet is handled by BCM54210 which
> states in data sheet: “IEEE 1588v2 compliant – One-step or two-step clock –
> On-chip timestamping”
> >
> > Thinking of pairing it with ZED-F9P with PPS would be fun to have PTP
> GPS stratum 1 on LAN for cheap. Ok enough rambling thank you have a nice
> day.
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com
> > To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>

-- 
-

Wojciech Owczarek