IEEE 1588 (PTP) tips

A full description of the IEEE 1588 (PTP) protocol is beyond the scope of TimeKeeper documentation but these are some important suggestions for configuration of PTP with TimeKeeper.

PTP modes/profiles

There are several flavors of PTP (called profiles). Below is an overview:

Full multicast (TimeKeeper’s default mode)

In this profile the grandmaster sends out multicast messages (sync, followup and announce), clients send multicast delay requests, the grandmaster responds to each request with a multicast response. This is pretty wasteful of network and CPU resources since every client/grandmaster/switch has to handle multicast packets not meant for them.

The grandmaster sends multicast messages (sync, followup, and announce), clients send unicast delay requests, the grandmaster responds with unicast responses. This is the most efficient since only systems that need a given packet have to see it and multicast on the network is kept very low.

Full unicast (also called Telecom Profile)

Each client sends a lease request to the gm, which it responds to in order to maintain a 15 minute ‘lease’. The grandmaster sends unicast messages to each client and the full exchange happens unicast (delay request, response, etc). Clients and grandmasters have to re-establish the lease every 15 minutes and the grandmaster has to maintain a list of all the clients, their leases and so on. There is a great deal of memory and CPU overhead for this mode.

Delay measurement mechanism

There are two mechanisms for measuring network delay.

The end to end delay measurement mechanism, or E2E, measures the delay from the grandmaster to the client. This can be used with network equipment that is not PTP aware. It calculates the network delay across the entire path between the server and client.

The peer to peer delay measurement mechanism, or P2P, measures the delay between each device on the network. This requires that all network equipment (switches, routers etc.) in the path be PTP aware.

The PTP delay measurement mechanism is controlled by the PTP_P2P configuration option and only applies to the client because the server responds to whatever request mechanism it sees (E2E or P2P).

Boundary Clocks

We generally recommend against using boundary clocks.

The first reason for this is that most boundary clock implementations (on switches) are buggy and introduce errors, connection problems and inaccuracies. In most cases we find that PTP problems where boundary clocks are involved are a result of the boundary clocks and one of the first suggestions FSMLabs support will make is to disable the boundary clock to see if problems continue.

The second reason is that most boundary clocks block PTP management messages. This prevents the exchange of accuracy information between PTP entities. That means recording the accuracy of systems in one place and generating reports on them isn’t possible.