TimeKeeper Server

We just saw how TimeKeeper acts as a client (see the “TimeKeeper Client” section), consuming time from a number of different sources. TimeKeeper server builds on this to take this time and use it to serve accurate time to clients.

As mentioned before, all of the capabilities described below can be managed easily with the built-in web interface. Configuration samples will be used here to keep the descriptions concise.

Given time sources to track, TimeKeeper can deliver PTP, NTP and TIME, and more to thousands of clients. Below we’ll build on the previous NTP client snippet, so that the below configurations are standalone examples of how to serve time.

Serving NTP

NTP is a very accurate protocol that is often poorly implemented. Do not believe outlandish claims that NTP “cannot achieve accuracy better than a millisecond”, it’s simply not true. You’re most likely to hear this from someone trying to sell you a PTP solution, or someone accustomed to poor NTP implementations. TimeKeeper serving NTP to TimeKeeper clients delivers accuracy much better than a microsecond without complex and expensive investments in specialized protocols and networking hardware.

NTP server benefits include:

Enabling the NTP server is a matter of adding this to the configuration:

SOURCE0() { NTPSERVER=hostname; }
SERVENTP=1

If TIME (RFC 868) is also desired, it can be enabled by adding “SERVETIME=1” to the above configuration.

NTP can be restricted to a specific interface if needed in a particular environment. It can also provide authenticated time, alert on client accuracy issues, and more.

PTP Grandmaster/boundary clock

TimeKeeper serves IEEE 1588 versions 1 and 2 in a number of ways. Since most users are interested in version 2 the examples focus on that.

Some terminology is in order here. A Grandmaster is generally a clock at the root of a timing network, delivering time to downstream clients, which may in turn deliver time to their clients.

A boundary clock is a PTP clock that takes time in from some upstream time source, and delivers time based on that source to any downstream clients. Some boundary clocks also serve as a bottleneck, preventing downstream clients from being able to reach upstream time sources. TimeKeeper does not add that limitation.

When serving PTP, TimeKeeper serves multiple domains via multiple interfaces, allowing PTP traffic to be matched properly with the network speeds. This avoids the introduction of link asymmetries that can cause clients to be unintentionally biased. This also allows for careful and complete redundancy, far beyond the limited failover capabilities of the PTP protocol itself.

Some key features of TimeKeeper as a PTP Grandmaster or boundary clock include:

PTP (version 2) provides time in multiple ‘domains’, which can have different parameters and behavior. Clients can then track these individual domains as needed, for redundancy and comparison for example.

To serve PTP domain 0 (the default), just add this to our sample NTP server configuration:

SOURCE0() { NTPSERVER=hostname; }
SERVENTP=1
SERVEPTP0() { PTPSERVERVERSION=2; }

Note that TimeKeeper also supports PTP version 1. Configuring to use IEEE 1588 version 1 means that there would be a “1” in place of the “2” for the PTPSERVERVERSION above.

To also serve PTP domain 2, the configuration would be:

SOURCE0() { NTPSERVER=hostname; }
SERVENTP=1
SERVEPTP0() { PTPSERVERVERSION=2; }
SERVEPTP1() { PTPSERVERVERSION=2; PTPDOMAIN=2; }

In many cases, it’s useful to serve PTP via specific interfaces. This ensures, for example, that PTP for a 10 gigabit network is being specifically delivered on a 10 gigabit link. It also provides clear redundancy and failover options for clients.

As an example, let’s take the previous configuration, and serve the PTP domain 0 traffic via eth1, and PTP domain 2 via eth2.

SOURCE0() { NTPSERVER=hostname; }
SERVENTP=1
SERVEPTP0() { PTPSERVERVERSION=2; IFACE=eth1; }
SERVEPTP1() { PTPSERVERVERSION=2; PTPDOMAIN=2; IFACE=eth2; }

As with the client PTP configuration, there are more options and capabilities than covered here in this overview. The rest of the documentation covers the other options and benefits in more detail.

Synchronizing and serving time

At this point we can put together a single example of TimeKeeper tracking time from multiple sources and serving that time to clients. Below, TimeKeeper is tracking PTP on domain 0, with a fallback to unicast PTP (domain 1, via eth4) and then NTP. It will synchronize the local clock to these sources and serve it via PTP (domain 3) and any NTP clients.

SOURCE0() { PTPCLIENTVERSION=2; PTPDOMAIN=0; }
SOURCE1() { PTPCLIENTVERSION=2; PTPSERVER=grandmaster; PTPDOMAIN=1; IFACE=eth4; }
SOURCE2() { NTPSERVER=hostname; }
SERVEPTP0() { PTPSERVERVERSION=2; PTPDOMAIN=3; }
SERVENTP=1

In this case, TimeKeeper is acting as a boundary clock for PTP and a stratum server for NTP at the same time. NTP clients can use this server, and PTP clients can communicate with it with the default, hybrid, or telecom profiles. Any TimeKeeper clients could track both NTP and PTP from this system at the same time for protocol redundancy.

Serving time via PPS

TimeKeeper can also be configured to drive a PPS on the network to deliver accurate information for downstream clients. This allows for:

An example of this is where a TimeKeeper server tracks time and then uses those sources to steer a PPS that is fed directly to downstream clients. The clients can then consume and compare that direct PPS feed to their NTP and PTP data, to confirm any biases or asymmetries in the network.

Next steps

Now we’ve seen TimeKeeper take in time from multiple sources and use them to serve time in various forms to clients. TimeKeeper can be run directly by users on their own hardware, managed right along with all of their other software with common tools as part of their estate.

Alternatively, these features are also packaged up in appliance form, known as a Grandmaster. Let’s look at what TimeKeeper can do as an appliance.