10 Technical Appendix
10.5.3.9 SYNC/FOLLOWUP Messages
The selected master clock sends out SYNC (and, in Two-Step environments, the corresponding FOLLOWUP)
messages in a configured interval. This interval (default value is one SYNC/FOLLOWUP packet every second)
determines how often the slave devices receive synchronization data that allows them to adjust their internal
clocks in order to follow the master clock time. Between receiving two SYNC messages, a slave clock runs free
with the stability determined by its own internal time base, for example a crystal oscillator. One important
factor for deciding on the SYNC interval is the stability of this oscillator. A very good oscillator requires a lower
SYNC message rate than a cheaper, low-accuracy model. On the other hand you directly affect the required
network bandwidth by changing the SYNC interval.
For Meinberg slave devices, the default one-SYNC-every-second setting is more than enough to achieve the
highest possible synchronization accuracy.
10.5.3.10 (P)DELAY REQUEST Messages
As explained in the General Mode Options chapter (see the “End-To-End or Peer-to-Peer” section), the delay
measurements are an important factor for achieving the required accuracy. Especially in E2E mode, the network
path delay measurements play a crucial part in the synchronization process. Per default, the slaves will perform
delay measurements every 8 seconds, resulting in sending and receiving one packet. This can be increased in
case the network path delay variation in the network is relatively large (i.e. the time it takes for the SYNC
message to reach the slave varies a lot) or the slave devices have to tightly follow the master and adjust their
time base (oscillator) very often due to its instability.
Meinberg slave devices will limit the effect of an outdated path delay measurement by using filters and opti-
mized PLL algorithms. This avoids that a clock “jumps around” and basically monitors the time difference to the
master clock carefully for a certain amount of time before adjusting its own clock. With a low cost time base this
is not possible, because the instability (i.e. temperature-dependent drift and overall short term stability/aging
effects) and therefore these slaves would require to perform as many delay measurements and receive as many
SYNC/FOLLOWUP messages as possible.
For P2P mode the delay request interval is not as critical, simply because the delay variation on a single-hop link
(i.e. from your slave device to its switch) is very stable and does not change dramatically in typical environments.
Current firmware versions of Meinberg Grandmaster clocks (V5.32a and older) do not offer changing the Delay
message rate in Multicast mode, it is fixed to one delay request every 8 seconds. Since this is actually a value
that is transmitted in the DELAY_RESPONSE message as a maximum value, the slave devices are not allowed
to perform delay measurements more often.
microSync
Date: 22nd June 2020
73