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

Wed Oct 21 15:37:24 UTC 2020

Hi

> On Oct 21, 2020, at 11:00 AM, Wojciech Owczarek <wojciech at owczarek.co.uk> wrote:
> 
> 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.

*Networking* hardware is the issue …..

> 
> 
>> ,  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 have fully symmetric delays, then there is no need for 1588. NTP will 
do just fine. Unfortunately as even home networking hardware loads up, 
( = lots of traffic in only one direction) this may not be the case. When things
*do* go asymmetric, then you *do* need 1588 compatible switches.

Bob

> 
> 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
> _______________________________________________
> 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.