When input references have been supplying input to NetClock and input from all the references has been lost, NetClock will not immediately declare loss of time synchronization, but first will go into Holdover mode. While the unit is in Holdover mode, the time outputs are derived from the internal 10 MHz oscillator incrementing the System Time, but the oscillator is not disciplined/steered by the external reference e.g., GNSS.
Because of the stability of the internal oscillator, accurate time can still be derived even after all the primary references are no longer valid or present. The more stable the oscillator is without an external reference, the longer this holdover period can be and have it still maintain very accurate outputs. The benefit of Holdover is that time synchronization and the availability of the time outputs is not immediately lost when input references are no longer available.
While NetClock is in Holdover, the only difference is the Holdover and associated Minor alarm are asserted. There are no changes to NTP or any of the other outputs, i.e. while in Holdover mode, NTP inside NetClock continues to be at the same Stratum level it was at before going into Holdover mode (such as Stratum 1 when synced to GPS). Should the Holdover period expire, however, or the unit is rebooted, the NTP Stratum will go to 16, preventing any clients from being able to sync with NetClock until GPS or another reference has been restored.
NetClock will remain in Holdover mode until either:
- Any enabled and valid input reference becomes available again: If one or more references return and are declared valid before the Holdover period has expired (even momentarily, i.e. for at least one second), NetClock exits the Holdover mode and returns to its fully synchronized state.
- The Holdover Timeout period expires. In this case, NetClock will declare loss of synchronization.
Note that Holdover mode does not persist through reboots or power cycles. If a reboot or power cycle occurs while NetClock is in Holdover mode, it will power-up and remain in a “not synchronized” state until at least one valid Time and 1PPS input reference becomes available again. While in this state, NTP will be Stratum 15 and outputs will not be usable. If the input references are restored and then lost or declared not valid again, NetClock will then go back into Holdover mode.
Holdover Timeout is the user-configurable allowable time period in which NetClock remains in Holdover mode before it declares loss of synchronization. Holdover Timeout can be adjusted according to application-specific requirements and preferences. See below for recommendations on how long (short) the Holdover Timeout should be.
To set the Holdover Timeout value:
- Navigate to MANAGEMENT > OTHER: Disciplining, and click the GEAR icon in the Status panel:
For more information on the TFOM value and Phase Error Limit, see Configuring the Oscillator.
Note: Changes made to the Holdover Timeout always take effect immediately. If NetClock is in Holdover and the Holdover timeout is changed to a value that is less than the current time period that NetClock has been in Holdover Mode, the unit will immediately declare loss of synchronization.
The factory default Holdover period is 2 hours (7200 seconds). The value can be increased up to 5 years. During this time period, NetClock will be useable by its NTP clients (or other consumers) after GNSS reception has been lost.
The length of time is really based on the type of oscillator installed in a unit, and what the typical accuracy requirements are for the NTP clients. The longer it can run in Holdover mode before it expires, the longer it can continue being a central time source for all of its clients. But the longer NetClock runs in Holdover, the larger the offset to true UTC time will become, because the undisciplined oscillator will drift over time:
The better the type of oscillator installed, the more stable it is while in Holdover and therefore, the less its time will drift away from true UTC time. This results in more accurate timing, over extended durations upon the loss of GPS input. For instance, a Rubidium oscillator will maintain significantly better time over a longer Holdover duration than a TCXO oscillator (TCXOs are considerably less stable than a Rb oscillator).
The chart below provides typical time drifts (estimated "error rates") for the oscillator types that can be found in NetClock units. These numbers are based on the oscillator being locked to a reference for two weeks, but then loses GPS reception for an extended period of time, while the ambient temperature remains stable.
This data can help you determine how long of a Holdover period can be tolerated, based on how much time drift may occur after GPS input is lost. The larger the time error that can be tolerated by NetClock clients, based on the oscillator installed, the larger the Holdover timeout period can be set to.
Estimated Holdover time drifts
|(Nominal drifts)||TCXO||OCXO||Low Phase Noise OCXO||Rubidium||Low Phase Noise Rubidium|
|After 4 hours||12 µs||1µs||0.5 µs||0.2 µs||0.2 µs|
|After 24 hours||450 µs||25 µs||10 µs||1µs||1µs|
|After 7 days||3150 µs (3.1 ms)||175 µs||70 µs||7 µs||7 µs|
|After 30 days||13950 µs||775 µs||310 µs||31 µs||31 µs|
To find out which type of oscillator is installed in your NetClock, navigate to MANAGEMENT > OTHER: Disciplining, and look for the line item Oscillator Type in the Status panel.
The length of the allowed Holdover Timeout period is displayed and configured in seconds. The table below provides example conversions for typically desired Holdover periods.
|Desired Holdover Length||Holdover Length (in seconds) to be entered|
|2 hours||7200 seconds (default value)|
|24 hours||86 400|
|7 days||604 800|
|30 days||2 419 200|
|1 year||29 030 400|
Note: Due to Leap Seconds that are periodically inserted into the UTC and Local timescales, it is not normally recommended to exceed 30 days of Holdover without an external reference that can supply Leap Second information being applied (such as GNSS).
Configuring a Holdover value exceeding 30 days could result in a one second time error in the UTC or Local timescales until an external reference (GNSS or IRIG input) is restored or a manually configured Leap Second is asserted by a user (leap seconds do not affect the GPS and TAI time scales).
If no external references (such as GNSS or IRIG) are available when a Leap Second is scheduled to occur, manual Leap Seconds can also be applied to the UTC or Local time base; see Leap Seconds.
No, the Holdover timer is automatically reset as soon as at least one reference has been restored/returned for at least one second. If GPS is restored and then lost again moments later, the Holdover timer starts again with its full value. If its set to one week in this case, it then gets another week of Holdover operation before NTP goes to Stratum 16 (if GPS remained unavailable for the entire week).
If the only available input reference is a manually set User time, and NetClock is subsequently rebooted or power cycled, time sync will be lost when NetClock powers back-up. The time will need to be set manually again in order for NetClock to return to its fully synchronized state. See The "User/User" Reference and Manually Setting the Time for more information.