How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
A simple hardware setup and software configuration for precision time synchronisation.
As noted in a previous article, An Introduction to IEEE 1588 Precision Time Protocol, PTP is much more than simply a higher performance NTP and it may be used to transfer frequency and provide phase alignment, in addition to providing time-of-day synchronisation. Furthermore, there are multiple versions of the standard and different 1588 network architectures, along with numerous profiles that have been developed to support a variety of different applications.
However, the simplest possible setup is comprised of a PTP grandmaster and a single slave device, without any sort of network switch in between. In this article, we’ll be taking a look at configuring such a setup for time synchronisation. We’ll be covering configuration of a grandmaster referenced to GPS, plus a BeagleBone Black (BBB) that is then synchronised to this. We’ll be using IEEE 1588-2008 — a.k.a. PTP v2 — which is the version of the standard most commonly in use today.
Cover from ITU-T Recommendation G.8265.1/Y.1365.1 (06/21).
Before we get on to configuration we will need to decide which IEEE 1588 profile we would like to use, as this will need to be suitable for our particular application, and the grandmaster and slave devices will need to be operating in compatible modes.
PTP profiles enable specific combinations of attribute values and optional features to be specified. For example, which Best Master Clock Algorithm (BMCA) is to be employed by the network in order to select the grandmaster, bearing in mind that there may often be more than one — for resilience and scaling purposes — and these may vary in accuracy. Profiles can define how path delay measurements are made, along with what types of nodes are required or may be used. Profiles may also extend the standard using TLVs (type, length, value) to carry additional information, and can specify optional BMCA and network management mechanisms.
Profiles are created by standards organisations and industry trade associations. We’ll be using a Symmetricom (now Microchip via Microsemi) TP2700, which was designed for synchronising 4G/LTE mobile networks, hence it supports two telecom profiles, plus a third. These are:
- Default. IEEE 1588-2008 Annex J multicast over UDP/IP.
- Telecom-2008. Generic unicast profile created for telecom before ITU-T G.8265.1.
- ITU-T G.8265-1. Telecom profile for frequency sync described in ITU-T G.8265.1.
Since we’re interested in time-of-day synchronisation, we’ll be using the first, Default, which was specified as an annex to the IEEE 1588-2008 (PTP v2) standard.
- The TP2700 key features are as follows:
- IEEE 1588 Precision Time Protocol Grandmaster
- ITU-T G.8265.1, Telecom-2008, and Default (optional) profiles
- Multi-Sync Enabled Boundary Clock (licensed option)
- GNSS (GPS and GLONASS), Primary Reference Time Clock (PRTC)
- Support for 8 to 64 PTP clients
- SyncE Input and Output
- 2 Gigabit Ethernet PTP/SyncE Interfaces (SFP or RJ45)
- E1/T1 Input or Output (optional)
- 10 MHZ or PPS, and TOD output
- 1 Gigabit Ethernet MGMT Port
Two particularly interesting features are support for Synchronous Ethernet (SyncE) and E1/T1 interfaces. The former is often used in telecoms networks to transfer clock signals via Ethernet, which are traceable to a common reference, such as the TP2700.
E1 is a carrier system for time-division multiplexing, which runs at a speed of 2.048Mbit/s and was originally developed for carrying voice communications in Europe. T1 meanwhile is the US equivalent, which runs at 1.544 Mbit/s. Both of which are used in Synchronous Digital Hierarchy (SDH) networks, which have mostly now given way to IP networking. However, with the TP2700 these ports could be used to sync to legacy SDH infrastructure, else to provide sync to it.
We also have of course GNSS, which is what we’ll be using as the primary reference. But should we ever need to, we could also use the same equipment to provide frequency and phase synchronisation to a SyncE or SDH network, in addition to providing a PTP service.
The grandmaster also features a management Ethernet port, which would typically be connected to a network dedicated to operations and maintenance (O&M), which is isolated from user traffic networks. We can use this to access a web interface and to connect via SSH for configuration, but it cannot be used for PTP and instead, we have to use the other two Ethernet ports, whereby one may optionally be configured as a PTP client, with the other as the grandmaster port.
It is common for grandmasters to support optional features which must be licensed and above can be seen the licenses configured in our device, which only has support for 8 up to PTP clients.
Finally, one nice feature of this grandmaster is that it is fitted with the rubidium oscillator a.k.a. “atomic clock” option, instead of just an oven-controlled crystal oscillator. This means that the holdover performance in the event of temporary loss of GNSS signal is far better, with this being specified as 24 hours instead of 1 hour for phase +/- 1.5usec, and frequency holdover at +/- 14 ppb being 5 years instead of 1 month.
Next, let's take a look at the configuration.
Here we can see that the default 1588 profile is active.
We can also examine the profile configuration, to check things such as the PTP priority settings are values advertised in PTP announce messages to determine the best master for the domain. The BMCA runs continuously, so master-capable devices are always looking out for the loss of a master clock. Selection is carried out based on six criteria, which along with the two priority values, includes the clock class, which can indicate if it is referenced to GNSS or perhaps has temporarily lost the signal and is in “holdover”, for example.
There are also configuration options for things such as interface addresses and VLAN tagging, firewall and SNMP management etc.
With our 1588 grandmaster set up, we can now turn to the client device.
We’ll be using a BeagleBone Black The Linux PTP Project. This was installed with:as the PTP client, which is based on a TI OMAP SoC with an Ethernet MAC that features 1588 hardware timestamp support. This will be running Debian Linux, with PTP software support courtesy of
$ sudo apt update $ sudo apt install linuxptp ethtool
We also installed the ethtool utility, since this allows us to check the Ethernet hardware to confirm that it does indeed have 1588 support enabled.
Note that since we have the Ethernet port directly cabled to the grandmaster and this does not route or bridge traffic, for configuration purposes we connected to the BBB via a USB WLAN adapter.
Linux PTP provides an executable called
ptp4l, which functions as a PTP Ordinary Clock (OC) or Boundary Clock (BC). The latter being a clock that is both a slave and master, which may be used to scale PTP networks. Configuration for
ptp4l is held in
Above we can see a fragment of the file which contains the global configuration. Note how utc_offset has been set to 37, which is the present number of seconds offset between International Atomic Time (TAI) and Universal Coordinated Time (UTC). This is required because TAI, as derived from atomic clocks, is continuous, whereas UTC is not and has leap seconds inserted — which are in turn necessary due to variances in the Earth’s rotation speed.
In the above configuration fragment, we can see the transport and interface options, which must be compatible with the grandmaster configuration.
Now if we execute
ptp4l, we see that it selects our grandmaster as the best master clock, following which messages are printed out with the master offset and path delay, which is required in order to be able to account for network latency. However, we are also told that we are “running in a temporal vortex” and that the UTC offset has been updated to 35 seconds. We’ll come back to this later.
On the TP2700 we can now see that we have one attached client.
And are able to issue a command that lists clients in order to find out more details.
At this point the
ptp4l process on our client is synchronising with the grandmaster, but if we want to sync the BBB system clock to PTP time, we also need to execute
The temporal vortex message and
ptp4l adjusting the UTC offset from the configured value of 37 to 35, would seem to suggest that the grandmaster is announcing an offset of the latter. However, if we execute the show clock command on the TP2700, this indicates that leap seconds is set to 37, as it should be at the time of writing. Furthermore, there does not appear to be any way to change this while the grandmaster is referenced to a GNSS primary time source.
On the BBB we are also able to execute
pmc, the PTP management client provided with Linux PTP, in order to try and dig a little deeper. Above we can see confirmation that the UTC offset is indeed set to 35 seconds. Furthermore, the grandmaster has indicated that this is valid and since it is referenced to a traceable time source, the PTP client has accepted the update.
At this point, it felt like it could be a firmware issue, since the TP2700 had not been updated in some time. Hence a support ticket was raised, the latest firmware was downloaded and the grandmaster was upgraded. Following which, upon testing once again, the temporal vortex message was no longer output and the UTC offset from international atomic time was set correctly, to 37 seconds.