Visible to Intel only — GUID: szk1673393538513
Ixiasoft
Visible to Intel only — GUID: szk1673393538513
Ixiasoft
5.1.6.9.3. Clock Types
- Ordinary clock
- Boundary clock
- End-to-End transparent clock
- Peer-to-Peer transparent clock
Ordinary clock
The ordinary clock in a domain supports a single copy of the protocol. The ordinary clock has a single PTP state and a single physical port. In typical industrial automation applications, an ordinary clock is associated with an application device such as a sensor or an actuator. In telecom applications, the ordinary clock can be associated with a timing demarcation device.
The ordinary clock can be a grandmaster or a receiver clock. It supports the following features:
- Sends and receives PTP messages. The timestamp snapshot can be controlled as described in MAC_Timestamp_Control register description.
- Maintains the data sets such as timestamp values.
Time Transmitter | Time Receiver |
---|---|
Delay_Req | SYNC |
For an ordinary clock, you can take the snapshot by setting the TSVER2ENA bit and selecting the snapshot mode in the MAC_Timestamp_Control register.
Boundary Clock
The boundary clock typically has several physical ports communicating with the network. The messages related to synchronization, host and subordinate hierarchy, and signaling terminate in the protocol engine of the boundary clock and such messages are not forwarded. The PTP message type status given by the MAC helps you to identify the type of message and take appropriate action.
- The clock data sets are common to all ports of the boundary clock.
- The local clock is common to all ports of the boundary clock.
End-to-End Transparent Clock
The end-to-end transparent clock supports the end-to-end delay measurement mechanism between the subordinate clocks and the source clock. The end-to-end transparent clock forwards all messages like normal bridge, router, or repeater. The residence time of a PTP packet is the time taken by the PTP packet from the ingress port to the egress port.
The residence time of a SYNC packet inside the end-to-end transparent clock is updated in the correction field of the associated Follow_Up PTP packet before it is transmitted. Similarly, the residence time of a Delay_Req packet, inside the end-to-end transparent clock, is updated in the correction field of the associated Delay_Resp PTP packet before it is transmitted. Therefore, the snapshot needs to be taken at both ingress and egress ports only for the messages mentioned in the table below. You can take the snapshot by setting the SNAPTYPSEL bits to 10 in the MAC_Timestamp_Control register.
PTP Messages |
---|
SYNC |
Delay_Req |
Peer-to-Peer Transparent Clock
The peer-to-peer transparent clock differs from the end-to-end transparent clock in the way it corrects and handles the PTP timing messages. In all other aspects, it is identical to the end-to-end transparent clock. In the peer-to-peer transparent clock, the computation of the link delay is based on an exchange of Pdelay_Req, Pdelay_Resp, and Pdelay_Resp_Follow_Up messages with the link peer. The residence time of the Pdelay_Req and the associated Pdelay_Resp packets is added and inserted into the correction field of the associated Pdely_Resp_Followup packet. Therefore, support for taking snapshot for the event messages related to Pdelay is added as shown in the table below.
PTP Messages |
---|
SYNC |
Pdelay_Req |
Pdelay_Resp |